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