Subject: Re: Multiple PTR records

From: Kevin Darcy <[email-masked]>
Date: Thu, 07 Jun 2001 20:24:38 -0400

[email-masked] wrote:

> >
> > To clarify: there is nothing in the DNS protocol to stop you from creating mu
> > ltiple
> > PTR records with the same name, however no app is known to actually look beyo
> > nd the
> > first PTR in a response, and because of this fact BIND suppresses RR sorting
> > for
> > PTR records. So essentially all PTRs beyond the first one are "invisible" and
> >  a
> > waste of packet space (if the response overflows the 512-byte limit, then it
> > may
> > also waste TCP retransmissions too).
> >
> >
> > - Kevin
>
>         Some site even go so far adding PTR records that they exceed
>         the protocols ability to send them in a response.  I wonder
>         about sites that do this and how much else they don't know
>         about.
>
>         You could even use multiple PTR records as a filtering
>         critera when selecting web hosting providers.  If they list
>         multiple PTR records then they most probable don't know
>         what they are doing and you should shy away from them.
>
>         It sound like you are trying to learn what to do which is
>         good.  Good luck and keep up the learning.

I wonder if this would be good BCP material (?). RFC 2181 (not a BCP of course but
Standards Track) almost seems to *encourage* multiple PTRs by "clarifying" that it
is supported in the protocol. Now that the cat is out of the bag, perhaps there
should be a BCP stating that, while multiple PTRs are technically possible, they
are generally undesirable and when taken to extremes can in fact cause problems.

I would not volunteer to write such a document, of course, given my
even-more-radical view that reverse DNS should probably go away or its use be
severely limited (and I don't think keeping reverse DNS around solely as a sort of
"ISP intelligence test" is really a strong argument, even when couched in terms of
spam-prevention).

- Kevin

---

From: Shane Kerr <[email-masked]>
Date: Fri, 8 Jun 2001 10:47:48 +0200

On 2001-06-07 20:24:38 +0000, Kevin Darcy wrote:
> 
> I wonder if this would be good BCP material (?). RFC 2181 (not a BCP
> of course but Standards Track) almost seems to *encourage* multiple
> PTRs by "clarifying" that it is supported in the protocol. Now that
> the cat is out of the bag, perhaps there should be a BCP stating that,
> while multiple PTRs are technically possible, they are generally
> undesirable and when taken to extremes can in fact cause problems.
> 
> even-more-radical view that reverse DNS should probably go away or its
> use be severely limited (and I don't think keeping reverse DNS around
> solely as a sort of "ISP intelligence test" is really a strong
> argument, even when couched in terms of spam-prevention).

This is an intriguing idea.  To be honest, at first glance it doesn't
seem *too* radical to me.  I mean, what's the real "use case" for
referse DNS?  Certainly any "match forward/reverse" for "security" has
long been discredited.  The ability to put a machine name in my utmp
entry seems like a very small gain for such a large system.

OTOH, my understanding of the IPv6 world is, "yes IPv6 numbers are
totally ridiculous, so use DNS for everything".  In such a world,
reverse DNS seems to take on a huge importance.  Not that I've heard any
proposals how ISP's are going to manage running reverse DNS for the /48
they're going to have to give out to each dial-up customer.  (I'm sure
that somebody has a clever solution for this, I just haven't heard it.)

-- 
Shane

---

From: Robert Elz <[email-masked]>
Date: Fri, 08 Jun 2001 17:01:22 +0700

Date:        Fri, 8 Jun 2001 10:47:48 +0200
    From:        Shane Kerr <[email-masked]>
    Message-ID:  <[email-masked]>

  | OTOH, my understanding of the IPv6 world is, "yes IPv6 numbers are
  | totally ridiculous, so use DNS for everything".  In such a world,
  | reverse DNS seems to take on a huge importance.

You're confusing two issues.   One is the ability to translate numbers
into names.   The other is "reverse DNS" (really DNS in the in-addr.arpa
or ip6.int or ip6.arpa zone).

The latter is commonly used to implement the former, but it certainly
isn't the only way.

kre

ps: as for managing the DNS for number->name for customers given a /48,
then one of two things happens - either the customer has a large network,
in which case they're either going to manage the DNS for themselves, or
pay you large enough sums that you will be willing to do it for them,
or they actually only have a very small real network, in which case the
only real difference from what you do now with IPv4 is that the names
are longer, isn't it?    And of course, there's also Dynamic DNS if
you want to use it - let the nodes update their own entries.

---

From: Shane Kerr <[email-masked]>
Date: Fri, 8 Jun 2001 15:00:34 +0200

Mostly thinking "out loud" here...

On 2001-06-08 17:01:22 +0000, Robert Elz wrote:
> into names.   The other is "reverse DNS" (really DNS in the
> in-addr.arpa or ip6.int or ip6.arpa zone).
> 

Can you expand on this?  I can think of lots of ways to do this in
theory - some even implemented (e.g. NIS+) - but are any actually used
on the Internet?

> ps: as for managing the DNS for number->name for customers given a
> /48, then one of two things happens - either the customer has a large
> network, in which case they're either going to manage the DNS for
> themselves, or pay you large enough sums that you will be willing to
> do it for them, or they actually only have a very small real network,
> in which case the only real difference from what you do now with IPv4
> is that the names are longer, isn't it?    And of course, there's also
> Dynamic DNS if you want to use it - let the nodes update their own
> entries.

Right now we basically have the case where you have 1 or 3 IP addresses
as an end user, and have little (or no) control over your in-addr.arpa,
or you get a relatively large number of addresses and either manage your
own DNS or your ISP does it.  But I expect we will reach the case in
IPv6 where your typical /48 has maybe a dozen or so devices which come
and go pretty much at random - phones, televisions, computers, radios,
clocks, and so on.  This seems an "uncomfortable" price-point for
administration to me.  It's too many to ignore, but not enough to
justify mechanisms that aren't (nearly-)fully automated.

If accessing these devices is important (and why put them on the
Internet if not), then the fact that IPv6 addresses are extremely
unwieldy (they are) means that they should have names.  If the protocols
used by each device report its name(s), then that's fine, but doesn't it
seem redundant to have to add a "report client name" option to every
protocol rather than allow DNS to provide it?

I imagine for certain kinds of protocols (and all unicast
push-protocols) this information is necessary.  Shouldn't my IP
telephone be able to return your call for me by knowing the name of the
handset you just called from?  (Just an example, please don't strain too
hard to blast obvious holes in it.)

Yes, there is Dynamic DNS - it works pretty good.  I think in a context
of DNSSEC (for IP-based update controls) or TSIG then it might even
work.  Isn't the issue with DDNS on a large scale the problem of key
distribution for whatever security mechanism is proposed?  How do ISP's
get the keys to both their servers and customers in a reliable and secure
fashion?  How do the customers (and I mean everybody, not just IT
professionals) get these keys into not only their PC's, but also all
other connected devices?  How do you avoid "leakage" of these keys over
wireless networks and other unsecure media?  I'm not saying this is
impossible, merely non-trivial and I honestly don't know what's proposed
to handle the issue.

-- 
Shane