Subnet reverse delagation, RFC 2317

[Mark Andrews]

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. :-)  You were asking the
wrong question to the wrong server.  When you ask the right questions
to the right servers it works.

> 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.

> 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".

DNS servers are authoritative for namespaces NOT address spaces.
Reverse zone use a specific mapping from address space to namespace
(i.e. reverse the decimal values of the octets and append IN-ADDR.ARPA).
RFC 2317 the maps from the reverse namespace (x.x.x.x.in-addr.arpa)
to a second namespace using CNAME records (in this case
x.128/25.x.x.x.in-addr.arpa). 

> > 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.ARP
> A
> > 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.

But you are.  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 

> > 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.

RFC 2317 states that servers for the "parent" should serve the "slave"
zone.  The reverse is also true but is not stated.

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