And here some very quick comments on top of Warren's. I only looked at the pdf version. Warren Kumari writes:
On Fri, Feb 9, 2018 at 5:51 AM, Andrew Mcconachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus Members,
On behalf of the RSSAC please find the RSSAC FAQ attached for your review. Please provide comments/edits to the list or in the document by February 23rd, 2018.
Alright, comments: 1: The first entry has a lot of interesting, nicely written history on why there were 13. At the end of the answer it says that the original "limit" no longer applies -- this immediately raises the "so, if the limit has been removed, why aren't there 17? 42? 387? I think an additional few sentences clarifying that the limit no longer apples, but that we don't need more than 13 because of reasons...
We should insert here a reference to SSAC023
3: I find the answer to 3 to be unsatisfactory -- the answer doesn't really answer the question asked. DNSSEC protects individual data, but if an RSO downloads a zonefile which is truncated, or signatures don't validate, DNSSEC is very unlikely to solve this. Pointing out that DNSSEC saves resolvers from **believing** corrupt data would be good, but I think pointing at TSIG here would be a really good addition. "The transfer of the zonefile is protected with TSIG, but even in the unlikely event the file were to become corrupted after transfer, <dnssec, dnssec>."
Being pedantic, TSIG was/is actually part of the original DNSSEC specs. But yes, explicitly mentioning TSIG is a what one really need here.
11: This starts off really well, but many people will not actually analyze the traffic. I suspect a short insertion of "the vast vast majority of your DNS traffic is either answered out of your local cache, or is for names below the root. The TTL on most TLDs is <number>, a vanishingly small amount of your queries get answered by root servers. <data>" -- many of the "but i need a local root" people I've spoken with seem to believe that all of their queries touch the root, and so 100ms sounds bad (but 1 in a <large number> of queries needing 100ms sounds fine). Perhaps a pointer to Q24 would help?
That won't hurt. Also, a reference to actual measurements, such as dnsmon <https://atlas.ripe.net/dnsmon/> will also be illustrative. (Shows the latency of most servers is below 60 ms as in <https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-66-66-99-100...>).
20: The answer doesn't really seem related to the question. There was also a proposal a while back for a shared anycast address for root servers, so anyone *could* do this (al la AS112). I think this answer needs much rewriting / work.
Agreed. Also with the comment[5] that it should probably left out. I also thing that it is probably not a great idea to speculate in answers what might maybe change in future.
I find the last set of answers inadequate.
22: Time requirements. If I asked this question, and got this answer, I'd not be satisfied -- it feels evasive / incomplete. If I asked this and got this as an answer I'd feel that you are not answering because you don't want me to apply.
How many hours would you **like** RSSAC Caucus members to be contributing? If I wanna join the caucus, but can only contribute 15 minutes a year, is that useful? Do most caucus members work on RSSAC stuff 35 hours a week? Yes, different people contribute different amounts, and it is bursty, but the above answers feel like: A: you want to grow RSSAC C so that there are lots of people for optics reasons / quantity over quality ("we've got 10,000 members, so obviously we are transparent and listening to the community") or: B: someone just asked the question and you were running off to the restroom and gave a throw away answer or C: it is so exclusive that only a small number of people can devote enough time (in direct contradiction to A :-)). Perhaps asking the caucus members how much time they are currently contributing (sadly, for most of us, *very* little) or say something like: "ideally we'd love it if members could contribute a few hours a week. Currently most people aren't, but as we have more projects, <blah>).
Agree about rephrasing the question to something more substantial (as proposed in the "Perhaps ..."
23. "Do root servers control where Internet traffic goes? No, routers and the BGP protocol determine the path that packets take through the network on their way from source to destination." Well, yes and no. I know what the answer is trying to say, but "Internet traffic" is sufficiently broad that this leaves many questions. The root servers definitely control where traffic goes, but at such a high level that this is also meaningless (if the IANA zone dropped .za, and the root server systems (correctly) answered with this, there would be much much less traffic heading towards South Africa. Yes, this is stretching the question to breaking point, but I think that the question should be tightened up. Note that I don't have a suggestion, and I understand the spirit behing the answer, but (as with all) feel free ot ignore / point out that this is ratholing.
Isn't there an article/paper about this subject we can point to. That prevent the ratholing and/or turning this FAQ into a version of "Internet for dummies". I remember that ISOC.org has some introductory papers.
25. "Are administration of the root zone and service provisioning of the root zone the same thing? Administration of the root zone is separate from service provision."
I find this answer to be not useful. Someone knowing what the terms "administration of the root zone" and "service provisioning of the root zone" are sufficiently deep in the system that they know that -- and people who *don't know what the terms mean are simply going to be more confused. I suggest either explaining this in baby words ("the people who make the zone file (IANA) and the people who serve it (rso) are different. Root server people have no control over what goes in the zone file, and we are more than fine with that... "? )
Although it isn't really introductory material, a references to the root zone management pages <https://www.iana.org/domains/root>, the root server pages (root-servers.org, that site could use some work) might be useful. Refer to Question 18 as well.
"29. Do the root servers only receive the TLD portion of the DNS query? Historically, root servers (and indeed all DNS servers) received the entire query name in the DNS request. In 2016, the IETF published RFC 7816, which describes how DNS clients can send only the smallest necessary part of the query name. This is called Query Name Minimisation."
Cool! So, is this a good thing? Why doe this happen? *Does* it now happen?! (perhaps add something that this improves user privacy by only exposing the minimum info necessary, but that it makes research / ops potentially harder. As of publishing this FAQ / <today>, somewhere around X% of queries are QNM, but that is increasing over time).
I'm not sure whether we can actually answer this X% on the moment> Somebody has done the research on that?
The purpose of this document, like any FAQ, is to answer questions that are frequently asked of the RSSAC. Most of the questions in this FAQ originate from audience members in the RSSAC’s tutorial sessions on the DNS Root Server System held at ICANN meetings. They have been collected here along with other common questions the RSSAC receives, and answers have been provided by RSSAC members.
Great -- I think that this is a really useful document, but could be even further improved.
And I think that a FAQ should not try to give all the answer, but also give pointers where detailed answers can be given.
Once the review is finished this document will become a web page hosted somewhere in the RSSAC section of the ICANN website. <https://www.icann.org/groups/rssac>
It will not be published as an RSSAC document with a number. And because it will be published as HTML we'll use links instead of footnotes for references. These don't work in the PDF, so you'll have to view the MS Word document if you want to see the URLs.
Now you tell me :-). jaap