Hiya,
On 31/03/2021 01:53, Erik Kline wrote:
I think, "IN NS com." doesn't reveal much information.
Right. And such cases are probably a huge percentage of both all, and all-of-the-sensitive, queries to root servers.
But perhaps "IN NS sensitive-tld." could have privacy implications for some folks?
I guess that's a fair point that querying some e.g. ccTLD NS from some locales could sometimes be an issue. Do we have any information as to the prevalence of such? (Or of cases where such queries are abused in ways that decrease privacy or enforce censorship.) Maybe in addition to recommending QNAME minimisation it'd be good if root server operators also recommended services that face such issues deploy those services lower down in the naming hierarchy? My guess is that service providers will do that anyway but no harm to give a bit of direction. On 31/03/2021 02:17, Eric Rescorla wrote:
However, recall that the TLS connection to the parent is what protects the NS records for the child, as they are not DNSSEC signed. Thus, one has a somewhat fragile situation if one has to store a lookaside list of the TLS status (and at some level the nameservers!) for the TLDs. I'm not saying it's unmanageable, but it's not amazing.
Also fair. Requiring the parent to be involved is a big deal for any of the offered solutions here (regardless of whether or not DNSSEC is involved). In any case, I still think we ought be able to live with a situation where the root server operators do less than the TLD server operators - it's the queries to the latter that more or less have to include the vast majority of sensitive information. (And if a solution that works for .com is found, then I bet we'd be able to find something that works as well for root server operators.) Cheers, S.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
