Re: comcast ipv6 PTR

[Mark Andrews <marka () isc org>]

In message <8738o1ob07.fsf () nemi mork no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> Mark Andrews <marka () isc org> writes:
> > In message <8738o2poov.fsf () nemi mork no>, =3D?utf-8?Q?Bj=3DC3=3DB8rn_Mork=
> ?=3D writes:
> > > Mark Andrews <marka () isc org> writes:
> > > =20
> > > > 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.
> > > =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?
> >
> > 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 polic=
> y.
>
> 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.

However *now* is the perfect time to do this as many ISP's are only
starting to think about how to do IPv6.  This means installing *new*
DHCP servers.  

Similarly most households don't yet have a IPv6 CPE device.

We are talking "basically" green field.

> 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...

Your customers should be able to get names for their machines
registered in the DNS.  If that means that generic names go the way
of the dinasour then so be it.

Remember generic names were only used because there was specified
method to do this originally and inertia took over for IPv4.

This is like the reason people used ISP to send and receive email
was because they were not alway connected and it was slightly less
hassle.

> 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=C3=B8rn
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org