In message <20100608041158.ga30...@vacation.karoshi.com.>, bmann...@vacation.ka roshi.com writes: > So ISC has allowed BIND to build with some default zones being created. I th > ink this > is - to coin a phrase - suboptimal and yet more code I have to rip out of the > BIND distro... > but that is not the point of this missive... :)
Your free to rip it out or you can just turn it off in named.conf or you can change the defaults. > I will use two of the automatically created zones to illistrate a potential p > oint and then > ask a question. Mark has "bracketed" the IPv4 space with the following two z > one stanzas: > > 0.in-addr.arpa. > > and > > 255.255.255.255.in-addr.arpa. I've looked at the list of special purpost IPv4 addresses. It just happens that 0/8 and 255.255.255.255 are special purpose blocks. > clearly the first incalulates the entire 0/8 netblock... while the latter on > ly incalcualtes > an IPv4 /32 or a host entry. 255/8 is not special purpose, just 255.255.255.255. > historically, one would define the local network with preceeding zeros, e.g. > > 0.0.0.152 with a netmask of 255.255.255.0 is the host .152 on the loc > al network > > and only the "all-zeros" /32 or 0.0.0.0/32 was special - reserved for broadca > st. > > and yet we see the ISC code reserving the entire /8 as an automatic zone. 0/8 is the local network for a /8 sized network or don't you think nameservers should be able to handle that sized local networks. Not all networks are /24's. > If there was any consistancy here, ISC should have created the zone > > 255.in-addr.arpa. or the 255/8 netblock > > but they did not. They created a zone cut for a /32 - which (other than zome > of my own > older configurations) seems to be unique. The zones are consistant with RFC5735 and with operational practice. > So the question - how common do we expect /32 delegations to become in futur > e? >From IN-ADDR.ARPA or from some other zone to handle /25-/32 sized delegations without using the techniques in RFC2317? I know there are people that argue that one shouldn't do RFC2317 style delegations so for the latter I would say a lot. For the former I don't expect any unless we create special purpose blocks smaller than /24. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop