On Sun, 31 Mar 2019, Watson Ladd wrote:
Please rip these ideas to shreds: 1) An extra bit in a response for "you could have asked over TLS"
Too late, you already lost your privacy.
2) An extra field when looking up the nameserver for "you can ask that server over TLS"
Where would this field be? Not a DNS option because that would take 10+ years to roll out. also how would this option be secured?
3) An extra field/bit/convention for "this nameserver supports tls" (like tls-ns vs ns)
Same as above. There was a reason I somewhat joked about DNSKEY flags. It is one of the view signaling methods we have that is secure and is about publishing something at the parent on behave of the child. But I don't think this is a real solution either. It would be a very bad signaling hack. The trick will be to have nameservers that are not within bailiwick of the zone. Then if the parent's transport security was good, you get nameservers which you can query for TLSA or tls-dnssec-chain to get its TLS/HTTPS key. Then query it for the target domain zone. And at that point you do not need a flag anywhere else either. And knowing you are querying ns.bighoster.com shouldn't reveal which domain you are looking up specifically. All of this assumes query minimalization too (obviously, if you do not, then you leak the target domain all over the place) It also leaves the domains with bailiwick without protection, but those target domains should only be hosting NS/A/AAAA of nameservers so the privacy loss is minimal. Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
