Reverse DNS RFCs and Recommendations

Mailman List Mirror (Read Only)
1

I've been (probably needlessly) pouring over the Reverse DNS RFCs for long enough to actually have questions about a subject that should be relatively unimportant. I do want to make sure that we set up our reverse DNS correctly and most efficiently the first time so that we don't irritate other network operators with difficult regex based filtering ( http://www.gossamer-threads.com/lists/nanog/users/113633 ) and we don't have to change things as per a recommendation down the road.

RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
When using IP addresses in host names, their numbers SHOULD be
   separated by '.'s (dots) rather than any meta character such as a '-'
   (dash) and expressed in decimal. Host names SHOULD NOT use the '_'
   (underscore) character, host names for hosts with any form of SMTP
   mail service MUST NOT use the '_' (underscore) character. It is
   preferable to use the IP address in reverse format in the same way
   the the IN-ADDR.ARPA. domain is defined.

Now since it is only a first revision draft I'm taking what it has to say with a grain of salt and it seems has taken quite a bit of criticism on forums. I'm also not singling out on Time Warner, WOW, Comcast or Charter for their naming conventions nor do I think they are bad, I'm just using them as examples because they are local, well-known ISPs.

Actual Examples:
cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX
d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX
c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX
24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX

*Most ISP Reverse DNS Hostnames (from what I've observed) seem to use the dash "-" character with the forward format, as opposed to the reverse IN-ADDR.ARPA. dotted scheme as recommended in the draft
*Comcast and Charter all have geographic based furthest-right-hand tokens.
*Charter, WideOpenWest, Time Warner, and Comcast all have some acronym that is not immediately clear, at least to me (HSD - High Speed Data?, BYCY - Bay City, MI?, DIM - Dynamic IP Mapping?, STNY - Southern Tier New York?)

Which finally brings me to my questions:
It seems like the unspoken de facto that mail admins appreciate given the IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld". This seems perfectly acceptable, it's short, detailed and to the point. Is there really anything bad about this?

What, if any would you name a network, gateway, broadcast address? Should the PTR be empty?

<tinfoilhat> I've seen a lot about naming what type of technology it is (wireless, adsl, cable, etc.) in order to filter out the "high speed spammers". It seems to me that this would open up the likelihood of a targeted attack. We've all heard of security though obscurity and of course no one relies on it but we have to face the fact there are CVEs every day for various networking hardware/firmware. If an attacker can query DNS and find out that the IP is for wireless they could filter all wireless gear exploits. Is this still a good practice given the abundance of high speed data connections or is this just opening yourself up to reconnaissance?</tinfoilhat>

There is a Merit Network mailing list discussion that outlines most of what I've read that can be found here ( http://www.merit.edu/mail.archives/nanog/msg06843.html )

Nolan Rollo
VoIP Engineer
Main: 517.223.3610x114
Fax: 517.223.4120
www.kw-corp.com<http://www.kw-corp.com/>

2

relatively unimportant. I do want to make sure that we set up our
reverse DNS correctly

the only thing that's important is that forward and reverse DNS matches.
After that, there is no correct or incorrect, so you need to do something
that makes sense for your deployment.

Nick

3

As I think I've said before on this list, when we tried to get
consensus on that claim in the DNSOP WG at the IETF, we couldn't.
Indeed, we couldn't even get consensus on the much more bland
statement, "Some people rely on the reverse, and you might want to
take that into consideration when running your services."

Now, IETF non-consensus on the way the Internet works is hardly a
surprise, but I thought I'd point this out just in case people want to
be prepared for flames from people who feel strongly about the matter.

Note, also, that there's an important distinction to be made between
matching reverse and mere existence of some reverse. An lot of sites
don't require matching any more, because of the way it can bloat PTR
RRsets if there are a lot of forward names at the same IP address.

Best,

A

4

RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:

I think you mean an "Expired RFC Draft from 2006 written by the people from
SORBS states :"

Which finally brings me to my questions:

It seems like the unspoken de facto that mail admins appreciate given the
IP 203.0.113.15 is "203-0-113-15.[type].[static/dynamic].yourdomain.tld".
This seems perfectly acceptable, it's short, detailed and to the point. Is
there really anything bad about this?

No. Nothing at all, and as you've already discovered it's what is used by
probably the majority of providers that include IP addresses in rDNS.

What, if any would you name a network, gateway, broadcast address? Should
the PTR be empty?

I've never seen anyone put in rDNS for networks or broadcast addresses.
(Naming networks was common many years ago, but it never made the jump to
DNS from what I've seen). rDNS for gateways can be helpful for traceroute,
and there are a few documents that provide examples of naming schemes for
such hosts, but I can't seem to find them right now... Again, these are
only samples - there's not such thing as a "right" answer.

5

The classic TCP wrapper had this as one of the security features, if reverse said something and this couldn't be verified by doing a forward lookup, the reverse was treated as invalid and not used for name based policies.

6

As for A records and PTR records matching, we've taken the approach that we'll auto-create a matching PTR where there's only a single A record with that IP. Otherwise, we'll add a PTR manually.

Plenty of applications can handle multiple A records; I'm not so sure that the same holds true for PTR records.

John

7

I would agree with that if you'd put scare-quotes around the word
"security". In general anyone depending on the reverse tree to
provide them any kind of security is engaged in wishful thinking,
particularly if the lookup isn't validated with DNSSEC. (But yes,
that's waht the TCP wrappers package was supposed to be doing.)

A

8

I've never seen anyone put in rDNS for networks or broadcast addresses.

I've done this a fair bit, on both a personal and professional basis. I find it quite helpful when I forget what the subnet masks are (or fail to apply them properly) and try and Do Something with an address that can't be a host.

Regards,
Tim.

9

It's taking all of my willpower to avoid an IETF rant. :slight_smile:

The "SHOULD" here is one way. A PTR record should point to a valid
forward name that resolves to the same IP address. To quote RFC 1034,
a PTR is "a pointer to another part of the domain name space". If the
RHS of a PTR is not a valid domain name, that's just not true.

But rather than some pedantic rant about standards there's a practical
purpose here. Tools that receive IP addresses will generate names
using reverse lookups, those names should then work. For instance if
trace route gives a name, "ping <name>" should then work.

But the opposite is not true. Many forward records may point to the
same IP address, and there is no need for reverses to match.

(in shorthand)

10.0.0.1 PTR webhosting.foo.com
webhosting.foo.com A 10.0.0.1
www.sitea.com A 10.0.0.1
www.siteb.com A 10.0.0.1
www.sitec.com A 10.0.0.1

10

The "SHOULD" here is one way.

Of course, there is no SHOULD anywhere. RFC 1034 is from the era
before RFC 2119, and there really isn't any guidance on the use of the
reverse tree anywhere. It was the discovery of that very gap way back
in 2006 that caused me to try to resurrect Daniel Senie's original
draft and drive it through DNSOP. I think I was less cynical in those days.

purpose here. Tools that receive IP addresses will generate names
using reverse lookups, those names should then work. For instance if
trace route gives a name, "ping <name>" should then work.

Rather than "should" here, I'd prefer to say that it'd be nice if they
work (just so that people don't mistake that should for a 2119 word).
But the distinction you're making is roughly parallel with the
distinction draft-ietf-dnsop-reverse-mapping-considerations-06 made
between existing and matching reverse entries. I agree this
distinction is worth keeping in mind.

But the opposite is not true. Many forward records may point to the
same IP address, and there is no need for reverses to match.

I can assure you that there are people who insist that they _do_ need
to match. It's also possible to have those multiple matches, as long
as the list is not too long. I think the view that every forward must
have a matching reverse is somewhat unrealistic; but the last time I
expressed such a strong opinion about the reverse tree I landed in a
long interaction with the proprietor of av8.net, so I'm disinclined to
defend my opinion very hard.

I do think that the people who think that the reverse tree is entirely
optional are neglecting the interoperability consequences of that
decision. That interoperation is the only real reason I can see to
maintain the reverse; but it's a pretty important reason!

Best,

A

11

RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
When using IP addresses in host names, their numbers SHOULD be
   separated by '.'s (dots) rather than any meta character such as a '-'
   (dash) and expressed in decimal. Host names SHOULD NOT use the '_'
   (underscore) character, host names for hosts with any form of SMTP
   mail service MUST NOT use the '_' (underscore) character. It is
   preferable to use the IP address in reverse format in the same way
   the the IN-ADDR.ARPA. domain is defined.

Hi Nolan,

Although no longer strictly required by the DNS RFCs, names which
follow these conventions are more likely to work with everyone else's
DNS servers.

1. Use only English alphabetic characters (a-z, A-Z), numeric
characters (0-9), the hyphen and the period.

2. The periods separate non-null sections of the name. You can't start
a name with a period or have two periods side by side.

3. Start each section of the name with a letter, not a number or hyphen.

4. Two hyphens can't be side by side, nor can a hyphen start or end a
section of the name.

Finally, the cardinal rule of reverse dns: whatever name the address
resolves to must resolve back to the address. If you don't do that,
you're basically asking for a whole bunch of servers on the Internet
to reject your connections. So:

13.12.11.10.in-addr.arpa PTR bob.examplecompany.com.
bob.examplecompany.com. A 10.11.12.15

is wrong (13!=15) and will cause your users problems! Also, if you
omit the A record and simply have the PTR record, that too will cause
your users problems. If you omit the A record, you should also omit
the PTR record and let the address stand without DNS.

Actual Examples:
cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX
d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX
c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX
24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX

All of these examples are fine provided the forward DNS (A record) matches.

Which finally brings me to my questions:
It seems like the unspoken de facto that mail admins appreciate
given the IP 203.0.113.15 is
"203-0-113-15.[type].[static/dynamic].yourdomain.tld". This
seems perfectly acceptable, it's short, detailed and to the
point. Is there really anything bad about this?

This is mainly for the benefit of the folks who run RBLs or other mail
reputation services. They use this information when classifying the
source and grouping sources into netblocks. If you take the time to
distinguish your intended mail servers from your dialup address pool
they'll try not to include your mail server when they ban mail
directly from your dialup address pool.

It's more a human factors question than supporting any automation.
You're hoping that by explaining your network to the antispammers
they'll cut you some slack when one of your doofus users gets pwned by
a spam bot. Many will. Some won't.

What, if any would you name a network, gateway, broadcast address?
Should the PTR be empty?

Pretty much whatever you want or nothing at all. If it doesn't
originate packets then nobody out there cares what it's named.

Regards,
Bill Herrin

12

1. Use only English alphabetic characters (a-z, A-Z), numeric
characters (0-9), the hyphen and the period.

This was never required by any DNS RFC. Also, they're not English
characters, but ASCII ones.

The full stop character is not actually part of the name. It's a
separator. For presentation format (i.e. the one you see and
manipulate) you need to use it, but be aware that it is not a part of
the name as such. (This is why IDNA can't provide an "alternate"
separator.)

In my opinion, it's really better to think in terms of labels. Labels
are separated by dots in presentation format, and by label length
markers in wire format. In order to maximise interoperability, it is
wise to stick to the LDH rule (which is roughly what William says
above: ASCII letters either upper or lower case, digts, and the
hyphen). But in principle, labels can be made of any octets you like.

Note that, if you use IDNA (internationalized labels) in the most
recent version (IDNA2008), the U-label form doesn't allow upper case.
This yields the bizarre example that Fass is a label (LDG) and fass is
a label (LDH) and faß is a label (U-label) but Faß is _not_ a valid
label.

3. Start each section of the name with a letter, not a number or hyphen.

This isn't a requirement and hasn't been since the so-called "3com
rule" change in RFC 1123. See RFC 1123 section 2.1. The topmost
label, however, _cannot_ begin with a number. No label may begin with
a hyphen.

4. Two hyphens can't be side by side, nor can a hyphen start or end a
section of the name.

Two hyphens can be side be side, but if you plan to be compatible with
IDNA they can't be side by side in the 3d and 4th positions. That is,
foobar--baz is a perfectly good label. fo--obarbaz is not. This is
so that strategies along the lines of "xn--", which is used for INDA,
can be used again in the future for other issues.

Finally, the cardinal rule of reverse dns: whatever name the address
resolves to must resolve back to the address.

This is a requirement for matching reverse. As I've already suggested
in this thread more than once, it is by no means an uncontroversial
claim.

Best,

A

13

So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS?
I'm also thinking of the famous www.1and1.com, where the number "1" starts off one of the sections.

<snip>

3. Start each section of the name with a letter, not a number or hyphen.

<snip>

14

So in the four examples below, 3 of them preface the IP with an alpha character. Charter however, starts the rDNS off with a number. I'm not arguing with anyone but what potential problems could that cause with DNS?

None.

I'm also thinking of the famous www.1and1.com, where the number "1" starts off one of the sections.

Which is fine.

Joe

15

At dnswl.org, we identify new servers from looking at the rDNS in what we
see is being queried through our logs. Names with "dynamic", "dialup" etc
or that look like they have an embedded IPv4 address are discarded through
that channel.

-- Matthias

16

Using domain name parts that start with a number will likely cause issues
for anyone running resolvers written in the 80's.

Anyone running resolvers that are less than ~25 years will likely not have
any issues.

  Scott

17

To be more precise it will cause no problems with the DNS. Some
pre RFC 1123 gethostbyname implementations may reject the name
but the DNS doesn't care.

Mark

18

So in the four examples below, 3 of them preface the IP with an alpha
character. Charter however, starts the rDNS off with a number. I'm
not arguing with anyone but what potential problems could that
cause with DNS?

Once upon a time there were buggy software implementations which
looked at the first character of the "name" to decide whether it was a
host name or an IP address. How many of them still exist? Not many
would be my guess.

3. Start each section of the name with a letter, not a number or hyphen.

The question I would ask myself is: will I recognize a gain from
putting a digit first in the name instead of a letter? If yes, it's
probably enough of an advantage to not worry about the old
implementations. If no (and it surely seems to be "no" in Nolan's
case) then keep to the conventions that work even with the ancient
buggy crap.

Regards,
Bill Herrin

19

Nolan Rollo wrote:

RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
When using IP addresses in host names, their numbers SHOULD be
    separated by '.'s (dots) rather than any meta character such as a '-'
    (dash) and expressed in decimal. Host names SHOULD NOT use the '_'
    (underscore) character, host names for hosts with any form of SMTP
    mail service MUST NOT use the '_' (underscore) character. It is
    preferable to use the IP address in reverse format in the same way
    the the IN-ADDR.ARPA. domain is defined.

That's not correct.

Not all domain names are host names, which is why '_' is allowed
for some domain names such as:

      _ldap._tcp.example.com [rfc2782]

However, though rfc1034 specifies;

   For example, when naming a mail domain, the user should satisfy
   both the rules of this memo and those in RFC-822. When creating
   a new host name, the old rules for HOSTS.TXT should be followed.

both of "should" in the rfc should, today, be interpreted as "MUST".

            Masataka Ohta

20

Andrew Sullivan wrote:

The classic TCP wrapper had this as one of the security features

I would agree with that if you'd put scare-quotes around the word
"security". In general anyone depending on the reverse tree to
provide them any kind of security is engaged in wishful thinking,

No, it's you who have wishful thinking.

particularly if the lookup isn't validated with DNSSEC.

As is discussed recently in IETF main and dns MLs, Lack of
secure time in most environment makes DNSSEC insecure.

Legal enforcement on zone administrators makes related zones
insecure.

For most users, security by plain DNS with reverse look up is
fine.

            Masataka Ohta