> On 22 Dec 2017, at 8:44 am, Ray Bellis <r...@bellis.me.uk> 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
