Re: new bind 9.9 and root NS
-Original Message-
From: dkole...@olearycomputers.com dkole...@olearycomputers.com
Organization: http://groups.google.com
Date: Tuesday, July 31, 2012 2:16 PM
To: comp-protocols-dns-b...@isc.org comp-protocols-dns-b...@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 2012080700 2012073023 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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: new bind 9.9 and root NS
On 08/05/2012 23:05, Michael Hoskins (michoski) wrote: 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. +1 https://www.dns-oarc.net/oarc/services/replysizetest -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: new bind 9.9 and root NS
-Original Message- From: Doug O'Leary dkole...@olearycomputers.com Date: Monday, August 6, 2012 9:58 AM To: 'Doug Barton' do...@dougbarton.us, Mike Hoskins micho...@cisco.com Cc: comp-protocols-dns-b...@isc.org comp-protocols-dns-b...@isc.org Subject: RE: new bind 9.9 and root NS After the network admin verified there was no firewall rule differences, we powered off the old secondary server and re-IPed the new one with the old secondary. The old secondary is able to get to the root nameservers w/o issue. Once we re-IPed the new one, it still was unable to get to the root nameservers via dig. Just checking the obvious; no host-based firewall on the new box? Is it the same OS? I also downloaded and installed lft - layer four traceroute (wonderful program, that one is). Lft was unable to get *anywhere* using udp regardless of what the IP address of the new system is. So, there's something with the virtualization software, vmware, which is preventing udp packets. There are some web sites saying the same thing so this isn't completely out of the blue. The client's opening a service call with vmware to see if there's a resolution. I'm serving several thousand clients using VMware + BIND, so I'm curious to see where this goes. :-) Which VMware product are you using, and what host platform? Thanks! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
new bind 9.9 and root NS
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 2012080700 2012073023 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
--
Senior UNIX Admin
O'Leary Computers Inc
linkedin: http://www.linkedin.com/dkoleary
Resume: http://www.olearycomputers.com/resume.html
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
