Re: Multiple PTR records

Shane Kerr <shane@ripe.net> Fri, 08 June 2001 13:37 UTC

Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12367 for <dnsop-archive@odin.ietf.org>; Fri, 8 Jun 2001 09:37:25 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) id f58D7pNF018068 for dnsop-outgoing; Fri, 8 Jun 2001 15:07:51 +0200 (MEST)
Received: from penguin.ripe.net (penguin.ripe.net [193.0.1.232]) by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f58D7ouA018063 for <dnsop@cafax.se>; Fri, 8 Jun 2001 15:07:50 +0200 (MEST)
Received: (from shane@localhost) by penguin.ripe.net (8.10.2/8.10.2) id f58D0YO17795; Fri, 8 Jun 2001 15:00:34 +0200
Date: Fri, 08 Jun 2001 15:00:34 +0200
From: Shane Kerr <shane@ripe.net>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: dnsop@cafax.se
Subject: Re: Multiple PTR records
Message-ID: <20010608150032.A17689@penguin.ripe.net>
References: <20010608104746.B17160@penguin.ripe.net> <200106072259.f57MxFv91665@drugs.dv.isc.org> <3B201B46.97FDF5A4@daimlerchrysler.com> <20010608104746.B17160@penguin.ripe.net> <2547.991994482@brandenburg.cs.mu.OZ.AU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <2547.991994482@brandenburg.cs.mu.OZ.AU>; from kre@munnari.OZ.AU at 2001-06-08 17:01:22 +0000
Sender: owner-dnsop@cafax.se
Precedence: bulk

Mostly thinking "out loud" here...

On 2001-06-08 17:01:22 +0000, Robert Elz wrote:
> 
>   | 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.

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