29.7.2010 15:10, Mark Andrews kirjoitti:
In message<4c516756.5060...@qnet.fi>, Jukka Pakkanen writes:
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 :)
You were confused before but didn't know it. :-)
I knew it, but after your message I was more confused...
You were asking the
wrong question to the wrong server. When you ask the right questions
to the right servers it works.
Well, the goal is to be able to administer the reverse DNS of that zone,
and at the moment it's not happening. So there is still something wrong.
Somewhere. I have to think about this from the endusers point of view as
well, and for them the reverse DNS is broken.
There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.
The only thing wrong is your understanding of what should be happening.
I can't agree with that. Reverse DNS for IP address range
62.142.217.128-254 is not working as we wish. So something is wrong
somewhere. Maybe my terminology about address spaces & name spaces is
off, but I suppose everybody at the list understands what I'm after.
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".
No. 128/25.217.142.62.IN-ADDR.ARPA has been delegated to your servers.
If 62.142.217.128/25 was delegated to you servers you would have
128 zones, 128.217.142.62.IN-ADDR.ARPA ... 255.217.142.62.IN-ADDR.ARPA.
The reverses for 62.142.217.128/25 is still served by the servers for
217.142.62.IN-ADDR.ARPA.
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
I think you have missed the difference between the two cases/networks,
one network of IP address is 62.142.217.128/25, the other one on
62.142.220.0/24, otherwise I don't understand where you get the number
"5" in the messages refering to this problem?
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.
Like said, this IP has nothing to do with us.
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.
But you are.
No I'm not :)
Please read the question section of the answers you get back.
;<<>> DiG 9.3.6-P1<<>> @ns1.qnet.fi -x 62.142.220.5
;; QUESTION SECTION:
;5.220.142.62.in-addr.arpa. IN PTR
This is not the 62.142.217.128/25 network, where I have this problem.
This is 62.142.220.0/24 network. Which works fine, regarding the reverse
DNS.
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?
You don't. You just have a copy of the zone locally. The administrator
for 217.142.62.IN-ADDR.ARPA changes it.
So we gat back to my original problem again, how can I administer the
zone on our server? What needs to be done, in addition or differently
of what's been done now.
Of course I could have asked "how can I have reverse DNS delegated and
working for IP addresses 62.142.217.128-254 to our Bind servers so that
we can administer the reverse DNS of these IP addresses", but instead I
tried to be more specific, tell what's been done, and what happens. And
asked we I'm doing wrong when the goal is not achieved.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
