strange reverse response
rodney.j.mertz at bt.com
rodney.j.mertz at bt.com
Wed Sep 20 22:53:04 UTC 2006
From: Chris Buxton [mailto:cbuxton at menandmice.com]
Sent: Wed 9/20/2006 5:50 PM
To: Mertz,RJ,Rodney,JPU4 R
Cc: comp-protocols-dns-bind at isc.org
Subject: Re: strange reverse response
There's a lame referral from 40.140.217.in-addr.arpa to itself
(coming from the bt.net servers). The +trace option to dig is pretty
stupid with regard to referrals, so it just keeps on keepin' on in
this case. Real name servers recognize that as an invalid response
and refuse to continue.
There are three obvious solutions to this:
- BT could talk to RIPE and get some larger netblock reverse zone,
such as 140.217.in-addr.arpa, delegated to them. This assumes that BT
has such a netblock, which is what their server actually claims if
you ask it.
- BT could talk to RIPE and get the /24 reverse zone delegated
directly to you, without any stop on the way at BT.
- BT could slave your reverse zone, so that the four bt.net servers
listed by RIPE are authoritative for your reverse zone.
Chris Buxton
Men & Mice
Take control of your network
On Sep 20, 2006, at 3:11 PM, Rodney J Mertz wrote:
> OK can someone help explain what is wrong here. A reverse search
> without the
> +trace option fails:
> -------------------------
> # dig -x 217.140.40.10
>
> ; <<>> DiG 9.2.4 <<>> -x 217.140.40.10
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58147
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ----------------------------
> But if you add +trace it works properly!
>
>
> # dig -x 217.140.40.10 +trace
>
> ; <<>> DiG 9.2.4 <<>> -x 217.140.40.10 +trace
> ;; global options: printcmd
> .. 64752 IN NS e.root-servers.net.
> .. 64752 IN NS f.root-servers.net.
> .. 64752 IN NS g.root-servers.net.
> .. 64752 IN NS h.root-servers.net.
> .. 64752 IN NS i.root-servers.net.
> .. 64752 IN NS j.root-servers.net.
> .. 64752 IN NS k.root-servers.net.
> .. 64752 IN NS l.root-servers.net.
> .. 64752 IN NS m.root-servers.net.
> .. 64752 IN NS a.root-servers.net.
> .. 64752 IN NS b.root-servers.net.
> .. 64752 IN NS c.root-servers.net.
> .. 64752 IN NS d.root-servers.net.
> ;; Received 292 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>
> 217.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET.
> 217.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET.
> 217.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE.
> 217.in-addr.arpa. 86400 IN NS NS-EXT.ISC.ORG.
> 217.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET.
> 217.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET.
> 217.in-addr.arpa. 86400 IN NS NS3.NIC.FR.
> ;; Received 223 bytes from 192.203.230.10#53(e.root-servers.net) in
> 73 ms
>
> 40.140.217.in-addr.arpa. 172800 IN NS ns0.bt.net.
> 40.140.217.in-addr.arpa. 172800 IN NS ns1.bt.net.
> 40.140.217.in-addr.arpa. 172800 IN NS ns2.bt.net.
> ;; Received 104 bytes from 202.12.29.59#53(SEC1.APNIC.NET) in 219 ms
>
> 40.140.217.in-addr.arpa. 300 IN NS ns2.syntegra.com.
> 40.140.217.in-addr.arpa. 300 IN NS ns3.syntegra.com.
> 40.140.217.in-addr.arpa. 300 IN NS ns4.syntegra.com.
> 40.140.217.in-addr.arpa. 300 IN NS ns1.syntegra.com.
> ;; Received 128 bytes from 217.35.209.188#53(ns0.bt.net) in 114 ms
>
> 10.40.140.217.in-addr.arpa. 21600 IN PTR
> relay11.mms.eu.btsyntegra.com.
> 40.140.217.in-addr.arpa. 21600 IN NS ns3.syntegra.com.
> 40.140.217.in-addr.arpa. 21600 IN NS ns4.syntegra.com.
> 40.140.217.in-addr.arpa. 21600 IN NS ns1.syntegra.com.
> 40.140.217.in-addr.arpa. 21600 IN NS ns2.syntegra.com.
> ;; Received 232 bytes from 150.143.80.2#53(ns2.syntegra.com) in 204 ms
>
>
>
>
-----------------
Thanks. I'll speak to them about updating their records.
..Rod
More information about the bind-users
mailing list