Reverse DNS w/5 octet numbers..

Re: Reverse DNS w/5 octet numbers..

From:

Date:

Time:

At 9:27 AM -0600 1/25/05, thomas sulentic wrote:
>Hello -
>
>Recently I was asked to help out with a particular problem a colleague was
>having in regards to a time out problem they were having with an in-house
>mail server..
>
>Turns out it had to do with a reverse record that was using a 5 octet number
>instead of the usual 4.. Something I have never come across..
>
>Is a 5 octet reverse new/old or something proprietary with their (PacBell)
>DNS servers?? The regular host file only contains a 4 octet IP number
>scheme.

The 5 number reverse records are for a classless subnet reverse zone.
PacBell (SBC) likes to use this format.

For a small subnet's reverse zone, the name of the zone is pretty
much arbitrary. The RFC that describes the technique suggests the
following:

n/m.c.b.a.in-addr.arpa.

The letters have the following meanings:

n = the network number - the last octet of the first (unusable)
address in the subnet. For example, in a 25-bit subnet, this will be
either 0 or 128.

m = the size of the netmask, a number between 25 and 30.

c, b, and a = the 3rd, 2nd, and 1st octets of the subnet. These are
the numbers you'd normally see in a class C subnet's reverse zone.

But this is just one possible system. In fact, the authors of the RFC
disagreed about it, and even mentioned their disagreement in the RFC
itself. Some equally valid approaches:

- The 5 octet solution, which is the same as above minus the "/m".
- Come up with a unique identifier for the customer, such as the
customer's name. Then use this format:

customer.c.b.a.in-addr.arpa.

- Delegate to a subdomain of the customer's forward domain, like this:

reverse.customer-domain.com.

In any case, it's customary (but not strictly required) that a PTR
record in the zone use the IP address' last octet as the first label
of the PTR record's name. For example, for the address 172.16.0.1, in
a 25-bit subnet where the reverse zone is named
"0.0.16.172.in-addr.arpa.", the PTR record will usually be named
"1.0.0.16.172.in-addr.arpa." However, in theory, this first label is
just as arbitrary as the zone's name.

>What was strange about this case was that nobody in PacBell was able to
>figure out what was up. Evidently, they went to this 5 octet number scheme
>w/o telling any of the tech support people..

That's pretty normal - tech support people are generally uninformed,
as counter-productive as this sounds. PacBell is not unique in this
regard.

>A 'quick fix' stumbled upon was to include 2 reverse zones.. One for the 4
>octet and one for the 5.. Very very odd..

I understand. This solution, while appearing to work, is actually not
a good idea. Better would be to figure out the source of the problem.
If you were to tell the list the subnet in question, I could do some
quick research.

>AND - even though the IP block was delegated to the client, and his
>master/slave DNS servers were his own, as registered by Netsol, he HAD to
>have the reverse managed by PacBell - if he wanted to avoid this time out
>problem..

Interesting. So his DNS servers were unable to come up with a reverse
lookup for his own addresses. This probably means a problem at
PacBell.

>PacBell says it for security.. Does this sound like something ordinary or
>out of the ordinary??

Ordinary, but it's not for security. It's to give the customer
control of their own reverse records when they don't have a full
class C (24 bit) subnet. Read the following RFC for more (but
confusing) information:

<http://www.faqs.org/rfcs/rfc2317.html>

Chris Buxton
Men & Mice - Making DNS Easy

Sales:
888/4-DPOINT

Support:
858/452-3696