PTR record handling in a subnetted network

[Bob Vance]

Personally, and as I have said here before, I would prefer to have the
ISP's CNAMEs simply point into my forward zone.

At least 2 benefits:
 . no new zone delegations nor NS RRs for anybody to worry about,
 . the PTRs can sit right next to their corresponding forward RR.

No one has yet given me a reason for *not* doing that.

-------------------------------------------------
Tks        | <mailto:BVance at sbm.com>
BV         | <mailto:BobVance at alumni.caltech.edu>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430           11455 Lakefield Dr.
Fax 770-623-3429           Duluth, GA 30097-1511
=================================================





-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
Behalf Of Joseph S D Yao
Sent: Monday, March 05, 2001 4:30 PM
To: David Tonhofer
Cc: bind-users at isc.org
Subject: Re: PTR record handling in a subnetted network



On Fri, Mar 02, 2001 at 11:43:44PM +0100, David Tonhofer wrote:
...
> This worked for bind 8 and also works for bind 9, but it's not how
> things should be according to RFC2317

Sure it is.

-----------------------------------------------------------------------
4. Classless IN-ADDR.ARPA delegation

   Since a single zone can only be delegated once, we need more points
   to do delegation on to solve the problem above.  These extra points
   of delegation can be introduced by extending the IN-ADDR.ARPA tree
   downwards, e.g. by using the first address or the first address and
   the network mask length (as shown below) in the corresponding address
   space to form the the first component in the name for the zones.  The
   following four zone files show how the problem in the motivation
   section could be solved using this method.
-----------------------------------------------------------------------

Note the "e.g." - this is ONE way [and not a common way] to do this.
It continues,

-----------------------------------------------------------------------
   The examples here use "/" because it was felt to be more visible and
   pedantic reviewers felt that the 'these are not hostnames' argument
   needed to be repeated.  We advise you not to be so pedantic, and to
   not precisely copy the above examples, e.g.  substitute a more
   conservative character, such as hyphen, for "/".
-----------------------------------------------------------------------

Note "not precisely copy".  Indeed, you can take it outside of the
"in-addr.arpa" domain entirely:

-----------------------------------------------------------------------
5.2 Alternative naming conventions

   As a result of this method, the location of the zone containing the
   actual PTR records is no longer predefined.  This gives flexibility
   and some examples will be presented here.

   An alternative to using the first address, or the first address and
   the network mask length in the corresponding address space, to name
   the new zones is to use some other (non-numeric) name.  Thus it is
   also possible to point to an entirely different part of the DNS tree
   (i.e. outside of the IN-ADDR.ARPA tree).  It would be necessary to
   use one of these alternate methods if two organizations somehow
   shared the same physical subnet (and corresponding IP address space)
   with no "neat" alignment of the addresses, but still wanted to
   administrate their own IN-ADDR.ARPA mappings.
...
-----------------------------------------------------------------------

> Notice the second $ORIGIN which actually gives the base address of my
> network. Question: do I have to set it up like this because my
> provider is doing something wrongly/weirdly? I tried some other
approaches
> but mainly got 'out of zone' errors from BIND.

YOU DO NOT NEED TO HAVE A "$ORIGIN".

NOBODY NEEDS A "$ORIGIN".

Why do so many people think they need a "$ORIGIN"?  I find that it
confuses them more often than not.  Then they get "out of zone" errors.
As you did.  (But the code the way you have it requires the "$ORIGIN"s
- you can't remove them without correcting the code.  If you know how
to do this without "out of zone" errors, fine.)

Start from the default ORIGIN passed in with the zone {} statement, and
stick with it.

There are RARE cases where a "$ORIGIN" clarifies a previously muddied
situation.

Having ranted about that almost enough ...

You do have to use the same names that your ISP does.  I would not do
it the way they did [I would find a way to include the netmask], but
that doesn't make their way wrong or weird.

...
> Question: *Who* says that
>
> "225.217.154.194.in-addr.arpa. 68781 IN  CNAME
> 225.224.217.154.194.in-addr.arpa."
>
> because it's definitely not my nameserver...is it?

It's your ISP, who is delegating you the subnet.

However, it could be you if you and your ISP "slave" to each other.
-----------------------------------------------------------------------
5.1 Recommended secondary name service

   Some older versions of name server software will make no effort to
   find and return the pointed-to name in CNAME records if the pointed-
   to name is not already known locally as cached or as authoritative
   data.  This can cause some confusion in resolvers, as only the CNAME
   record will be returned in the response.  To avoid this problem it is
   recommended that the authoritative name servers for the delegating
   zone (the zone containing all the CNAME records) all run as slave
   (secondary) name servers for the "child" zones delegated and pointed
   into via the CNAME records.
-----------------------------------------------------------------------

--
Joe Yao				jsdy at cospo.osis.gov - Joseph S. D. Yao
COSPO/OSIS Computer Support					EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.