[rssac-caucus] FOR REVIEW: RSSAC FAQ
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
On Fri, Feb 9, 2018 at 5:51 AM, 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.
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@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
On Feb 9, 2018, at 14:28, Warren Kumari <warren@kumari.net<mailto:warren@kumari.net>> wrote: 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. Thanks for all your comments and additions Warren. I should probably have mentioned in my first mail that I’ll be taking any proposed edits and incorporating them into a new version. There will then be a 48-hour review of that version for final commentary. After that it will be put up on the RSSAC’s website. Please continue commenting on the current draft. Thanks, Andrew
On Fri, Feb 9, 2018 at 8:28 AM, Warren Kumari <warren@kumari.net> wrote:
On Fri, Feb 9, 2018 at 5:51 AM, 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.
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>."
Yes, I agree - DNSSEC is not the answer to "How do you ensure that the root zone is properly replicated?" (I assume from the root zone maintainer to the root server operators. In fact, DNSSEC cannot be the answer to this because significant portions of the root zone data are not signed (e.g. non-authoritative data like delegation NS record sets and associated glue records). TSIG or some alternative form of cryptographically integrity protected transport mechanism is needed. Maybe the RSSAC FAQ can elaborate on what mechanisms are actually in place to ensure correct transfer of the root zone to to the RSOs. Shumon Huque.
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@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...>).
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
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<http://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<mailto: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>
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
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@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_FAQ_v2-CLEAN.docx> <RSSAC_FAQ_v2-REDLINE.docx> _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
On Mon, Feb 26, 2018 at 5:40 PM, Wessels, Duane via rssac-caucus < rssac-caucus@icann.org> wrote:
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.
Hi Duane and others, I don't think this is correct. TSIG authenticates an entire DNS message using a keyed hash (specifically HMAC-MD5, HMAC-SHA256, etc) computed over the message contents and some metadata. Assuming TSIG is being used to authenticate zone transfers, then each constituent DNS message in the zone transfer will have a TSIG signature placed in the OPT TSIG record. So in fact TSIG does protect zone transfers and will be able to detect corrupted transfers or MITM'd content. It *may* also be able to authenticate the identity of the client and server, but that depends on configuration details - for symmetric TSIG this would need distinct keys shared between client and server pairs (which generally should always be done, otherwise TSIG clients could fake zone transfers to one another). For public key (SIG0) you just need unique public key credentials per server.
- I think its misleading to imply that RSOs are performing DNSSEC validation of received zones before serving them. AFAIK none are doing that.
And it's also impossible. Paraphrasing what I said in my earlier note in this thread, which most people seemed to have ignored: DNSSEC can't validate the *full* contents of a zone if the zone has any non-authoritative data in it. This is abundantly true for the root zone (it has many child NS sets and glue address records - those don't have DNSSEC signatures so can't be validated). Nor was DNSSEC designed to fulfill that function. Here's what RFC 4035, Section 4 says: 4. Services Not Provided by DNS Security [....] The DNS security extensions provide data and origin authentication for DNS data. The mechanisms outlined above are not designed to protect operations such as zone transfers and dynamic update ([RFC2136], [RFC3007]). Message authentication schemes described in [RFC2845] and [RFC2931] address security operations that pertain to these transactions. Shumon Huque
On Mon, Feb 26, 2018 at 6:57 PM, Shumon Huque <shuque@gmail.com> wrote:
Here's what RFC 4035, Section 4 says:
4. Services Not Provided by DNS Security
[....]
The DNS security extensions provide data and origin authentication for DNS data. The mechanisms outlined above are not designed to protect operations such as zone transfers and dynamic update ([RFC2136], [RFC3007]). Message authentication schemes described in [RFC2845] and [RFC2931] address security operations that pertain to these transactions.
D'oh, I meant RFC 4033 ... https://tools.ietf.org/html/rfc4033#section-4 Shumon.
On Feb 26, 2018, at 3:57 PM, Shumon Huque <shuque@gmail.com> wrote:
Hi Duane and others,
I don't think this is correct. TSIG authenticates an entire DNS message using a keyed hash (specifically HMAC-MD5, HMAC-SHA256, etc) computed over the message contents and some metadata. Assuming TSIG is being used to authenticate zone transfers, then each constituent DNS message in the zone transfer will have a TSIG signature placed in the OPT TSIG record. So in fact TSIG does protect zone transfers and will be able to detect corrupted transfers or MITM'd content.
Ah, thanks for clarifying that. I should've read the TSIG RFC more carefully. I withdraw my objection to "protected"! another attempt: 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). These zone transfer messages are protected by the use of TSIG resource records as described in RFC 2845. This is a reliable protocol and we are not aware of any incidents of data corruption. Furthermore, since the root zone is signed, incorrect or falsified answers can be detected by DNSSEC validators. RSSAC encourages all recursive name server operators to enable DNSSEC validation when possible.
And it's also impossible.
Paraphrasing what I said in my earlier note in this thread, which most people seemed to have ignored: DNSSEC can't validate the *full* contents of a zone if the zone has any non-authoritative data in it. This is abundantly true for the root zone (it has many child NS sets and glue address records - those don't have DNSSEC signatures so can't be validated). Nor was DNSSEC designed to fulfill that function.
Yes, agreed. I did gloss over that point. DW
On Mon, Feb 26, 2018 at 7:12 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
On Feb 26, 2018, at 3:57 PM, Shumon Huque <shuque@gmail.com> wrote:
Hi Duane and others,
I don't think this is correct. TSIG authenticates an entire DNS message using a keyed hash (specifically HMAC-MD5, HMAC-SHA256, etc) computed over the message contents and some metadata. Assuming TSIG is being used to authenticate zone transfers, then each constituent DNS message in the zone transfer will have a TSIG signature placed in the OPT TSIG record. So in fact TSIG does protect zone transfers and will be able to detect corrupted transfers or MITM'd content.
Ah, thanks for clarifying that. I should've read the TSIG RFC more carefully. I withdraw my objection to "protected"!
another attempt:
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). These zone transfer messages are protected by the use of TSIG resource records as described in RFC 2845. This is a reliable protocol and we are not aware of any incidents of data corruption. Furthermore, since the root zone is signed, incorrect or falsified answers can be detected by DNSSEC validators. RSSAC encourages all recursive name server operators to enable DNSSEC validation when possible.
Looks good to me. I still think that we should s/of TSIG resource records/of TSIG/ -- TSIG uses RRs, but they are hidden, and I'm concerned someone will go digging for them -- but, I don't really care. W
And it's also impossible.
Paraphrasing what I said in my earlier note in this thread, which most people seemed to have ignored: DNSSEC can't validate the *full* contents of a zone if the zone has any non-authoritative data in it. This is abundantly true for the root zone (it has many child NS sets and glue address records - those don't have DNSSEC signatures so can't be validated). Nor was DNSSEC designed to fulfill that function.
Yes, agreed. I did gloss over that point.
DW
_______________________________________________ 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
On Feb 26, 2018, at 4:16 PM, Warren Kumari <warren@kumari.net> wrote:
Looks good to me. I still think that we should s/of TSIG resource records/of TSIG/ -- TSIG uses RRs, but they are hidden, and I'm concerned someone will go digging for them -- but, I don't really care.
yeah, removing "resource records" there is fine with me too. DW
On Mon, Feb 26, 2018 at 7:12 PM, Wessels, Duane <dwessels@verisign.com> wrote:
Ah, thanks for clarifying that. I should've read the TSIG RFC more carefully. I withdraw my objection to "protected"!
another attempt:
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). These zone transfer messages are protected by the use of TSIG resource records as described in RFC 2845. This is a reliable protocol and we are not aware of any incidents of data corruption. Furthermore, since the root zone is signed, incorrect or falsified answers can be detected by DNSSEC validators. RSSAC encourages all recursive name server operators to enable DNSSEC validation when possible.
Looks good to me! Shumon.
Dear RSSAC Caucus Members, The RSSAC FAQ is now up on the RSSAC section of the ICANN website. <https://www.icann.org/groups/rssac/faq> A high-level changelog is below: - Accepted all of Paul Hoffman’s edits. - Accepted text from the list for answer #3. (The TSIG question.) - Removed question #25. Thanks everyone who helped create and review the FAQ. Thanks, Andrew On Feb 26, 2018, at 17:54, Andrew Mcconachie <andrew.mcconachie@icann.org<mailto: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<http://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<mailto: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_FAQ_v2-CLEAN.docx> <RSSAC_FAQ_v2-REDLINE.docx> _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
participants (6)
-
Andrew Mcconachie -
Jaap Akkerhuis -
Paul Hoffman -
Shumon Huque -
Warren Kumari -
Wessels, Duane