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
