Authoritative for a /27 network.

[Mark.Andrews at nominum.com]

> Baumann, Sean C. wrote:
> 
> > Hello,
> >
> > I browsed the list archive and read RFC2317, but I still have questions
> > about how to set up our BIND server to be authoritative for a /27 network.
> > I understand that our ISP (who actually owns the entire class C) should
> > create a zone file that delegates our particular subnet to us.  They must
> > also create CNAME records in their reverse zone as specified in the RFC2317
> .
> > However, on our DNS server, if we create a zone for say
> > "32/27.3.2.1.in-addr.arpa",
> 
> I'd personally prefer a name more like 32-63.3.2.1.in-addr.arpa. I've heard
> that some resolvers don't like slashes. Of course, the decision is ultimately
> up to your ISP, since they are the ones who are going to be creating the
> CNAMEs. You have to abide by their preferences if you want this to work.

	Actually you and you ISP have to agree on the name as it can be
	any name.  32-63.3.2.1.in-addr.arpa works around a bug in a BIND
	betas that got included in certain OS releases.

> 
> > our server will not resolve the reverse
> > addresses (but can resolve the forward for that domain).
> 
> It *will* resolve the PTR's, because nameservers will follow the CNAMEs they
> find in the /24 zone. That will bring them to your server.
> 
> For instance, ignoring caching for a moment, a nameserver trying to resolve
> 54.3.2.1.in-addr.arpa will first get the following CNAME from your ISP's serv
> er
> when they do the PTR lookup:
> 
> 54.3.2.1.in-addr.arpa    IN    CNAME    54.32-63.3.2.1.in-addr.arpa
> 
> Following the normal CNAME logic, since you are authoritative for
> 32-63.3.2.1.in-addr.arpa, they will then ask you about the name
> 54.32-63.3.2.1.in-addr.arpa, and since you have the PTR you will give them th
> e
> final, definitive answer.
> 
> There's really nothing that magical about RFC 2317. It just describes somethi
> ng
> people have been doing with forward records for ages: creating CNAMEs in one
> zone pointing to records in another zone, so that someone else can manage the
> namespace transparently to the users. The only difference is, RFC 2317 brings
> that wisdom to bear on the in-addr.arpa tree and PTR records, to help people
> deal with the > /24 problem.
> 
> > Do we have to set
> > up a zone file for "3.2.1.in-addr.arpa" on our server as well with the CNAM
> E
> > records as well?

	I always recommend that you secondary the parent zone as
	you will then be able to resolve internal addresses if you
	become disconnected from your ISP.

> 
> Since you're not delegated that zone, how do you expect anyone to know to ask
> you about names in it?
> 
> Just create the zone that contains whatever your ISP's CNAMEs point to.
> Technically, this doesn't even need to be in the in-addr.arpa tree, but that'
> s
> the usual convention.
> 
> 
> - Kevin
> 
> 
> 
	Mark
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com