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-us...@lists.isc.org>,
Ryan Pavely <para...@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.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
