Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.protocols.dns.bind > #16050

Re: intermittent failures and queries sent over TCP

Show key headers only | View raw

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

Back to comp.protocols.dns.bind | Previous | Next | Find similar

Thread

Re: intermittent failures and queries sent over TCP Mark Andrews <marka@isc.org> - 2020-08-19 10:55 +1000

csiph-web