IPv4 not working reverse on > /24 cidr

Ryan Pavely paradox at nac.net
Mon Jul 22 16:29:06 UTC 2013


I only mentioned rfc1918 as I am directly hosting them, versus my 
upstream pointing cnames at me for other blocks.  I didn't expect 
anything different about them.


I thought, and it worked in the past (2008/2009 perhaps), that having 
the full cidr notation and such in the named.conf files you are doing 
the link.

e.g.

zone "0/27.1.10.10.IN-ADDR.ARPA" {
         type master;
         file "/usr/named/rev/10.10.1.0-27.rev";
         };




And then that file announces
     Origin 0/27.1.10.10.IN-ADDR.ARPA.



I always thought I had to break up the CIDR's into the proper blocks so 
then my downstream customer can slave that partial zone.  I don't want 
them slaving 10.10.1/24... etc.. So to do that you break up the block 
into all its parts, each with an origin, ttl, etc etc...
  So now it appears I need both the 10.10.1.rev and each 
10.10.1.XX-YY.rev file.  Seems redundant.



   Ryan Pavely
    Net Access Corporation
    http://www.nac.net/

On 7/22/2013 12:17 PM, Barry Margolin wrote:
> In article <mailman.879.1374506938.20661.bind-users at lists.isc.org>,
>   Ryan Pavely <paradox at nac.net> wrote:
>
>> So that would suggest any time any block > a /24 is hosted you must
>> actually host the parent zone, pointing to the larger cidr, and then
>> have your normal files for each cider in that block.
> Of course. How else do you expect DNS to figure out that it should look
> in the RFC 1918 zone? The CNAMEs are the link between the normal reverse
> DNS name and the CIDR-style name. There's nothing automatic about RFC
> 1918.
>



More information about the bind-users mailing list