new bind 9.9 and root NS

[Michael Hoskins (michoski)]

-----Original Message-----

From: "dkoleary at olearycomputers.com" <dkoleary at olearycomputers.com>
Organization: http://groups.google.com
Date: Tuesday, July 31, 2012 2:16 PM
To: "comp-protocols-dns-bind at isc.org" <comp-protocols-dns-bind at isc.org>
Subject: new bind 9.9 and root NS

>I have a client who's migrating from an old bind 9.3 installation to a
>new bind 9.9.  I've done the migration and everything seemed to be
>running fine.  Before switching the internic pointers, though, the
>client gave it a good thorough trashing and they're finding some
>issues.
>
>On the new system, the first time a domain outside of the client's
>authoritative space is queried, the response takes longer than it
>should.  Obviously, non-cached searches will take longer, but these
>are taking *way* longer:
>
># rndc flush
># time host www.olearycomputers.com.
>www.olearycomputers.com has address 69.246.199.78
>real 0m7.62s
>user 0m0.00s
>sys 0m0.00s
>
>The old server beats that by more than 3 seconds:
>
>[root]# rndc flush
>[root]# time host www.olearycomputers.com.
>www.olearycomputers.com has address 69.246.199.78
>real 0m3.334s
>user 0m0.003s
>sys 0m0.003s


This almost sounds like an upstream firewall or proxy with faulty protocol
"fixups".  If you do a query and EDNS is blocked or improperly configured
a "fall back" will occur which causes queries to take longer or possibly
timeout.


>A dig trace on the old box looks resonable:
>
># dig +trace www.olearycomputers.com
>; <<>> DiG 9.3.4 <<>> +trace www.olearycomputers.com
>;; global options: printcmd
>[[root ns snipped]]
>;; Received 512 bytes from 143.43.32.201#53(143.43.32.201) in 1 ms
>com. 172800 IN NS f.gtld-servers.net.
>com. 172800 IN NS k.gtld-servers.net.
>com. 172800 IN NS m.gtld-servers.net.
>[[remaining .com NS snipped]]
>;; Received 501 bytes from 192.5.5.241#53(f.root-servers.net) in 71 ms
>olearycomputers.com. 172800 IN NS ns3.no-ip.com.
>olearycomputers.com. 172800 IN NS ns1.no-ip.com.
>olearycomputers.com. 172800 IN NS ns4.no-ip.com.
>olearycomputers.com. 172800 IN NS ns5.no-ip.com.
>;; Received 211 bytes from 192.35.51.30#53(f.gtld-servers.net) in 77
>ms
>www.olearycomputers.com. 60 IN A 69.246.199.78
>olearycomputers.com. 86400 IN NS ns5.no-ip.com.
>[[etc]]
>;; Received 289 bytes from 204.16.253.33#53(ns3.no-ip.com) in 34 ms
>
>On the new box, I get nowhere:
>
># dig +trace www.olearycomputers.com
>; <<>> DiG 9.9.1-P1-RedHat-9.9.1-2.P1.fc17 <<>> +trace
>www.olearycomputers.com
>;; global options: +cmd
>. 517932 IN NS g.root-servers.net.
>. 517932 IN NS e.root-servers.net.
>[[some root ns snipped]]
>518025 IN RRSIG NS 8 0 518400 20120807000000 20120730230000 50398 .
>ICR2HkAQdy85QN3+i3lpLqoFc11zE/ZTNiBcb9F6dyglatHsX+dvWdJS 1laG5xA//M/
>OfFCALDy/xApk/Thnh20mTeEtXiiB0IEBFE17B3NgTggO gqbhk7sWt0m7SyDbXgHLbbFB
>+xyLMbT3bOaUUVf7470Cnx6eTI8Q5Hco PVs=
>;; Received 857 bytes from 143.43.32.170#53(143.43.32.170) in 5 ms
>;; connection timed out; no servers could be reached
>
>A straight hit to one of the root ns on the new box is equally as bad:
>
># dig @a.root-servers.net.
>; <<>> DiG 9.9.1-P1-RedHat-9.9.1-2.P1.fc17 <<>> @a.root-servers.net.
>; (1 server found)
>;; global options: +cmd
>;; connection timed out; no servers could be reached
>
>But, on the old box works like a champ:
>
># ssh ${old}  'dig @a.root-servers.net.'
>; <<>> DiG 9.3.4 <<>> @a.root-servers.net.
>; (2 servers found)
>;; global options: printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1160
>;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
>;; QUESTION SECTION:
>;. IN NS
>;; ANSWER SECTION:
>[[sniped]]
>;; Query time: 25 msec
>;; SERVER: 198.41.0.4#53(198.41.0.4)
>;; WHEN: Tue Jul 31 15:50:47 2012
>;; MSG SIZE rcvd: 512
>
>Can someone tell me why the root ns don't seem to like the new bind
>9.9 systems?


Since it's a new IP, are you sure ACLs are allowing any to 53/tcp and
53/udp on your new name server and from your name server to any on the
same ports?

What are you seeing in named's logs?

https://kb.isc.org/article/AA-00708/55/Why-does-BIND-log-messages-about-dis
abling-EDNS-or-reducing-the-advertised-packet-size