non-octet boundaries

[Kevin Darcy]

Kevin wrote:

> Having read through many articles, archives, and even DNS & BIND 3rd ed., I
> still have a few questions regarding this type of DNS. These questions all
> pertain to my subnet, which is a class A and a subnet mask of
> 255.255.255.248 (6 usable IPs)
>     1. If the ISP is providing fourth octet delagation, is there a need to
> have the db.mysubnetnumber  on the local (my) DNS server? Will there be two
> copies
>     of this db, one at the ISP and one local on my DNS server?
>
>     2. In addition to the db.mysubnetnumber record, there will have to be a
> db for each IP number, something like db.64.64.199.200, db.64.64.100.201,
> etc.. Same question as above, where do these records live; ISP or my dns
> server or both?

Simply put, there are two basic ways for an ISP to handle "delegation" of
maintenance for a chunk of reverse address space smaller than a /24 (so-called
"classless delegation"):

1) Delegate each IP address as a separate DNS zone to the subscriber

2) Create an alias for each IP address, pointing to names in a zone controlled
by the subscriber

You and your ISP have to pick which method and implement it.

With method (1), they add NS records for each address, referring to your
master and its slave(s). Then you create the zone definitions on the master
and slave(s), and, on the master, generate a zone file for each address,
consisting of just the mandatory SOA, NS record(s) and of course the
PTR record itself. Since you only have 6 addresses, this wouldn't be a big
deal, but for folks with, say, 126 addresses in their range, they
understandably prefer not to have to create 126 zonefiles and zone
definitions.

With method (2), they add a CNAME record for each address. You pick what zone
should contain the targets of those aliases -- either an existing zone, or a
new one you create for the purpose. Note that if you choose to create a new
zone for this, which is a subzone of the "real" /24 reverse zone (e.g. if you
choose the zone 248/29.3.2.1.in-addr.arpa as the "container" zone, off of
3.2.1.in-addr.arpa, as RFC 2317 suggests), then your provider will need to do
some extra work to create the delegation to your server(s). Note further that
some resolvers will choke on the "/" character in a domain name, so many folks
change RFC 2317's "/" into a "-" instead, e.g. 248-29.3.2.1.in-addr.arpa. My
personal preference would be instead to put those PTR's into one of my regular
"forward" zones, or a special subzone thereof, e.g. extranet1.example.com,
thus precluding the need for any messy cross-organizational delegations. Then
you just populate your "container" zone with the appropriate PTR records.
Since this method requires less new zones to be defined/created, it is more
suited to larger address spaces, especially if the PTR targets follow a
last-octet-based naming convention which would allow the $GENERATE directive
to be used.

Note that in *neither* case should you be defining the /24 reverse zone, e.g.
3.2.1.in-addr.arpa, as master on your server. That zone is delegated to your
provider's server -- if you also define it on yours, then this is a
"rogue" copy of the zone, which could potentially propagate bogus data. It
makes more sense to just be a slave for that zone from your provider.


- Kevin