intermittent failures and queries sent over TCP
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
Re: intermittent failures and queries sent over TCP
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 2020083121 2020081820 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 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN 2001:503:231d::2:30 c.gtld-servers.net. 172800 IN 2001:503:83eb::30 d.gtld-servers.net. 172800 IN 2001:500:856e::30 e.gtld-servers.net. 172800 IN 2001:502:1ca1::30 f.gtld-servers.net. 172800 IN 2001:503:d414::30 g.gtld-servers.net. 172800 IN 2001:503:eea3::30 h.gtld-servers.net. 172800 IN 2001:502:8cc::30 i.gtld-servers.net. 172800 IN 2001:503:39c1::30 j.gtld-servers.net. 172800 IN 2001:502:7094::30 k.gtld-servers.net. 172800 IN 2001:503:d2d::30 l.gtld-servers.net. 172800 IN 2001:500:d937::30 m.gtld-servers.net. 172800 IN 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 > 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.co
Re: intermittent failures and queries sent over TCP
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 ___ 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
