[rssac-caucus] FOR REVIEW: RSSAC FAQ

Fri Feb 9 13:28:24 UTC 2018

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...

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>."

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?

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.

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>).

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.

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... "? )

"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).

> 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.

>
> 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.
>
> Thanks,
> Andrew
>
>
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf