Perhaps: OLD: 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 The reasons that the root zone is signed is to enable the receiver of a the zone file or a resource record for a root zone record to know whether such corruption has occurred. NEW: The transfer of the root zone file from the Root Zone Maintainer (RZM) to the individual RSOs is protected through the use of TSIG (as described in RFC 2845). In the unlikely event the root zone became corrupted during transfer (or were intentionally corrupted), DNSSEC would mitigate the effect of the corruption. DNSSEC allows validating resolvers to detect, and discard incorrectly signed or corrupt resource records. The previous made it sound like it gets signed by DNSSEC *if* it got corrupted, or that DNSSEC was largely created to protect against TSIG corruption. Also, the "or intentional" but helps reinforce that RSOs cannot twiddle the zone themselves. Thanks for the edits, this version looks much improved, W On Mon, Feb 26, 2018 at 11:54 AM, Andrew Mcconachie <andrew.mcconachie@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@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-caucus mailing list rssac-caucus@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