new bind 9.9 and root NS

[Doug O'Leary]

Hi;

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

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?

Thanks for any hints/tips/suggestions.

Doug O'Leary

[Patrick Wallek]

Is there any IPv6 enabled on the new server?  If so, do you really need it?

I found a hit online where someone was having similar issues and traced it back to the queries trying to go out IPv6, but since it wasn't set up on their network they were getting nowhere.

[Doug O'Leary]

Hey;

Thanks for the reply.  

IPv6 is *not* configured on the network and, to the best of my knowledge, I have it deconfigured from bind: I have "-4" as the options in /etc/sysconfig/named, I can see the option in the process listing, and I have the listen-on-v6 option commented out in the named.conf file.  It took all those to get the ipv6 errors to stop spawning...

I was getting log-bombed with ipv6 errors when I first kicked it off and those configs were what it took to get them to stop...

Thanks; appreciate the help.

Doug O'Leary

[Matti_Kurkela]

The RRSIG records suggest the new BIND may be trying to use DNSSEC. This can significantly increase the time required between BIND startup and first response, as BIND must perform cryptographic validation of the zone information.

On the other hand, DNSSEC should reduce or eliminate an entire class of DNS-based security vulnerabilities, so it would be a good thing to make it work.

[Doug O'Leary]

Hey;

>> The RRSIG records suggest the new BIND may be trying to use DNSSEC

Bummer; that was one of my two theories. I was really hoping someone would say "The new DNS servers have to be registered w/internic in order to talk to root name servers"

While I'm a big fan of cryptography in general, I know nothing about dnssec in particular... Oh well, time for some research/learning.

Thanks for the repoly.

Doug O'Leary

[Doug O'Leary]

Hey;

It appears the problem is not DNS or DNSSEC related.  My latest test turned dns completely off and reconfigured the resolver to point to the old dns server.  Basically, the new dns server, at the moment, is little more than a linux OS.  I *still* can't get to the root name servers: 

# dig @f.root-servers.net

; <<>> DiG 9.9.1-P1-RedHat-9.9.1-2.P1.fc17 <<>> @f.root-servers.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Since it's not DNS related, the next obvious choice is network/firewall.  I have someone checking into that now.

I should have thought of the firewall sooner....  grrr.

Thanks for the responses.

Doug O'Leary