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
- Re: Multiple PTR records Kevin Darcy
- Re: Multiple PTR records Shane Kerr
- Re: Multiple PTR records Robert Elz
- Re: Multiple PTR records Shane Kerr