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