[DNSOP] A conversational description of sentinel.

[Warren Kumari <[e-mail]>]

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