[166242] in North American Network Operators' Group
Re: comcast ipv6 PTR
daemon@ATHENA.MIT.EDU (Joe Abley)
Tue Oct 15 07:08:39 2013
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <CE82B9DD.331C2%Lee@asgard.org>
Date: Tue, 15 Oct 2013 07:08:28 -0400
To: Lee Howard <Lee@asgard.org>
Cc: John Levine <johnl@iecc.com>, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi Lee,
I can tell it has been a long weekend here; I find myself agreeing with =
Mark Andrews.
On 2013-10-15, at 04:32, Lee Howard <Lee@asgard.org> wrote:
> On 10/15/13 7:54 AM, "Mark Andrews" <marka@isc.org> wrote:
>=20
>> Actually you just need to *let* the hosts update their own ptr
>> records using UPDATE.
>=20
> Cool. How do I tell a residential device what name server they should =
send
> updates to?
The device can discover the lowest zone cut for a particular owner name, =
and extract the MAME from the corresponding SOA.
> Remember that the ISP uses DHCPv6 or PPPoE or TR-069 to send =
configuration
> information to the CPE, which sends DHCPv6 or RA to hosts. "Hosts" =
may be
> computers, tablets, game consoles, phones, TVs, or other.
Yes.
>> People keep saying the PTR records don't mean anything yet still
>> demand really strong authentication for updates of PTR records.
>> TCP is more than a strong enough authenticator to support update
>> from self.
>=20
> Dynamic DNS uses TCP? I didn't realize that.
DNS can use TCP. DNS UPDATE can use TCP.
>> You can even delegate the reverse zone when doing or just after a PD.
>=20
> To a home router? How do you tell the home router that it is now
> authoritative for the reverse zone?
The device can discover that itself by looking for a delegation to =
itself, knowing the owner name.
>> * Extend DHCPv6 to support delegations (NS or DNAME) relayed via
>> the DHCP server as part of the PD. NS records would result in a
>> temporarially lame delegation until the zone is configured in the
>> nameserver.
>=20
> Let me know when you need me to express support for your draft being
> adopted by dhc WG.
> Until that feature is implemented, it is of limited operational =
utility.
There's no protocol work required for any of this in the IETF. All that =
is required is agreement between access providers and home gateway =
vendors. Home gateways already need an overhaul to stop them spraying =
DNS responses received on the WAN port all over the Internet, so might =
as well take care of this at the same time.
(If I've woken up to a world where the presence or absence of an IETF =
BCP makes a difference to anybody in this context, then let's ditch this =
topic and move straight to BCP38. We can talk after that.)
Joe=
