Re: [DNSOP] kskroll-sentinel responses
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
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
> 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
> 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
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
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
> 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
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