Damian Menscher via NANOG <nanog@nanog.org> writes: > "This experiment will be done in collaboration with DNS providers who > already support DoH, with the goal of improving our mutual users’ > security and privacy by upgrading them to the DoH version of their > current DNS service. With our approach, the DNS service used will not > change, only the protocol will. As a result, existing content controls > of your current DNS provider, including any existing protections for > children, will remain active."
That sounds useful, actually, as long as the browser can check, on every startup, which recursive name server its host is configured to use, and whether it is known that that server offers an equivalent DoH service, and that the entity operating said service explicitly wants clients to use that in preference to its regular port 53 or 853 service. One could imagine a local, special, domain, containing a record that the browser could look for, and which, in effect, says: "we run an equivalent DoH service; here's the URL; please use that". This redirection would then be valid for the TTL of that record. Ideally, of course. the browser, like any other application, should just use the host's local resolving mechanism, which, in turn, should be using whatever the host is configured to use as a recursor, and this mechanism should be secure, i.e. both trustworthy and private. However: because the browser cannot know for sure that the DNS traffic is being routed over a secure channel, and browsers are being used for all sorts of sensitive communication, it could check, and try to assist the user. This means detecting whether communication with the recursor is using port 53, and, if so, checking whether DoT and/or DoH is available from that same service provider, possibly in the fashion previously described. It could also check that DNSSEC validation is in use and working, and whether said DoT and/or DoH service is properly secured, by certificates that have a valid chain from a trusted root, or that can be verified from DNSSEC protected TLSA records. Any problems found could then be reported to the user, along with suggestions for how to fix them (or get them fixed). As a last resort, the user could be offered reconfiguration of the browser itself to directly use a better mechanism offered by the already used resolving name server, if possible. Bottom line: those of us who provide DNS services to end users need to make sure that we do so in a secure fashion, which means offering encrypted DNS with DNSSEC validation. If we don't, we can't blame the browser makers for trying to help our users remedy our faults. They want to protect their users from poor sysadmins. Let's not be that. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay
