[rssac-caucus] FOR REVIEW: RSSAC FAQ

[Wessels, Duane]

I'm still really struggling with the answer for #3.  Here's the current answer:


> The transfer of the root zone file from the Root Zone Maintainer (RZM) to the individual RSOs is protected by the use of TSIG resource records as described in RFC 2845. In the unlikely event the root zone were to get corrupted during transfer it is signed by DNSSEC.  One of the reasons that the root zone is signed is to enable the receiver of the zone or a resource record for a root zone record to know whether such corruption has occurred. One of the good arguments for having several operators and multiple servers per operator is to enable a requesting system to get the root zone or a resource record from another source.


My issues:

- I think "protected" can give the wrong impression because the TSIG key only authenticates the identify of the client/server, and does not validate the data. While it is factually correct to say that the zone transfer utilizes TSIG, it is not quite relevant to the question that was asked.

- I think its misleading to imply that RSOs are performing DNSSEC validation of received zones before serving them.  AFAIK none are doing that.

- Similarly, the last sentence sort of implies that RSOs are getting the zone from another source, which is not true.

This would be my written answer to that question:

The transfer of the root zone file from the Root Zone Maintainer (RZM) to the individual RSOs occurs via the DNS zone transfer protocols (AXFR in RFC 5936 and IXFR in RFC 1995).  RSOs generally rely on AXFR/IXFR to correctly update and transfer the zone.  This is a reliable protocol and we are not aware of any incidents of data corruption within the last XX years.  Furthermore, since the root zone is signed, any corruption that might possibly occur can be detected by DNSSEC validators.  RSSAC encourages all recursive name server operators to enable DNSSEC validation when possible.



For #25 I think the answer (or perhaps the question) needs work.  The question specifically asks about "administration" vs "provisioning". This quickly becomes confusing because we have a number of related and loosely defined terms.  Pre-transition the NTIA was sometimes called the Root Zone Administrator (see 2010 KSK DPS), sometimes IANA is the Root Zone Manager (see https://www.iana.org/domains/root and 2016 KSK DPS).  The figure for #18 places IANA and Verisign/RZM under in the "provisioning" half of the diagram so I think we need to be very careful when using that term.


DW




> On Feb 26, 2018, at 8:54 AM, Andrew Mcconachie <andrew.mcconachie at icann.org> wrote:
> 
> Dear RSSAC Caucus Members,
> 
> The review period for the RSSAC FAQ closed on February 23rd. I have added text to the FAQ in response to your comments. Special thanks to Warren and Jaap who provided considerable comments. 
> 
> Please respond with any comments by the end of this week, March 2nd. Questions/answers where we don’t have good text we’re just going to leave out for now, as the Caucus can always return to them later. The RSSAC would very much like this on their website before ICANN 61.
> 
> A high-level changelog is below(numbers are from the FAQ):
> 1) Added links to more information.
> 3) Added text about TSIG for root zone transfer. Please review since this is largely outside of my expertise.
> 7) Looking for statistics on Dyn attack size vs RSS comparison. Otherwise will remove question.
> 8) Removed question.
> 11) Added sentence on caching and RIPE Atlast measurements.
> 20) Removed question.
> 22) Added text on Caucus time committments.
> 23) Added link to ISOC DNS for Dummies white paper and added DNS sentence.
> 24) Added sentence on caching in recursives.
> 25) Added links to the IANA RZM page and root-servers.org, added text on same.
> 29) Added text on QNAME Minimization. Looking for data on QNAME Minimization deployment.
> 
> Thanks,
> Andrew
> 
>> On Feb 9, 2018, at 11:51, 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.
>> 
>> 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.
>> 
>> 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_FAQ_v1.docx>
>> <RSSAC_FAQ_v1.pdf>
>> 
> 
> <RSSAC_FAQ_v2-CLEAN.docx>
> <RSSAC_FAQ_v2-REDLINE.docx>
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus