There was some discussion in last night's meeting about encoding keys in the DNS name of a nameserver, similar to DNSCurve. There are at least some issues with it:
1. The RDATA of an NS record has to be a hostname, so it would limit the amount of data that can be encoded within the NSDNAME. As an example, base32 encoding is not possible. 2. It would have to work for nameservers that are within a domain with a very long name already. 3. Let's assume it takes about 10 years for resolver->auth privacy transport to trickle into widespread operational availability. It is expected that quantum computers capable of obsoleting traditional crypto will be available in as few as 15-20 years from now. It is unclear if the limited length of keys that can be encoded into a subset of a DNS name would be sufficient for post-quantum crypto algorithms. 4. NS records returned as part of delegations are unsigned, so for a resolver to trust key information in the RDATA of such NS records in a delegation, it would require the delegation to be returned using secure transport to the parent-side nameserver of the zone cut. During last night's conversation, there was some talk about fallback to plain transports - it will not be useful unless the entire delegation from root is followed with secure transports. Mukund _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy