comcast ipv6 PTR

Wed Oct 16 07:50:29 UTC 2013

In message <87mwmao693.fsf at nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> Joe Abley <jabley at hopcount.ca> writes:
> > On 2013-10-15, at 10:57, Bj=C3=B8rn Mork <bjorn at mork.no> wrote:
> >> Mark Andrews <marka at isc.org> writes:
> >>=20
> >>> 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
> >> This sounded like an excellent idea at first, but then I started
> >> thinking:  As a home user, would I really want to give anyone with
> >> access to my network the right to change my reverse delegation?
> >
> > I think what you'd be doing is giving anybody you have assigned an
> > IPv6 address to the ability to update the PTR (or a delegation, since
> > Mark suggested that too) for that particular address.
> >
> > So, it's not "my reverse delegation", it's "my 2^80 or fewer reverse
> > delegations" (if you've been assigned a /48).
> 
> Ah, right.  I understood the proposal as "any address within then /48
> can update the delegation for the /48 reverse".
> 
> But if that would be 2^80 distinct delegations or PTRs, then I am
> worrying about luser stupidiy and the ability to DoS the name server.  I
> guess this can be combined with some sort of limit, making it fly?
> Still don't see the advantage of being able to delegate if it's only
> single address delegations.  But allowing a limited number of PTR
> updates based on TCP sounds like a nice idea.  Going to consider that.

No that would be 1 delegation.  e.g.  x.x.x.x.8.b.d.0.1.0.0.2.ip6.arpa

> For the full /48 delegation I don't see any other option than making it
> part of a self service portal.  But the marketing/product droids usually
> don't want that sort of "complex" techical stuff  for retail users.
> Probably for good reasons...

I can see this being done completely automatically by the CPE device.
It is trivial to code.  It just required ISP's to *allow* it to happen.

* CPE generates a RSA key pair.  Stores this in non-volatile memory.
  [needs to be coded, no protocol work required]

* CPE generates DHCP PD request which includes a "KEY-RDATA" option
  which contains a RSASHA256 KEY RDATA.
  [needs to be coded, needs code point allocated but otherwise no
  protocol work required]  

* DHCP server updates DNS server based on the prefix it is delegating
  and the KEY-RDATA using TSIG for authentication and responds with
  prefix.  If this is a new PD it will clear out all the old DNS
  records as part of the delegation processs.  If there are multiple
  prefixes being delegated the DNS server will be updated for all of
  them.
  [needs to be coded.  uses existing protocols]

* The CPE device configures the nameserver built in to it to server
  the reverse of the delegated prefixes.
  [needs to be coded, no protocol work required]

* CPE device generates DNS update which delegates the reverse name
  space to itself and uses SIG(0) to sign the request with owner
  name matching the reverse of the delegated prefix.
  [needs to be coded, uses existing protocols]

* The ISP's DNS server is configured to accept self signed requests.
  It examines the request. Looks at the KEY record added by the DHCP
  server and decides the request is valid.
  [exists, uses existing protocols]

At this stage the reverse space has been delegated to the CPE device
which can accept updates from machines within the home.

> In any case: All of you should expect legitimate, technical brilliant
> users attempting to connect to your SMTP servers from IPv6 addresses
> with no PTR records. This is not going to go away.  You are of course
> free to refuse those connections, but personally I find a that rather
> arrogant and pretty stupid decision.  The existence of a PTR record is
> one of many factors to consider for your spam filter.  There never has
> been any reason to make it an absolute requirement, and I am pretty sure
> the score needs to be lowered with IPv6.
> 
> 
> Bj=C3=B8rn (yes, my mail server has a proper IPv6 reverse record, but that's
> only because I am in a position to create the reverse delegation....)
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org