Subject: Re: [DNSOP] kskroll-sentinel responses

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 02 Jan 2018 15:37:06 -0800

On 23 Dec 2017, at 11:59, Geoff Huston wrote:

>> On 22 Dec 2017, at 8:44 am, Ray Bellis <[email-masked]> wrote:
>>
>>
>>
>> On 21/12/2017 15:36, Robert Story wrote:
>>> I reread the draft today, and noticed that two things aren't 
>>> specified.
>>> The first is the contents of the A/AAAA RRSET returned, and the 
>>> second
>>> is the TTL for the records.
>>>
>>> Maybe the A/AAAA record values could be used to return additional
>>> details? For example, whether or not the key is part of static
>>> configuration, or learned via 5011.
>>
>> I had also wondered about this.
>>
>> A browser-based system for triggering these queries can't do so 
>> without
>> also then attempting a download of some resource via whatever IP 
>> address
>> is returned.
>>
>> (in other words, you can't make a browser "just" do a DNS lookup, the
>> DNS lookup is a side effect of attempting to access a URL)
>>
>
> As Ray points out, if a browser is conducting the experiment, and the
> only visible indication of successful resolution is the retrieval of 
> the
> named object, then a reasonable test would use some sentinel object as
> the named target (a 1x1 pixel gif is conventional in these
> circumstances). In this case the TTL of the DNS record is not directly
> visible to the browser.
>
> In situations where a client may have multiple resolvers in their 
> local
> /etc/resolv.conf configuration, and recursive resolvers may themselves
> /use forwarders, it is not immediately obvious which resolver
> generated the response, so I’m unsure of the interpretation of any
> attempt to embed some form of additional information into either the 
> IP
> address of the named object.
>
> The intent of the test is to establish a usable test along the lines 
> of
> "If you can retrieve this named object you are ready for a Root Zone 
> KSK
> roll" The issues around the diversity of behaviours in the DNS turn 
> this
> dsimple songle fetch into a compound fetch of three named objects, but
> the semantic intent is the same. That is: "From the pattern of the
> results of performing these three tests we can compute a likelihood of
> concluding whether or not, you, the end user, will, or will not, be
> affected by a pending KSK roll. From a large enough sample of users 
> was
> can then estimate the 'impact' of a KSK roll on the total user
> population.
>
> Note that the intent is not to try and isolate the behaviour of a 
> single
> resolver, nor to attempt to diagnose the reasons for that behaviour. 
> The
> intent is to look at the user and the set of resolvers that the user's
> DNS is configured to use, and determine if the user's DNS will be
> "stranded" in the even of a KSK roll.

This answer doesn't seem to fully address Robert's and Ray's questions. 
Why use an A/AAAA query if you aren't going to do anything with the 
result? If you are going to use A/AAAA, you have to tell resolvers what 
to return in the results. Using a new RRtype would have clearer 
semantics.

--Paul Hoffman

---

From: Geoff Huston <[email-masked]>
Date: Wed, 3 Jan 2018 13:33:51 +1100

> This answer doesn't seem to fully address Robert's and Ray's questions. Why use an A/AAAA query if you aren't going to do anything with the result? If you are going to use A/AAAA, you have to tell resolvers what to return in the results. Using a new RRtype would have clearer semantics.

The motivation behind this draft is to be able to perform a large scale measurement of the readiness of users for a pending roll of the KSK, or the measurement of the extent to which users are using a DNS environment that is NOT ready for a KSK roll.

Large scale user measurement is not easy - small scale measurements tend to have a problem in measurement bias, so if we are looking for some random selection mechanism that can measurement in the order of millions of sample points each day then either one would need to place the test on a very popular web site used across the entire Internet, or use online ads.

In both cases the measurement uses a browser to perform the text, scripting the test using HTML5. The simplest form of such a test is to GET a URL - if the client contacts the http(s) server then as long as the DNS name is suitably unique, we have a decent signal that the client’s DNS was able to resolver the DNS name. But in a browser you cannot perform an arbitrary DNS query - the DNS query made by the browser is the side-effect of a GET and therefore the query is for an A or AAAA record.

To keep things simple we look for the outcome of the DNS by implication: if the client contacts the HTTP(s) server then we can infer that the client’s DNS resolved correctly.

So a new RR type would entirely defeat the objective of the measurement exercise. The A or AAAA query is there to allow the client to perform a subsequent HTML fetch to indicate that the DNS name was successfully resolved for the client.

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Wed, 3 Jan 2018 13:55:30 +1100

> On 3 Jan 2018, at 1:33 pm, Geoff Huston <[email-masked]> wrote:
> 

I have been asked off-list the question: “Which HTTP(s) server are you referring to here?”

At the risk of heading waaaay down potentially spurious ratholes here let me quickly explain what I meant. Within the structure of a browser-based scripted test, such as you might find in an online ad script, the common operation within the script is to perform a GET of a URL. A common approach in measurements of this form is to direct all the GET operations to a server that is part of the experiment rig. That way you don;t need the client running the measurement script to report its own results - the results can be constructed from  analysis of the logs of the HTTP(s) servers. An examination of the HTTP log files can reveal which URL name was used to retrieve a named URL web object, and if the experiment is careful to present a uniquely-named DNS name within each URL, then the URL names collected by the experiment’s servers can infer which clients were able to successfully resolve the corresponding DNS names.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 3 Jan 2018 09:11:00 +0000

On 02/01/2018 23:37, Paul Hoffman wrote:

> to return in the results. Using a new RRtype would have clearer semantics.

Actually, that wasn't my question at all.

The point I was trying to make (perhaps too obliquely) is that if you
are going to run this experiment from a browser, you'd better make sure
the IP address you return is one that's either under your control or
otherwise "harmless" when the browser subsequently tries to access it.

Using a new RRTYPE would be futile, since browsers don't know how to
access those.

Ray

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 03 Jan 2018 07:26:14 -0800

> Actually, that wasn't my question at all.

Sorry for indicating it was. It was also not (directly) Robert's 
question either. Robert asked "The first is the contents of the A/AAAA 
RRSET returned, and the second is the TTL for the records", and I took 
Geoff's lack of answer to mean that he wasn't going to use the result.

Geoff has now said "At the risk of heading waaaay down potentially 
spurious ratholes here let me quickly explain what I meant. Within the 
structure of a browser-based scripted test, such as you might find in an 
online ad script, the common operation within the script is to perform a 
GET of a URL." I did not realize that draft-ietf-dnsop-kskroll-sentinel 
was only meant for browser-based tests because there is no indication of 
this in the draft.

> otherwise "harmless" when the browser subsequently tries to access it.

Fully agree.

> Using a new RRTYPE would be futile, since browsers don't know how to

That is true for the "browser-based scripted test", definitely. If 
that's the sole motivation for this draft, then we need to stick with A 
/ AAAA records which will be specified in a future version of the draft.

--Paul Hoffman