You can always send a QUERY with no question. It’s not perfect, as it is subject to downgrade attacks, but does allow you to probe server capabilities.
% dig +ednsopt=100 +header-only +qr ; <<>> DiG 9.15.4+hotspot+add-prefetch+marka <<>> +ednsopt +header-only +qr ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38660 ;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ab59773fd258541b ; OPT=100 ;; QUESTION SECTION: ;; QUERY SIZE: 39 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38660 ;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ab59773fd258541b010000005dc24d3939228b15d289bab4 (good) ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Nov 06 15:34:01 AEDT 2019 ;; MSG SIZE rcvd: 51 % > On 6 Nov 2019, at 10:13, Warren Kumari <[email protected]> wrote: > > On Tue, Nov 5, 2019 at 2:40 PM Paul Wouters <[email protected]> wrote: >> >> On Tue, 5 Nov 2019, Warren Kumari wrote: >> >>> Because then I need to probe them on 853 and wait N before trying on port >>> 53, or I will >>> only get any sort of protection for name-servers which I’ve spoken to >>> recently enough that >>> I have them in cache — that works for e.g: ns1.google.com, but not >>> ns0.nohats.ca >> >> Well, that's how we do things when remembering per-server >> characteristics, which we need to do anyway in case of outages. >> >> Like EDNS0 support and DNS COOKIES support is remembered and cached, >> why wouldn't resolvers do the same for this property. We didn't put >> "ns-edns" out there in name hacks either. Why start now? > > For things like COOKIES I don't need knowledge of the server *before* > I contact it -- when I want to lookup www.nothat.ca, and get back a > cookie, I've learnt something useful for future connections. > > For privacy, I really don't want to have to leak the fact that I'm > looking up secret.nohats.ca because I happen to be the first user who > is (recently) asking for a name on ns0.nohats.ca. > a.ns.facebook.com is popular and so in basically all caches, all the > time - and so users looking that up would get privacy most of the > time. > ns01.kumari.net is (obviously) less popular, and so basically never in > caches -- and so anyone looking up kink.kumari.net will be exposed. > > Now, I really don't think it is fair and right that people looking up > Facebook (or Google) get privacy simply because those sites are > popular, and people reaching my personal site don't. > I could get privacy back by moving my DNS to a large commercial DNS > hoster (ns59.domaincontrol.com is in many caches, much of the time), > but this seems like an even worse push. > > I'd like some system where I can signal that I support DoT: > 1: without my parent having to do anything (like be upgraded to support DoT) > > 2: without having people to probe and wait for a timeout > > 3: with my users first connection protected, so they don't have to > lookup safe.kumari.net (to make sure that the resolver knows that > ns01.kumari.net supports DoT), or something like _dot.kumari.net > before looking up secret.kumari.net. > > 4: without expecting everyone to support DNSSEC. > > I'd like to see something less stupid than ns01-dot.kumari.net, but I > don't really see what else the child controls at the parent (without > having a separate set of info / RR type / encoding stuff in DS, etc) > > W > > > >> >> Paul > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
