DNS frustration

Kevin Darcy kcd at daimlerchrysler.com
Fri May 12 00:53:12 UTC 2006


Minimal input stream to nsupdate:

--- begin input stream ---
update add 1.40.110.10.in-addr.arpa. 86400 ptr foo.example.com.
send
--- end input stream ---

Optionally, you could prepend "server", "zone", "key", "prereq" etc. 
directives...

- Kevin

Chad Morris wrote:

>Bill,
>
>I'm still attempting to add reverse lookups via nsupdate...
>
>what would be the syntax for adding a PTR record with nsupdate to the  
>zone 40.110.10.in-addr.arpa?
>
>Chad
>
>
>On May 11, 2006, at 8:18 AM, Bill Larson wrote:
>
>  
>
>>On May 11, 2006, at 5:37 AM, Chad Morris wrote:
>>
>>    
>>
>>>I appreciate the time you have taken to explain many of these DNS  
>>>mysteries to me.  I'm kind of a newbie to DNS, but what I have set  
>>>up seems to work for the most part!  I obviously have some looking  
>>>over to do here...
>>>
>>>The one part I do not understand is this...
>>>
>>>      
>>>
>>>>I think that the simplest solution for you is, for example, with  
>>>>your 10.110.40.0/21 network, which incorporates the  
>>>>10.110.40.0/24, 10.110.41.0/24, 10.110.42.0/24, ...  
>>>>10.110.47.0/24 networks, is to define separate zones for each of  
>>>>these "/24" subnets.  Instead of just one reverse zone, in this  
>>>>case, you really need to have eight zones.  (You have some, but  
>>>>not all of these sub-subnets.)
>>>>        
>>>>
>>The "in-addr.arpa" reverse DNS operates on eight bit network  
>>boundaries.  For example, there are the following in-addr.arpa  
>>delegations possible:
>>
>>	10.in-addr.arpa
>>	110.10.in-addr.arpa
>>	40.110.10.in-addr.arpa
>>
>>The first is a 10.0.0.0/8 network (10.0.0.0-10.255.255.255), the  
>>second is for a 10.110.0.0/16 network (10.110.0.0-10.110.255.255),  
>>and the third is for a 10.110.40.0/24 network  
>>(10.110.24.0-10.110.40.255).  The in-addr.arpa reverse DNS  
>>naturally breaks on eight bit subnet boundaries.
>>
>>Your 10.110.40.0/21 network covers the range of  
>>10.110.40.0-10.110.47.255.  This range of addresses can't be  
>>handled in the in-addr.arpa delegation as a single zone.  All I was  
>>suggesting is that you may want to insure that ALL of the possible  
>>range of IP addresses that you use are configured in DNS for your  
>>in-addr.arpa delegation.
>>
>>What this means is that for your 10.110.40.0/21 network you need to  
>>have eight in-addr.arpa zones defined.  There needs to be zones for:
>>
>>	40.110.10.in-addr.arpa
>>	41.110.10.in-addr.arpa
>>	42.110.10.in-addr.arpa
>>	43.110.10.in-addr.arpa
>>	44.110.10.in-addr.arpa
>>	45.110.10.in-addr.arpa
>>	46.110.10.in-addr.arpa
>>	47.110.10.in-addr.arpa
>>
>>to cover this whole 10.110.40.0/21 network.  You have some of  
>>these, but not all.  All I am suggesting is that you fill out the  
>>whole range to insure that you are covered.  It may be that some of  
>>these in-addr.arpa zones are not populated at the moment.  If in  
>>the future any of these zones are actually used, then you are  
>>prepared - rather than trying to play catch-up.
>>
>>Bill Larson
>>
>>
>>    
>>
>
>
>
>
>
>  
>




More information about the bind-users mailing list