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