Delegating a /24 out of a /16.

Kevin Darcy kcd at daimlerchrysler.com
Wed Jan 19 00:23:49 UTC 2005


Sam Hayes Merritt, III wrote:

>On Tue, 18 Jan 2005, Kevin Darcy wrote:
>
>  
>
>>Well, the problem is on the 216.82.202.14 server.
>>    
>>
>
>Yep. And this is just a test zone to see if I can make delgating a /24
>work. This also is not the server it will run on once working, however
>the other servers I have tried doing this same thing on come up with the
>same error.
>
>  
>
>>Do you control that server?
>>    
>>
>
>yes
>
>  
>
>>What does named.conf on that server say about the 5.155.10.IN-ADDR.ARPA
>>zone?
>>    
>>
>
>It is my understanding that since I am delegating a /24 out of a /16, I
>have to do that from the parent, IE the 155.10.in-addr.arpa zone.
>(What few resources I can find, including DNS & Bind seem to hint at that)
>
>How else do you delegate a /24 to a different nameserver?
>
Do a non-recursive query (add a "+norec" flag to dig's command-line 
arguments) against the parent server if you want to see the referral 
information for a delegated subzone. If you do a recursive query, then 
the query will in most cases be answered by the child nameserver(s), 
which will tend to return unhelpful responses like SERVFAIL if the zone 
is not set up on it/them.

- Kevin

>>Are there error messages on startup, when the nameserver tries to load
>>the zone file?
>>    
>>
>
>no.
>
>
>
>Thanks,
>
>sam
>
>  
>
>>>We have a /16 from ARIN. We want to delegate a /24 out of that to a
>>>customers nameservers. In the past, when we had smaller than a /16, a SWIP
>>>would take care of that for us, however since we have the entire /16, we
>>>have to do it ourselves now.
>>>
>>>Here's the relevant sample parts of my named.conf:
>>>
>>>zone "155.10.IN-ADDR.ARPA" {
>>>       type master;
>>>       file "10.155.db";
>>>};
>>>
>>>
>>>And here's 10.155.db:
>>>
>>>$TTL 86400
>>>; 10.155.db
>>>;
>>>; Edit History
>>>; date:         who:                    what:
>>>; 12/06/00      Auto-Generated          Forward Mapping File
>>>;
>>>; Origin added to names not ending in a dot: 155.10.IN-ADDR.ARPA
>>>;
>>>
>>>@                               IN      SOA     ns1.lsn.net. root.lsn.net.
>>>(
>>>                               2005011801      ; serial
>>>                               10800           ; refresh after 3 hours
>>>                               3600            ; retry after 1 hour
>>>                               604800          ; expire after 1 week
>>>                               86400 )         ; minimum TTL of 1 day
>>>
>>>                       IN      NS      ns5.lsn.net.
>>>
>>>5      IN      NS      ns8.lsn.net.
>>>
>>>
>>>A dig for the /16 comes back with the expected response.
>>>dig @216.82.202.14 155.10.in-addr.arpa any
>>>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
>>>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>>;; QUERY SECTION:
>>>;;	155.10.in-addr.arpa, type = ANY, class = IN
>>>
>>>;; ANSWER SECTION:
>>>155.10.in-addr.arpa.	1D IN SOA	ns5.lsn.net. root.lsn.net. (
>>>					2005011802	; serial
>>>					3H		; refresh
>>>					1H		; retry
>>>					1W		; expiry
>>>					1D )		; minimum
>>>
>>>155.10.in-addr.arpa.	1D IN NS	ns5.lsn.net.
>>>
>>>;; ADDITIONAL SECTION:
>>>ns5.lsn.net.		13h35m12s IN A	216.82.202.14
>>>
>>>
>>>
>>>But a dig for the delegated /24, comes back with a SERVFAIL.
>>>dig @216.82.202.14 5.155.10.in-addr.arpa any
>>>
>>>; <<>> DiG 8.3 <<>> @216.82.202.14 5.155.10.in-addr.arpa any
>>>; (1 server found)
>>>;; res options: init recurs defnam dnsrch
>>>;; got answer:
>>>;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6
>>>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>>>;; QUERY SECTION:
>>>;;	5.155.10.in-addr.arpa, type = ANY, class = IN
>>>
>>>;; Total query time: 23 msec
>>>
>>>
>>>
>>>
>>>What part of this am I not getting correct. Looking at DNS & Bind
>>>9.5.1 Subnetting on an Octet Boundary, this should be correct.
>>>
>>>
>>>
>>>Thanks,
>>>
>>>sam
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>
>>
>>    
>>
>
>
>
>
>
>  
>




More information about the bind-users mailing list