8.4.4 reverse zone problems

Kevin Darcy kcd at daimlerchrysler.com
Wed May 26 01:38:30 UTC 2004


David Price wrote:

>  
>
>>Ok, though this really asserts authority for the whole /16.  This will
>>be a Bad Thing when you try to resolve addresses that are in
>>10.20.0.0/16 but not in 10.20.192.0/20.
>>
>>    
>>
>I try to avoid Bad Things if possible. What is the correct way to handle 
>this type (/20) of delegation?
>
>  
>
>>What do you get from dig?  Timeout?  NXDOMAIN?  Somehting else?  Any
>>errors when you load the zone?
>>    
>>
>
>When I use dig I get nothing back, there is no answer section and no 
>authority section, just a query section and the summary.
>
Sounds like a "NODATA" response, i.e. a NOERROR RCODE but 0 answers. It 
means the name exists, but no records exist of the type requested. You 
*did* specify PTR as the query type, right? The default query type for 
dig is "A".

>>Concepts like "class A/B/C/D" and CIDR notation are routing elements,
>>and the things in DNS that look similar to them are really just naming
>>conventions.  
>>    
>>
>
>If this is true why is an entire RFC (2317) devoted to define how to 
>delegate smaller-than-C-block sized address spaces? You even used CIDR 
>notation in describing a problem above. I know CIDR numbers and the 
>address classes are not directly applicable to DNS but they are 
>inextricably part of IPv4.
>
The in-addr.arpa tree is, by convention, based on an octet 
*representation* of IPv4 addresses, but that doesn't mean DNS knows 
about the different classes of networks, or is capable of delegating 
normally between octet boundaries. The problem that RFC 2317 addresses 
is the common one where an organization gets delegated some chunk of 
address space smaller than a /24, and they want to control their 
reverse-resolution, but don't want the hassle of getting their ISP to 
delegate each address (think of each of those as a /32, thus on an octet 
boundary and thus delegable in the normal way) as a separate zone. Since 
they can't use normal delegation -- which is limited to octet boundaries 
-- some other mechanism must be used to "delegate" (scare quotes there) 
the relevant range(s) to their nameservers. RFC 2317 recommends CNAME 
records to accomplish this "delegation". If you're at or above the /24 
level, though, you can delegate normally, and don't need to follow RFC 2317.

>  There's no reason that the zone
>  
>
>>"192.20.10.in-addr.arpa" couldn't have 500 records in it, for example,
>>or 1000.
>>
>>    
>>
>Does that mean that a "192.20.10.in-addr.arpa" zone would be able to 
>include pointer records for 200.20.10.in-addr.arpa and 
>198.20.10.in-addr.arpa and BIND would respond authoritatively to queries 
>against both of them?
>
No, those would be out-of-zone records. I'm not sure what Jim was 
getting at above -- sure, that zone could have 1000 records in it, but 
they couldn't all be useful reverse records. Only 256 (arguably less, if 
you subtract network and broadcast) names are meaningful as reverse 
records in a zone at the /24 level. Of course, one name can own multiple 
PTRs, or records of type other than PTR, but I don't see the point, to 
be quite honest...

- Kevin



More information about the bind-users mailing list