forwarding rfc1918 queries, stub zones

[Kevin Darcy]

Will Yardley wrote:

>On 2004-02-02, Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>  
>
>>Will Yardley wrote:
>>    
>>
>
>[ Thanks for the long response. My head is still spinning, but doing my
>best to digest all of that. ]
>
>  
>
>>>Maybe a FAQ, but what's the simplest way (if you have a split
>>>caching-only / authoritative setup) to forward queries for rfc1918
>>>reverse lookups to the authoritative machine? Can I just setup a stub
>>>zone for 10.in-addr.arpa. and forward all those queries to the
>>>authoritative nameservers (even if the zones we're running are actually
>>>more specific)?
>>>
>>>Also, what should the "master" of a stub zone be set to - the server
>>>it's forwarding queries to?
>>>      
>>>
>
>  
>
>>Set up a 10.in-addr.arpa on a master. For redundancy, have one or more
>>other nameservers be published slaves for the zone.
>>    
>>
>
>The problem (and I realize that this is somewhat specific to our
>situation, perhaps), is that our DNS zones are all generated
>automagically (by our system), and it generates separate zone files for
>each /24 we're using in rfc1918 space.
>
>For example, say I have 34.3.10.in-addr.arpa. and 35.3.10.in-addr.arpa.
>setup on our master authoritative nameserver and 2 slaves. However, I
>don't want to have to make any special changes I were to add
>36.3.10.in-addr.arpa. or even 10.3.10.in-addr.arpa... other than adding
>those zones themeslves. Could I just create 10.in-addr.arpa. and do a
>wildcard delegation -- something like this:
>
>$ORIGIN 10.in-addr.arpa.
>*   IN NS ns1.example.com.
>    IN NS ns2.example.com.
>    IN NS ns3.example.com.
>
>Or (as below), would forwarding the whole 10.in-addr.arpa. zone to
>ns{1-3}.example.com Just Work without setting up 10.in-addr.arpa. at all
>on those machines (provided zones for any 10 block IPs we're actually
>using are setup individually, and are all setup on the same 3 machines)?
>
You should still set up a 10.in-addr.arpa, because even if you're only 
using part of that address range, it should not be the case that common, 
day-to-day mistypings of your internal IP addresses cause bogus 
*.*.*.10.in-addr.arpa queries to pollute the Internet DNS 
infrastructure. Defining 10.in-addr.arpa in your resolution path stops 
those queries from ever reaching the Internet. I have, for instance, 
defined all of the RFC 1918 ranges in my border nameservers, even though 
we use RFC 1918 quite sparingly these days (which is quite ironic since 
one of the RFC 1918 co-authors worked here at the time :-)

>>b) define all of the descendant zones as slave zones (which can be a
>>maintenance nightmare, you might not be able to do zone transfers of
>>all of those zones, or it would use up too much bandwidth)
>>    
>>
>
>Right - in this case, it would probably be a management headache since
>the zones on the authoritative servers (master and slave) are all
>managed by machine, and (currently), the caching-only machines are
>managed by hand - thus I'm trying to keep the config on these as simple
>as possible, and the number of slave zones to a minimum.
>
>  
>
>>or c) define 10.in-addr.arpa itself as a "type forward" zone, pointing
>>to alternate forwarders which can resolve all names in that part of
>>the namespace (just be sure these alternate forwarders either honor
>>recursion or are authoritative for all of the descendant zones as in
>>(b) above).
>>    
>>
>
>This is my preferred solution (see above) - except that I'd forward to
>the 3 authoritative nameservers which already serve the various 10 net
>zones.
>
Generally I prefer stub zones to forwarding. Works more efficiently for 
deep hierarchies (because with stub zones, the delegation information 
for intermediate levels of the hierarchy are cached and can be used to 
"short-circuit" future related queries), handles situations where the 
target servers don't honor recursion (it is generally recommended to 
turn off recursion for authoritative servers), and in most versions of 
BIND, provides much better resilience in the face of failures (using the 
RTT-based algorithm to quickly penalize a downed server, and then 
eventually redeeming it when it comes back on-line, versus the 
try-in-sequential-order-with-timeout algorithm that most versions of 
BIND use for forwarding). In your context, forwarding would only be 
appropriate if you lacked connectivity to all of the nameservers of one 
or more descendant zones, and even then, it might be better to just 
define those particular zones as "type forward" instead of the whole 
namespace hierarchy.

                                                                         
                     - Kevin