29.7.2010 14:23, Mark Andrews kirjoitti:
In message<4c5134af.2080...@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.
Uuh... NOW I'm confused :)
There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.
ns1.qnet.fi should be the authoritive reverse DNS server for that IP
range, but it's not serving. Getting "recursion requested but not
available".
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.
62.142.220.0/24 has been delegated to out servers (qnet servers) and
have been working fine for years. And are working at them moment.
Mentioning 62.142.220.5 was just to inform that with similar
configuration, this /24 reverse dns works ok.
The problem is the 62.142.217.128/25 network, which should be delegated
to out servers, but for some reason they respond with "recursion needed".
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.
62.142.217.5 is NOT supposed to be delegated to our servers.
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.
I'm not asking that.
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.
If it's a slave, how can I administer the zone?
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
