Common operational misconceptions

Thu Feb 16 22:40:16 UTC 2012

In message <CA+ycCUOoLgwAMUn_aSBf8FFiPczWmt2oo7T45jOnqthJWx+xpg at mail.gmail.com>, Daniel Griggs writes:
> --001636c5b8ca93b4eb04b91b7066
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Seems like dig doesn't always advertise a big enough buffer, I was having
> the same issue as you. If you set the buffer size on the command line it
> works as directed.

Well you were supposed to ask your recursive server, not ask the
authoritative server directly.  We were talking about testing the
path from the recursive server (which you may not have log in access
to) to the authoritative server.  If you want to ask the authoritative
server directly then +edns=0 or +dnssec or +bufsize=4096 or you can
use dig from BIND 9.9.0 which sets the ad flag and enables edns
(version 0) by default.

% dig edns-v6-ok.isc.org txt
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.7.3-P3 <<>> edns-v6-ok.isc.org txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46198
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;edns-v6-ok.isc.org.		IN	TXT

;; ANSWER SECTION:
edns-v6-ok.isc.org.	0	IN	TXT	"EDNS-4096-OK" "EDNS-4096-OK" <snipped>

;; AUTHORITY SECTION:
edns-v6-ok.isc.org.	7199	IN	NS	edns-v6-ok.isc.org.

;; ADDITIONAL SECTION:
edns-v6-ok.isc.org.	7199	IN	AAAA	2001:4f8:0:2::8

;; Query time: 174 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Feb 17 09:36:37 2012
;; MSG SIZE  rcvd: 4127

%

> Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58
> ;; Truncated, retrying in TCP mode.
> ;; Connection to 149.20.64.58#53(149.20.64.58) for
> edns-v4-ok.isc.orgfailed: connection refused.
> Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58+bufsize=4096
> 
> ; <<>> DiG 9.7.3-P3 <<>> edns-v4-ok.isc.org txt @149.20.64.58 +bufsize=4096
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18209
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;edns-v4-ok.isc.org.        IN    TXT
> 
> ;; ANSWER SECTION:
> edns-v4-ok.isc.org.    0    IN    TXT    "EDNS-4096-OK" "EDNS-4096-OK"
> "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK"
> <snip>
> "EDNS-4"
> 
> ;; Query time: 176 msec
> ;; SERVER: 149.20.64.58#53(149.20.64.58)
> ;; WHEN: Fri Feb 17 10:22:08 2012
> ;; MSG SIZE  rcvd: 4096
> 
> 
> 
> 
> On 17 February 2012 05:53, Phil Regnauld <regnauld at nsrc.org> wrote:
> 
> >        Borderline dns-ops, sorry folks! - but this is interesting
> >        as we've been talking about ipv6 being operational, and this
> >        is part of it...
> >
> > Mark Andrews (marka) writes:
> > >
> > > If you are seeing TC between the resolver and the server and the TCP
> > query is being answers then
> > > something in the path is intercepting the DNS queries.
> >
> >         TC is on the answer from the remote server to my resolver, so
> > yeah, seems
> >        like something is messing with the packets.
> >
> > > >     Don't see any v6 fragments (that'd be a problem since PF doesn't
> > handle
> > > >     them on this host).
> > >
> > > You should see something like this on the wire.  The second query is to
> > answer
> > > dig's query over TCP.
> >
> >         I'm not seeing fragments as you are.
> >
> >        Here's what I see:
> >
> > 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 52841
> > TXT? edns-v6-ok.isc.org. (36)
> > 14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561:
> > 52841*-| 0/0/0 (36)
> > 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flags
> > [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS
> > val 2571957531 ecr 0], length 0
> > 14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flags
> > [R.], seq 0, ack 1112939463, win 0, length 0
> >
> >        Cheers,
> >        Phil
> >
> >
> 
> 
> -- 
> Daniel Griggs
> Network Operations
> e: daniel at fx.net.nz
> d: +64 4 4989567
> 
> --001636c5b8ca93b4eb04b91b7066
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <br>Seems like dig doesn't always advertise a big enough buffer, I was =
> having the same issue as you. If you set the buffer size on the command lin=
> e it works as directed.<br><br>Daniels-Mac-mini:~ daniel$ dig <a href=3D"ht=
> tp://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a> txt @<a href=3D"http://149.=
> 20.64.58">149.20.64.58</a><br>
> ;; Truncated, retrying in TCP mode.<br>;; Connection to 149.20.64.58#53(149=
> .20.64.58) for <a href=3D"http://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a>=
>  failed: connection refused.<br>Daniels-Mac-mini:~ daniel$ dig <a href=3D"h=
> ttp://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a> txt @<a href=3D"http://149=
> .20.64.58">149.20.64.58</a> +bufsize=3D4096<br>
> <br>; <<>> DiG 9.7.3-P3 <<>> <a href=3D"http://edns=
> -v4-ok.isc.org">edns-v4-ok.isc.org</a> txt @<a href=3D"http://149.20.64.58"=
> >149.20.64.58</a> +bufsize=3D4096<br>;; global options: +cmd<br>;; Got answ=
> er:<br>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18209<br>;;=
>  flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1<br>;; WA=
> RNING: recursion requested but not available<br><br>;; OPT PSEUDOSECTION:<b=
> r>
> ; EDNS: version: 0, flags:; udp: 4096<br>;; QUESTION SECTION:<br>;<a href=
> =3D"http://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a>.=A0=A0=A0 =A0=A0=A0 I=
> N=A0=A0=A0 TXT<br><br>;; ANSWER SECTION:<br><a href=3D"http://edns-v4-ok.is=
> c.org">edns-v4-ok.isc.org</a>.=A0=A0=A0 0=A0=A0=A0 IN=A0=A0=A0 TXT=A0=A0=A0=
>  "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK"=
>  "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK"=
>  <br>
> <snip><br>"EDNS-4"<br><br>;; Query time: 176 msec<br>;; SER=
> VER: 149.20.64.58#53(149.20.64.58)<br>;; WHEN: Fri Feb 17 10:22:08 2012<br>=
> ;; MSG SIZE=A0 rcvd: 4096<br><br><br><br><br><div class=3D"gmail_quote">On =
> 17 February 2012 05:53, Phil Regnauld <span dir=3D"ltr"><<a href=3D"mail=
> to:regnauld at nsrc.org">regnauld at nsrc.org</a>></span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"> =A0 =A0 =A0 =A0Borderline dns-ops, sorry fo=
> lks! - but this is interesting<br>
>  =A0 =A0 =A0 =A0as we've been talking about ipv6 being operational, and=
>  this<br>
>  =A0 =A0 =A0 =A0is part of it...<br>
> <div class=3D"im"><br>
> Mark Andrews (marka) writes:<br>
> ><br>
> > If you are seeing TC between the resolver and the server and the TCP q=
> uery is being answers then<br>
> > something in the path is intercepting the DNS queries.<br>
> <br>
> </div> =A0 =A0 =A0 =A0TC is on the answer from the remote server to my reso=
> lver, so yeah, seems<br>
>  =A0 =A0 =A0 =A0like something is messing with the packets.<br>
> <div class=3D"im"><br>
> > > =A0 =A0 Don't see any v6 fragments (that'd be a problem s=
> ince PF doesn't handle<br>
> > > =A0 =A0 them on this host).<br>
> ><br>
> > You should see something like this on the wire. =A0The second query is=
>  to answer<br>
> > dig's query over TCP.<br>
> <br>
> </div> =A0 =A0 =A0 =A0I'm not seeing fragments as you are.<br>
> <br>
>  =A0 =A0 =A0 =A0Here's what I see:<br>
> <br>
> 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 5284=
> 1 TXT? <a href=3D"http://edns-v6-ok.isc.org" target=3D"_blank">edns-v6-ok.i=
> sc.org</a>. (36)<br>
> 14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561: 5284=
> 1*-| 0/0/0 (36)<br>
> 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flag=
> s [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS =
> val 2571957531 ecr 0], length 0<br>
> 14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flag=
> s [R.], seq 0, ack 1112939463, win 0, length 0<br>
> <br>
>  =A0 =A0 =A0 =A0Cheers,<br>
>  =A0 =A0 =A0 =A0Phil<br>
> <br>
> </blockquote></div><br><br clear=3D"all"><br>-- <br>Daniel Griggs<br>Networ=
> k Operations<br>e: <a href=3D"mailto:daniel at fx.net.nz" target=3D"_blank">da=
> niel at fx.net.nz</a><br>d: +64 4 4989567<br>
> 
> --001636c5b8ca93b4eb04b91b7066--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org