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:
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
Mark Andrews <marka@isc.org> writes: =20 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