[rssac-caucus] FOR REVIEW: RSSAC FAQ
Jaap Akkerhuis
jaap at NLnetLabs.nl
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
More information about the rssac-caucus
mailing list