[rssac-caucus] Preliminary result in Resolver Study Work Party
Hi RSSAC Colleagues, I'm sorry and I missed last call for Resolver Study Work Party. I'm wondering is there any open document or preliminary result of this work party? I'm personally intereted in the resolver behavior on timeout and re-query. Can anyone give me some hint? Thanks, Davey
Mario, would you kindly add Davey to the Work Party mailer?
On Dec 19, 2018, at 4:39 PM, Davey Song <songlinjian@gmail.com> wrote:
I'm sorry and I missed last call for Resolver Study Work Party. I'm wondering is there any open document or preliminary result of this work party? I'm personally intereted in the resolver behavior on timeout and re-query. Can anyone give me some hint?
The SOW is at https://www.icann.org/en/system/files/files/rssac-sow-resolver-behaviors-07a.... We have "met", for some definition of that term, three times. The current progress is that: Paul Hoffman (ICANN) is building a testbed with the intention of facilitating replication, on the theory that science benefits when an experiment can be reproduced with the same or different results. He will be discussing that at our January meeting. Geoff Huston and Joao Damas are doing work at APNIC. I'm not sure what their schedule is, but they have discussed similarly documenting the means and logic behind their experiments. The experiments they carry out use a basic facility used by George Michelson and others at APNIC, which is "advertisements" carried by Google and others. It might be most easily explained using an example. https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=BE is derived from APNIC data. The advertisement, in this case, contains three URLs, which means that a client resolves three names and opens three TCP sessions. One name has only an A record, so the TCP session uses IPv4. The second name has only a AAAA record, so the TCP session uses IPv6. The third name has both an A and a AAAA record, and it can be interesting to observe which one it chooses. The first TCP session informs the experiment that a client is out there. The second, if its SYN arrives, tells the experiment that the path from client to server is IPv6-capable end to end, and the data shows the blue line indicating that there is a client out there that can possibly use IPv6. The third indicates a choice, and if the client chooses the AAAA record, the experiment reports that the client *prefers* IPv6. Now look at the web page. Geoff uses a similar mechanism but performs different experiments. Since he is running the resolver and the system the TCP sessions connect to, he can make a number of observations about clients and resolvers, and draws conclusions from them. He'll have to describe anything further (and that's what the Work Party is asking him or Joao to document for the call in January), but that gives you a flavor of what's going on. I have attached the information about the next call.
Hi Fred, Let me know follow up with Davey Song and the procedure to add him to the WP mailing list. Best, --- Mario A. Aleman Support Staff for RSSAC and RZERC Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 612-245-7112 www.icann.org <http://www.icann.org> On 12/19/18, 4:10 AM, "Fred Baker" <fredbakersba@gmail.com> wrote: Mario, would you kindly add Davey to the Work Party mailer? > On Dec 19, 2018, at 4:39 PM, Davey Song <songlinjian@gmail.com> wrote: > > I'm sorry and I missed last call for Resolver Study Work Party. I'm wondering is there any open document or preliminary result of this work party? I'm personally intereted in the resolver behavior on timeout and re-query. Can anyone give me some hint? The SOW is at https://www.icann.org/en/system/files/files/rssac-sow-resolver-behaviors-07a.... We have "met", for some definition of that term, three times. The current progress is that: Paul Hoffman (ICANN) is building a testbed with the intention of facilitating replication, on the theory that science benefits when an experiment can be reproduced with the same or different results. He will be discussing that at our January meeting. Geoff Huston and Joao Damas are doing work at APNIC. I'm not sure what their schedule is, but they have discussed similarly documenting the means and logic behind their experiments. The experiments they carry out use a basic facility used by George Michelson and others at APNIC, which is "advertisements" carried by Google and others. It might be most easily explained using an example. https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=BE is derived from APNIC data. The advertisement, in this case, contains three URLs, which means that a client resolves three names and opens three TCP sessions. One name has only an A record, so the TCP session uses IPv4. The second name has only a AAAA record, so the TCP session uses IPv6. The third name has both an A and a AAAA record, and it can be interesting to observe which one it chooses. The first TCP session informs the experiment that a client is out there. The second, if its SYN arrives, tells the experiment that the path from client to server is IPv6-capable end to end, and the data shows the blue line indicating that there is a client out there that can possibly use IPv6. The third indicates a choice, and if the client chooses the AAAA record, the experiment reports that the client *prefers* IPv6. Now look at the web page. Geoff uses a similar mechanism but performs different experiments. Since he is running the resolver and the system the TCP sessions connect to, he can make a number of observations about clients and resolvers, and draws conclusions from them. He'll have to describe anything further (and that's what the Work Party is asking him or Joao to document for the call in January), but that gives you a flavor of what's going on. I have attached the information about the next call.
Note that I believe we did create a mailing list for this WP, we've since agreed that all WP mail should be conducted on the global caucus list and we shouldn't use the WP specific mailing lists. On Wed, Dec 19, 2018 at 11:22 AM Mario Aleman <mario.aleman@icann.org> wrote:
Hi Fred,
Let me know follow up with Davey Song and the procedure to add him to the WP mailing list.
Best,
--- Mario A. Aleman Support Staff for RSSAC and RZERC Internet Corporation for Assigned Names and Numbers (ICANN)
Mobile: +1 612-245-7112 www.icann.org <http://www.icann.org>
On 12/19/18, 4:10 AM, "Fred Baker" <fredbakersba@gmail.com> wrote:
Mario, would you kindly add Davey to the Work Party mailer?
> On Dec 19, 2018, at 4:39 PM, Davey Song <songlinjian@gmail.com> wrote: > > I'm sorry and I missed last call for Resolver Study Work Party. I'm wondering is there any open document or preliminary result of this work party? I'm personally intereted in the resolver behavior on timeout and re-query. Can anyone give me some hint?
The SOW is at https://www.icann.org/en/system/files/files/rssac-sow-resolver-behaviors-07a.... We have "met", for some definition of that term, three times. The current progress is that:
Paul Hoffman (ICANN) is building a testbed with the intention of facilitating replication, on the theory that science benefits when an experiment can be reproduced with the same or different results. He will be discussing that at our January meeting.
Geoff Huston and Joao Damas are doing work at APNIC. I'm not sure what their schedule is, but they have discussed similarly documenting the means and logic behind their experiments. The experiments they carry out use a basic facility used by George Michelson and others at APNIC, which is "advertisements" carried by Google and others. It might be most easily explained using an example.
https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=BE is derived from APNIC data. The advertisement, in this case, contains three URLs, which means that a client resolves three names and opens three TCP sessions. One name has only an A record, so the TCP session uses IPv4. The second name has only a AAAA record, so the TCP session uses IPv6. The third name has both an A and a AAAA record, and it can be interesting to observe which one it chooses. The first TCP session informs the experiment that a client is out there. The second, if its SYN arrives, tells the experiment that the path from client to server is IPv6-capable end to end, and the data shows the blue line indicating that there is a client out there that can possibly use IPv6. The third indicates a choice, and if the client chooses the AAAA record, the experiment reports that the client *prefers* IPv6. Now look at the web page.
Geoff uses a similar mechanism but performs different experiments. Since he is running the resolver and the system the TCP sessions connect to, he can make a number of observations about clients and resolvers, and draws conclusions from them. He'll have to describe anything further (and that's what the Work Party is asking him or Joao to document for the call in January), but that gives you a flavor of what's going on.
I have attached the information about the next call.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- Wes Hardaker USC/ISI
On Wed, 19 Dec 2018 01:09:58 -0800, Fred Baker wrote:
Mario, would you kindly add Davey to the Work Party mailer?
On Dec 19, 2018, at 4:39 PM, Davey Song <songlinjian@gmail.com> wrote:
I'm sorry and I missed last call for Resolver Study Work Party. I'm wondering is there any open document or preliminary result of this work party? I'm personally intereted in the resolver behavior on timeout and re-query. Can anyone give me some hint?
The SOW is at https://www.icann.org/en/system/files/files/rssac-sow-resolver-behaviors-07a.... We have "met", for some definition of that term, three times.
That looks like an interesting study. There is some recent work related to some of the tasks: 1. Analyze DNS resolver network traffic and behaviour to better understand how they operate as they interact with authoritative servers generally and the RSS specifically in terms of preferred root server selection. => task 1 was I think discussed in [Mueller17b] 2. Analyze DNS resolver and authoritative server code bases and perform (ideally repeatable) simulations to further extract a model of how modern resolvers implement caching and priming of the root name servers. => task 2 was discussed in [Moura18b], at least in the context of DoS 3. Analyze DNS resolver code bases and perform (ideally repeatable) resolution simulations to further extract a model of how modern resolvers choose which authoritative server for a given zone to query. => Am I correct to read task 3 as like task 1, but about general authoritative servers and not just root servers? It would be interesting to know if anyone (or how many) treat the roots differently than general auths. 4. Analyze DNS resolver systems using multiple resolution instances (with potentially individual or shared caching systems) to understand how they interact with the RSS. (e.g. google, cloudflare, quad9 type systems) => Google was examined in [Schomp13a], although I'm sure it's changed since then, and it's only one example of a large parallel recursive resolver. But their methodology is solid and probably useful at looking at the new public DNS implementations. Specific references are below. It will be neat to see new results here---I think the prior work mainly used WAN experiments and traffic analysis, so examining code may lead to some new observations. Or things may have changed. I just wanted to mention them because The SOW at https://www.icann.org/en/system/files/files/rssac-sow-resolver-behaviors-07a... didn't mention any prior work, so it's a little hard to tell where it's starting. -John ---------------------------------------------------------------------- [Moura18b] Giovane C. M. Moura, John Heidemann, Moritz M{\"u}ller, Ricardo de O. Schmidt, and Marco Davids. When the Dike Breaks: Dissecting DNS Defenses During DDoS. In _Proceedings of the ACM Internet Measurement Conference_, October, 2018. <https://doi.org/10.1145/3278532.3278534>, <https://www.isi.edu/%7ejohnh/PAPERS/Moura18b.html>. [Mueller17b] Moritz M\"{u}ller, Giovane C. M. Moura, Ricardo de O. Schmidt, and John Heidemann. Recursives in the Wild: Engineering Authoritative DNS Servers. In _Proceedings of the ACM Internet Measurement Conference_, pp. 489-495. London, UK, 2017. <https://doi.org/10.1145/3131365.3131366>, <https://www.isi.edu/%7ejohnh/PAPERS/Mueller17b.html>. [Schomp13a] Kyle Schomp, Tom Callahan, Michael Rabinovich, and Mark Allman. On Measuring the Client-Side DNS Infrastructure. In _Proceedings of the ACM Internet Measurement Conference_, Barcelona, Spain, ACM. October, 2013. <http://conferences.sigcomm.org/imc/2013/papers/imc029-schompAemb.pdf>.
There is some recent work related to some of the tasks:
Hi John, Much of this work is covering not traffic analysis (though we'll likely do more of that as well), but focusing on simulations of real software and what each component does when thrown into a test network. Paul Hoffman has designed a testbed where various packages (bind, unbound, etc) can be watched carefully in a simulated environment. That should hopefully get us some ground truth, which we may then in turn be able to look to real world traffic and do some comparisons against it. Thanks for sending the papers, though, as it was on my todo list to send many of those to the group as well! -- Wes Hardaker USC/ISI
participants (5)
-
Davey Song -
Fred Baker -
John Heidemann -
Mario Aleman -
Wes Hardaker