Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 15:10, Mark Andrews kirjoitti:
> In message<4C516756.5060304 at qnet.fi>, Jukka Pakkanen writes:
>    
>> 29.7.2010 14:23, Mark Andrews kirjoitti:
>>      
>>> 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.
>>>
>>>        
>> 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.