Dear colleagues, I managed to delete instead of sending my note on this topic earlier today, and my brain is sufficiently soft that I couldn't just re-type it out. Nevertheless,
On Tue, Jul 18, 2017 at 03:19:44PM +0200, Willem Toorop wrote: > I support trying to come up with a standards solution for alias names at > the apex. But.... I agree with this, and > The dependency on online signing is a little more then just a technical > issue. also this. > Currently all DNS Resource Records support the "offline" domain-name > holder signed zones mode of DNSSEC. There is another provisioning > oriented resource record: DNAME. For DNAME, it is described how > validators can verify that the followed referral matches. The same thing > should be done for ANAME. The problem is that DNAME has another feature that ANAME (and other things like BNAME) can't: RFC 6672 gives the reasons why all validators must also be able to cope with DNAME. This was a fact (or maybe accident) of history. It is just not true of ANAME, and that means that much of section 3 of the I-D is far too weak. It needs to say that, if you can't sign online, then you will break DNSSEC. It is very strange for us to suggest this, but I think there are only two options: either DNSSEC means we can never do any more aliasing, or else we have to accept that some kinds of innovation in the DNS is going to break DNSSEC sometimes, and allow zone operators to decide whether they want to break validation (and therefore lose the connections) or whether they want to serve everyone. Alternatively, of course, we can follow the multiple-algorithm approach that others have suggested. This has the disadvantage of bloating the DNSKEY RRset for anyone who wants to use these features, of course, so it is also not free. I'm also slightly concerned about this at the end of 3.3: The type bit map SHOULD only include address types which are known to exist at the <target> Is the advice really to ask for both and then incorporate what is known? That seems maybe safer advice. I also wonder whether the document would be easier to understand if it were broken up into smaller chunks dealing separately with the authorities, intermediates, and stubs. It could be that nobody else find these items too tangled in the current I-D, but if others do I can propose text. A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
