Re: [dns-privacy] Some additional signalling ideas

[Paul Wouters <[e-mail]>]

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