PTR record handling in a subnetted network
Bob Vance
bobvance at alumni.caltech.edu
Mon Mar 5 23:20:14 UTC 2001
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.
More information about the bind-users
mailing list