comcast ipv6 PTR

Tue Oct 15 11:08:28 UTC 2013

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 at asgard.org> wrote:

> On 10/15/13 7:54 AM, "Mark Andrews" <marka at isc.org> wrote:
> 
>> Actually you just need to *let* the hosts update their own ptr
>> records using UPDATE.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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