Re: comcast ipv6 PTR

[Bjørn Mork <bjorn () mork no>]

Mark Andrews <marka () isc org> writes:
> In message <8738o2poov.fsf () nemi mork no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> > Mark Andrews <marka () isc org> writes:
> >
> > > Actually you just need to *let* the hosts update their own ptr
> > > records using UPDATE.
> > >
> > > 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.
> > >
> > > You can even delegate the reverse zone when doing or just after a PD.
> > >
> > > * Accept NS/DNAME updates for the reverse prefix from any address
> > >   in the delegated address range over TCP.  This avoids having a
> > >   temporatially lame delegation.  named already has code to do this
> > >   for /48's as I coded it to to support 6to4.
> >
> > 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?
>
> Yet this is essentially what 6to4 has been doing for years.  See
> RFC 5158.  Sometimes good enough is all that is needed.

Yes.  Could be. But there will always be these paranoid users which do
not want to allow their teenage childrens hacker friends to change
delegations and create cooool names...

> One could add a KEY record at the same time as you add the NS/DNAME
> records and use SIG(0) to authenticate subsequent updates to the
> delegation based on that key.

I really like this idea.

> The DHCP server would clear delegations on new PD presumably using
> a TSIG signed UPDATE request.

I would only do the clearing when changing the prefix owner in the
DHCPv6 backend database, but I guess that depends on how you do the
allocations.

>       if no sig0 then allow update tcp-6to4
>       if self-signed the allow update
>       if this tsig then allow update
>
> Named already has the concepts of "this tsig", "self-signed",
> "tcp-6to4".  It doesn't have the concept of "no sig0" but adding
> this sort of thing is relatively straight forward.

Some sort of "this name+RR exists" conditional would be useful in the policy.

I would like to make the policy depend on
  if self-signed then allow update
  if KEY(zone) exists then deny update
  if tcp-self then allow update KEY PTR

Actually, a count of records would be useful:

  if this tsig then allow update
  if self-signed then allow update
  if count(KEY, zone) > 0 then deny update
  if tcp-self then allow update zone KEY
  if count(PTR, *.zone) > 5 then deny update
  if tcp-self then allow update *.zone PTR

Does BIND do automatic validation of NS updates vs other records?
I.e. if a NS record exists, are PTR updates inside the delegated zone
automatically denied?

> A third method would be for the CPE could send a KEY record rdata
> in the DHCP PD request that the DHCP server which would add to the
> zone with a owner name based on the allocated prefix.  SIG(0) would
> then be used to authenticate further update requests at or below
> this name.

That would also work.  But it requires co-ordinated DCHPv6 client and
server support, making it less likely to succeed IMHO.  Making those
behave is difficult enough alread.

Still, one additional concern showed up when discussing these ideas with
people being paid to be paranoid: Spamming botnets are real.  Most users
won't ever touch their reverse DNS records.  In particular, those users
with botnet controlled PCs are not going to have any KEYs.  Until the
bot programmers discover that *they* now have the power to add proper PTR
and SPF records for their spam service...

Haven't they yet discovered this on 6to4?  Well, I guess they have now,
and you will all just deny mail from 6to4 addresses regardless of DNS.


Bjørn