On Mon, Jan 15, 2018 at 7:22 AM william manning <chinese.apri...@gmail.com> wrote:
> your wrote,: "In the real world, the user will not be expected to figure > this out [...] -- a bit of JS on www.example.com will do the 3 fetches > and report "You'll be just fine", "You will have issues, call your ISP and > get them to install the new key" or "Sorry, cannot tell. Call your ISP and > ask them to upgrade to a resolver which does this!"." > > I think its a bit sad that for the DNS to work, one now needs to run > http[s] and JS. So much for stand alone protocols. Now if you could show > how this works without JS or HTTP, then we might be getting somewhere. > % dig invalid.example.com A: Did I get an answer (SERVFAIL isn't an answer)? I'm not validating. Keyroll won't affect me. % dig _is-ta-12345.example.com % dig _not-ta-12345.example.com B: Did I get an answer to both? My resolvers haven't been upgraded, I cannot tell what will happen. C: Did I get an answer for _is-ta-12345.example.com and a SERVFAIL for _ not-ta-12345.example.com ? My resolver supports sentinal (is sentinent?!), and has the new key. I'll be fine. D: Did I get a SERFVAIL for _is-ta-12345.example.com and an answer for _ not-ta-12345.example.com ? My resolver supports sentinal, and does not have the new key. I'll die during the rollover. This works just fine without JS or HTTP -- but expecting users (which is ultimatly what we are trying to measure) to do the above, and then report that back somewhere is not really viable. RFC8145 tried to measure using the DNS only -- but that only lets you know what *resolvers* will be OK, which is fairly meaningless; I have a resolver in my basement which only has the old key, but seeing as no users are querying it, it it's nearly as important as my local ISP, whose resolver services thousands of users. If you have a better proposal, we are all ears... W > > /Wm > > On Sun, Jan 14, 2018 at 5:51 PM, Warren Kumari <war...@kumari.net> wrote: > >> Hi all, >> >> I had a conversation with a friend earlier today, who had carefully read >> the document >> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/) >> , but had not managed to understand it at all >> . >> Since >> this friend is bright, and really understand >> s >> DNS, I figured that the document doesn't do as good a job explaining how >> this would be used in practice as it should. Sometimes it is easier to >> explain things in an informal manner, and so here is a (hopefully better) >> description of draft-ietf-dnsop-kskroll-sentinel). >> >> 2 things seemed to be causing confusion: >> 1: The only "magic" that happens is in validating recursive resolvers, >> right before they send the response to a query >> . T >> here is no magic / change needed in authoritative servers, stubs, or >> anywhere else. >> >> 2: Anyone who wants to provide a service like this >> (see below) >> can - you don't need to be in any special location in the DNS tree to do >> this. >> >> >> The (new) rules: >> A: If the qname starts with _is-ta, and the included keyid is *NOT* in >> the trust store, the resolver changes the answer to a SERVFAIL (otherwise >> things proceed normally). >> B: If the qname starts with _not-ta and the included keyid *IS* in the >> trust store, the resolver changes the answer to a SERVFAIL (otherwise >> things proceed normally). >> >> (There is some pseudo-code below, but it makes this look much more >> complex (and I dislike pseudo-code - it's hard to guess at the level of >> abstraction to use!). >> >> >> Let's pretend >> I'm the operator of example.com, and I'd like to help users know if the >> resolvers that they use will survive the new keyroll (with key id 12345). >> >> I publish this in my a zone: >> >> _is-ta-12345.example.com. 600 IN A 192.0.2.1 >> _is-ta-12345.example.com. 600 IN RRSIG A <valid signature> >> >> _not-ta-12345.example.com. 600 IN A 192.0.2.2 >> _not-ta-12345.example.com. 600 IN RRSIG A <valid signature> >> >> invalid.example.com. 600 IN A 192.0.2.3 >> invalid.example.com. 600 IN RRSIG A <0x0000 (an invalid >> signature)> >> >> I also run 3 webservers: >> >> 192.0.2.1 >> -- a picture of a cute kitten >> 192.0.2. >> 2 -- a picture of a puppy >> 192.0.2. >> 3 -- a picture of a fish. >> >> >> >> >> >> I now tell users to please browse to www.example.com, where I have a >> webpage which includes the following links: http://_ >> is-ta-12345.example.com/ >> ( >> kitten) , http://_not-ta-12345.example.com/ (puppy), >> http://invalid.example.com/ (fish). >> The pictures the user can see tells them if they will survive the >> rollover. >> >> >> >> The user can be in one of 4 classes, depending on which animals they see: >> >> 1: The user sees a Fish, a Kitten and a Puppy -- they fetched all the >> URLs (including http://invalid.example.com/). If they see a Fish, they >> are not using a validating resolver and so will survive the keyroll (it >> actually means that at least 1 of their resolvers is not validating). The >> user is happy and goes to have ice-cream (nonV). >> >> 2: The user sees a only Kitten and a Puppy (they fetched http://_ >> is-ta-12345.example.com/ and http://_not-ta-12345.example.com/, but not >> http://invalid.example.com/.) This means that they are using a >> legacy >> validating resolver >> (it >> doesn't implement this mechanism >> ) >> . >> They cannot tell, and this test doesn't tell them anything >> (Vleg). >> >> 3: They see only a Kitten (they fetched http://_is-ta-12345.example.com/, >> not http://_not-ta-12345.example.com/, and not >> http://invalid.example.com/). The user is behind a validating resolver >> which implements this mechanism, and knows about the new key. They are >> happy, and go have ice-cream (Vnew). >> >> 4: The user sees only a Puppy (they did not fetch http://_ >> is-ta-12345.example.com/, they did fetch http://_ >> not-ta-12345.example.com/, they did not fetch http://invalid.example.com). >> The user is behind a validating resolver which implements this mechanism, >> but does NOT have the new key). The user is sad, and calls their ISP to >> complain (and has cold porridge for dinner) (Vold). >> >> +-------------+----------+-----------+------------+ >> | Type\Query | _is-ta | _not-ta | invalid | >> +-------------+----------+-----------+------------+ >> | Vnew | A | SERVFAIL | SERVFAIL | >> | Vold | SERVFAIL | A | SERVFAIL | >> | Vleg | A | A | SERVFAIL | >> | nonV | A | A | A | >> +-------------+----------+-----------+------------+ >> >> In the real world, the user will not be expected to figure this out from >> looking at pictures -- a bit of JS on www.example.com will do the 3 >> fetches and report "You'll be just fine", "You will have issues, call your >> ISP and get them to install the new key" or "Sorry, cannot tell. Call your >> ISP and ask them to upgrade to a resolver which does this!". There will >> also likely be some Geoffvertisement which will do this on a large scale >> and report back. >> >> Hopefully this clears things up some -- the only code change needs to >> happen on recursive resolvers, the A record returned is unmolested (so that >> if can be used for something) and the only action is to make some VALID >> answers INVALID (A (or whatever) -> SERVFAIL). >> >> W >> >> >> >> Pseudo-code: >> >> func extract_ta(string): >> # Extracts the queried trust anchor (a set of digits) from a qname. >> # E.g: "perl -pne "s/_.*-ta-(\d*)\..*/\1/" (_is-ta-55555.foo -> 55555) >> return (numbers) >> >> <normal processing> >> ... >> queried_ta = extract_ta (qname); >> if qname startswith("_is-ta-"): >> if queried_ta is in trust_store: >> return; >> else: >> return SERVFAIL >> >> if qname startswith("_not-ta-"): >> if queried_ta is in trust_store: >> return SERVFAIL; >> else: >> return; >> --- >> >> >> -- >> 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 >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
