Hi Shumon and Christian, As one of the authors of RFC 4470 I most certainly care about this topic.
However, to my mind the major issue isn’t so much optimising the amount of work done at the edge when generating the negative response. Nor is it the size of the response. Instead my view is that for our idea (generating negative responses on the fly) to ever become more than a fringe phenomena we need to talk about alternatives for having private keys located at the edge (i.e. in the authoritative servers generating the response). I.e this section in the draft is the crux of the matter: > 6. Security Considerations > Online signing of DNS records requires authoritative servers for the DNS zone > to have > access to the private signing keys. Exposing signing keys on Internet > reachable > servers makes them more vulnerable to attack. Our original idea was to propose a different type of DNSKEY, i.e. a new flag bit in the DNSKEY that would signal “this key is only allowed to sign negative responses”. We were, however, talked out of that idea based on the strong wish to get DNSSEC out the door ASAP and therefore under no circumstances open up the Pandoras Box of further tweaks to the existing protocol. And yet, here we are, seventeen years later, still discussing this. For white lies, black lies, compact lies or whatever we choose to call them to ever become mainstream my view is still that we need a mechanism that works for *all* zones. In particular it needs to work for TLD zones, as they are the one’s that care most about prohibiting zone walking. And the TLDs most certainly are not about to hand over their private keys to their contracted DNS service providers (and I say this as previously having been responsible for DNS at a major service provider for many years and now working for a ccTLD registry). It just aint gonna happen. So either we’re limiting scope to optimising black lies, and there’s nothing wrong with that. Or we decide to talk about the real issue: what change is needed to DNSSEC to allow a third party DNS provider to generate negative responses on the fly without having access to the private keys of the customer? Otherwise, and my cynicism may be showing here, we will still be talking about this seventeen years from now, i.e. sometime around 2040. Unless, of course, the Internet stops working in 2038, when we, literally, run out of time :-) Regards, Johan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
