[rssac-caucus] FOR REVIEW: RSSAC FAQ

Mon Feb 12 11:45:02 UTC 2018

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 at 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&dnsmon.session.exclude-errors=true&dnsmon.session.color_range_rtt=0-60-60-250-5000&dnsmon.session.color_range_relative-rtt=0-125-125-200-1000&dnsmon.type=zone-servers&dnsmon.zone=root&dnsmon.maxProbes=undefined&dnsmon.startTime=1518394200&dnsmon.endTime=1518427800&dnsmon.filterProbes=false&dnsmon.ipVersion=both&dnsmon.isTcp=false>).

 > 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