Subnet reverse delagation, RFC 2317

Mark Andrews marka at isc.org
Thu Jul 29 11:23:25 UTC 2010


In message <4C5134AF.2080302 at qnet.fi>, Jukka Pakkanen writes:
> Doing first time the RFC 2317 style subnet reverse DNS, and have a 
> problem with recursion.  When doing a query like "dig @ns1.qnet.fi -x 
> 62.142.217.200" is succeeds from the local network, but outside I get 
> "recursion requested but not available".  Our /24 reverse zones work 
> fine, the server knows it's the master and serves ok, like "dig 
> @ns1.qnet.fi -x 62.142.220.5".

There is NOTHING wrong here.  You are not testing the servers properly.

While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA,
it is not authoritative for 217.142.62.IN-ADDR.ARPA.  When you do
"dig @ns1.qnet.fi -x 62.142.220.5" you are asking for
PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve.

Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR
5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARPA
then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR
record at 5.128/25.217.142.62.IN-ADDR.ARPA.  It will then combine the
two answers and send it back to the original client.

> Recursion is only allowed for the local networks, but why the server 
> thinks recursion is needed in the first place?

Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA.

If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then
have all the information required to answer the query without asking
other services.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the bind-users mailing list