intermittent failures and queries sent over TCP

[David Newman]

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;


};

[Mark Andrews]

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

> _______________________________________________
> 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-...@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: ma...@isc.org

[David Newman]

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