Re: [DNSOP] kskroll-sentinel responses

[Paul Hoffman]

On 3 Jan 2018, at 1:11, Ray Bellis wrote:


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

This answer doesn't seem to fully address Robert's and Ray's 
questions.

Why use an A/ query if you aren't going to do anything with the
result? If you are going to use A/, you have to tell resolvers 
what
to return in the results. Using a new RRtype would have clearer 
semantics.


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/ 
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 wy 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.



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.


Fully agree.


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


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 
/  records which will be specified in a future version of the draft.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] kskroll-sentinel responses

[Ray Bellis]

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

> This answer doesn't seem to fully address Robert's and Ray's questions.
> Why use an A/ query if you aren't going to do anything with the
> result? If you are going to use A/, you have to tell resolvers what
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] kskroll-sentinel responses

[Geoff Huston]

> On 3 Jan 2018, at 1:33 pm, Geoff Huston  wrote:
> 
>> This answer doesn't seem to fully address Robert's and Ray's questions. Why 
>> use an A/ query if you aren't going to do anything with the result? If 
>> you are going to use A/, 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  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.
> 

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

At the risk of heading wy 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.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] kskroll-sentinel responses

[Geoff Huston]

> This answer doesn't seem to fully address Robert's and Ray's questions. Why 
> use an A/ query if you aren't going to do anything with the result? If 
> you are going to use A/, 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  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  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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] kskroll-sentinel responses

[Paul Hoffman]

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


On 22 Dec 2017, at 8:44 am, Ray Bellis  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/ RRSET returned, and the 
second

is the TTL for the records.

Maybe the A/ 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/ query if you aren't going to do anything with the 
result? If you are going to use A/, you have to tell resolvers what 
to return in the results. Using a new RRtype would have clearer 
semantics.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] kskroll-sentinel responses

[Paul Hoffman]

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

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.


Exactly right. Having a browser run this test can easily lead to false 
positive and false negative results for a user who expects that seeing 
something in their browser means something.


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.


... for the current set of resolvers that you are using. A quite 
believable scenario is that while you're sitting in a coffee shop, you 
get one set of results, but a different set when you change to your home 
ISP or your organization's network.



From a large enough sample of users was
can then estimate the 'impact' of a KSK roll on the total user
population.


To get a good estimate, you'll need to sample the same user multiple 
times, looking for changes in the results. The design methodology for 
such a study will be daunting.


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.


Agree. Note, however, that the sentinel can indeed be used to isolate 
the behavior of a single resolver if you run the test against a known 
address, not against "whatever /etc/resolv.conf gives me".



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.


How can this protocol tell the set of resolvers that the user's DNS is 
configured to use? Either you are seeing the results as an amorphous 
blob (as described in Section 4), or as a specific result because you 
are sending the queries to a single known resolver address.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] kskroll-sentinel responses

[Geoff Huston]

> On 22 Dec 2017, at 8:44 am, Ray Bellis  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/ RRSET returned, and the second
>> is the TTL for the records.
>> 
>> Maybe the A/ 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] kskroll-sentinel responses

[Ray Bellis]

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/ RRSET returned, and the second
> is the TTL for the records.
> 
> Maybe the A/ 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)

Ray

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] kskroll-sentinel responses

[Robert Story]

I reread the draft today, and noticed that two things aren't specified.
The first is the contents of the A/ RRSET returned, and the second
is the TTL for the records.

Maybe the A/ 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.

-- 
Robert Story 
USC Information Sciences Institute 


pgpwVyffI5pQ4.pgp
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop