• intermittent failures and queries sent over TCP

    From David Newman@dnewman@networktest.com to bind-users on Tue Aug 18 17:34:41 2020
    From Newsgroup: comp.protocols.dns.bind

    bind 9.11.5.P4 on Debian 10

    Greetings. I recently had to migrate a nameserver from FreeBSD to
    Debian. It works fine most of the time but I've noticed a few
    intermittent resolution failures.

    After "gmail.com" failed to resolve I took a packet capture using
    tcpdump to listen to the result of the command "dig -t mx gmail.com" and
    here's what I found:

    1. That query over UDP, with responses over UDP pointing to Google's nameservers

    2. Nearly 200 attempts to reach root servers over TCP, followed
    immediately by RST messages from the root servers.

    Some time later, gmail.com started resolving succesfully again, clearing
    up the issue for now.

    AFAIK there's nothing in the BIND configs that would force the use of
    TCP queries. I checked the docs for various TCP options and didn't see
    any applied here. I don't know if the TCP queries are related to the
    gmail.com resolution failure but I suspect they are (and in any event
    inability to reach root servers is a problem).

    This server is authoritative for several domains. It gets its zones from
    a hidden primary. The system's firewall permits inbound TCP and UDP
    traffic on port 53 and AFAIK does not block outbound UDP (the firewall
    is nftables, which is new to me, but since I see UDP queries in the
    packet capture I think it works).

    What would cause the server to send queries over TCP?

    Thanks in advance for troubleshooting clues.


    dn



    CONFIG FILES

    (named.conf is just pointers to .local and .options and .default-zones)

    // named.conf.local

    acl "xfer" {
    // redacted -- a list of IPv4 and IPv6 addresses I trust
    };

    controls {
    inet 127.0.0.1 port 953 allow { 127.0.0.1; };
    };

    logging {
    channel simple_log {
    file "/var/log/named/named.log" versions 30 size 1m;
    severity info;
    print-time yes;
    print-severity yes;
    print-category yes;
    };
    category default { simple_log; };
    category update { simple_log; };
    category update-security { simple_log; };
    category security { simple_log; };
    category queries { simple_log; };
    category lame-servers { null; };
    };

    zone "example1.org" in {
    type slave;
    file "example1.org.bak";
    masters { 198.18.0.53; }; // not the real address
    allow-query { any; };
    allow-transfer { xfer; };
    };

    zone "example2.org" in {
    type slave;
    file "example2.org.bak";
    masters { 198.18.0.53; }; // not the real address
    allow-query { any; };
    allow-transfer { xfer; };
    };

    // etc.


    // named.conf.options

    acl "trusted" {

    // redacted -- a list of IPv4 and IPv6 addresses I trust
    };

    options {
    directory "/var/cache/bind";
    pid-file "/var/run/named/named.pid";
    statistics-file "/var/run/named/named.stats";
    transfer-format many-answers;
    masterfile-format text;
    max-transfer-time-in 60;
    allow-query { any; };
    allow-recursion { trusted; };
    allow-query-cache { trusted; };
    allow-transfer { xfer; };
    version none;

    disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
    disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
    disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";


    querylog yes;


    };
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From Mark Andrews@marka@isc.org to David Newman on Wed Aug 19 10:55:36 2020
    From Newsgroup: comp.protocols.dns.bind

    Named will try TCP when the server returns TC=1 (TrunCated) in the UDP response.
    If you are getting RST responses check your firewall settings. RST is often forged
    when TCP is blocked. The root servers normally accept TCP connections.
    % dig +tcp gmail.com @a.root-servers.net +dnssec
    ; <<>> DiG 9.15.4<<>> +tcp gmail.com @a.root-servers.net +dnssec
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10648
    ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 27
    ;; WARNING: recursion requested but not available
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 1232
    ;; QUESTION SECTION:
    ;gmail.com. IN A
    ;; AUTHORITY SECTION:
    com. 172800 IN NS a.gtld-servers.net.
    com. 172800 IN NS b.gtld-servers.net.
    com. 172800 IN NS c.gtld-servers.net.
    com. 172800 IN NS d.gtld-servers.net.
    com. 172800 IN NS e.gtld-servers.net.
    com. 172800 IN NS f.gtld-servers.net.
    com. 172800 IN NS g.gtld-servers.net.
    com. 172800 IN NS h.gtld-servers.net.
    com. 172800 IN NS i.gtld-servers.net.
    com. 172800 IN NS j.gtld-servers.net.
    com. 172800 IN NS k.gtld-servers.net.
    com. 172800 IN NS l.gtld-servers.net.
    com. 172800 IN NS m.gtld-servers.net.
    com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
    com. 86400 IN RRSIG DS 8 1 86400 20200831210000 20200818200000 46594 . PYeeQv/k4ZmcU9umNOIIKJFf3lyVEfd740ppq1E+hiv037ckkEsqMKiQ rELQZnazq/J4mPZHGV0oyrEpLXMIcEbwBHLLH9I06LyLxlipWWvo56A8 xmJNfbMgRefV1tM45azUETCDLUzIWTZDcAAHEszZKqeyMXNJAWb8h8Ip 6DbVBGS8g9mYyUVt2xiOafw18ZZyljBnb/mdYUOKKs5q7+b/CrbtCVip jINz6vdGAEnFNMS4K8GsL/x9usZ3jVFt9YErWFYJfBovlkUGqEQGYt2i IsvBMzeh4K43jJeaKd/4M0ZVJ6j8w61Hq9BHyi/f6FM7ANbzLSHm11y8 PENYkA==
    ;; ADDITIONAL SECTION:
    a.gtld-servers.net. 172800 IN A 192.5.6.30
    b.gtld-servers.net. 172800 IN A 192.33.14.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 i.gtld-servers.net. 172800 IN A 192.43.172.30 j.gtld-servers.net. 172800 IN A 192.48.79.30 k.gtld-servers.net. 172800 IN A 192.52.178.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 m.gtld-servers.net. 172800 IN A 192.55.83.30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30 d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30 e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30 f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30 g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30 h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30 i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30 j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30 k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30 l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30 m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
    ;; Query time: 327 msec
    ;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
    ;; WHEN: Wed Aug 19 10:48:11 AEST 2020
    ;; MSG SIZE rcvd: 1169
    %
    Mark
    On 19 Aug 2020, at 10:34, David Newman via bind-users <bind-users@lists.isc.org> wrote:

    bind 9.11.5.P4 on Debian 10

    Greetings. I recently had to migrate a nameserver from FreeBSD to
    Debian. It works fine most of the time but I've noticed a few
    intermittent resolution failures.

    After "gmail.com" failed to resolve I took a packet capture using
    tcpdump to listen to the result of the command "dig -t mx gmail.com" and here's what I found:

    1. That query over UDP, with responses over UDP pointing to Google's nameservers

    2. Nearly 200 attempts to reach root servers over TCP, followed
    immediately by RST messages from the root servers.

    Some time later, gmail.com started resolving succesfully again, clearing
    up the issue for now.

    AFAIK there's nothing in the BIND configs that would force the use of
    TCP queries. I checked the docs for various TCP options and didn't see
    any applied here. I don't know if the TCP queries are related to the gmail.com resolution failure but I suspect they are (and in any event inability to reach root servers is a problem).

    This server is authoritative for several domains. It gets its zones from
    a hidden primary. The system's firewall permits inbound TCP and UDP
    traffic on port 53 and AFAIK does not block outbound UDP (the firewall
    is nftables, which is new to me, but since I see UDP queries in the
    packet capture I think it works).

    What would cause the server to send queries over TCP?

    Thanks in advance for troubleshooting clues.


    dn



    CONFIG FILES

    (named.conf is just pointers to .local and .options and .default-zones)

    // named.conf.local

    acl "xfer" {
    // redacted -- a list of IPv4 and IPv6 addresses I trust
    };

    controls {
    inet 127.0.0.1 port 953 allow { 127.0.0.1; };
    };

    logging {
    channel simple_log {
    file "/var/log/named/named.log" versions 30 size 1m;
    severity info;
    print-time yes;
    print-severity yes;
    print-category yes;
    };
    category default { simple_log; };
    category update { simple_log; };
    category update-security { simple_log; };
    category security { simple_log; };
    category queries { simple_log; };
    category lame-servers { null; };
    };

    zone "example1.org" in {
    type slave;
    file "example1.org.bak";
    masters { 198.18.0.53; }; // not the real address
    allow-query { any; };
    allow-transfer { xfer; };
    };

    zone "example2.org" in {
    type slave;
    file "example2.org.bak";
    masters { 198.18.0.53; }; // not the real address
    allow-query { any; };
    allow-transfer { xfer; };
    };

    // etc.


    // named.conf.options

    acl "trusted" {

    // redacted -- a list of IPv4 and IPv6 addresses I trust
    };

    options {
    directory "/var/cache/bind";
    pid-file "/var/run/named/named.pid";
    statistics-file "/var/run/named/named.stats";
    transfer-format many-answers;
    masterfile-format text;
    max-transfer-time-in 60;
    allow-query { any; };
    allow-recursion { trusted; };
    allow-query-cache { trusted; };
    allow-transfer { xfer; };
    version none;

    disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
    disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
    disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";


    querylog yes;


    };
    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

    ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


    bind-users mailing list
    bind-users@lists.isc.org
    https://lists.isc.org/mailman/listinfo/bind-users
    --
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From David Newman@dnewman@networktest.com to Mark Andrews on Tue Aug 18 18:12:45 2020
    From Newsgroup: comp.protocols.dns.bind

    On 8/18/20 5:55 PM, Mark Andrews wrote:

    If you are getting RST responses check your firewall settings. RST is often forged
    when TCP is blocked. The root servers normally accept TCP connections.

    % dig +tcp gmail.com @a.root-servers.net +dnssec

    Bingo. This query failed before adding a rule to the upstream firewall
    to allow outbound queries, and works now.

    Thanks!

    dn

    --- Synchronet 3.18a-Linux NewsLink 1.113