Dear RSSAC Caucus, According to the RSSAC work plan the RSSAC reviews and, if necessary, publishes an updated FAQ in December each year. <https://www.icann.org/groups/rssac/faq <https://www.icann.org/groups/rssac/faq>> Please take a look at the RSSAC FAQ and if you think there need to be any changes made please suggest them to the list. If there is interest in updating an answer or adding a new question/answer I will start a Google doc and we can work on refining the language. If there are no suggested changes by December 2nd we can consider the FAQ reviewed and not publish an updated one this year. Thanks, Andrew
Random thoughts for discussion: Do we want to add text about RFC8976 message digests? (maybe adding to 2.2, though it's not quite perfect) Maybe for 2.6 we should say "though the root server system has been globally attacked in the past, no attack has ever been successful in taking the whole system down". For 3.3 we could add a point that latency to the root server system is not as critical as latency to pretty much everything else. But worded better :-P 4.1 and 4.3 really feel out of scope for an RSSAC document. Useful information, but odd that we're talking about non-root specific items. 5.2 or a new 5.3: add information about the GWG maybe? On Fri, Nov 18, 2022 at 5:15 AM Andrew McConachie < andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus,
According to the RSSAC work plan the RSSAC reviews and, if necessary, publishes an updated FAQ in December each year. <https://www.icann.org/groups/rssac/faq>
Please take a look at the RSSAC FAQ and if you think there need to be any changes made please suggest them to the list. If there is interest in updating an answer or adding a new question/answer I will start a Google doc and we can work on refining the language.
If there are no suggested changes by *December 2nd* we can consider the FAQ reviewed and not publish an updated one this year.
Thanks, Andrew
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Wes Hardaker USC/ISI
* Paragraph 5. Change “more than 1000 anycast instances” to “more than 1500 anycast instances”. We should be proud of those extra 500 ! 😊 2.2. Should we mention that keys for TSIG are changed regularly? 2.7. Reference RFC 8806 2.<new> What about an entry to show how to identify which RSI instance you are getting a response from? (i.e. CHAOS TXT hostname.bind). Or is that just asking for trouble when someone finds out they are using an instance that they think is non-optimal? We would need a good explanation of how the route is chosen (i.e. not by the RSS) and how it can change over time 5.<new> Where can I find RSSAC publications? https://www.icann.org/groups/rssac/documents -Ken From: rssac-caucus <rssac-caucus-bounces@icann.org> on behalf of Andrew McConachie <andrew.mcconachie@icann.org> Date: Friday, November 18, 2022 at 8:15 AM To: RSSAC Caucus <rssac-caucus@icann.org> Subject: [URL Verdict: Neutral][Non-DoD Source] [RSSAC Caucus] Annual RSSAC FAQ Review All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ________________________________ Dear RSSAC Caucus, According to the RSSAC work plan the RSSAC reviews and, if necessary, publishes an updated FAQ in December each year. <Caution-https://www.icann.org/groups/rssac/faq < Caution-https://www.icann.org/groups/rssac/faq > > Please take a look at the RSSAC FAQ and if you think there need to be any changes made please suggest them to the list. If there is interest in updating an answer or adding a new question/answer I will start a Google doc and we can work on refining the language. If there are no suggested changes by December 2nd we can consider the FAQ reviewed and not publish an updated one this year. Thanks, Andrew
On 18/11/2022 20:12, Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus wrote:
2.<new> What about an entry to show how to identify which RSI instance you are getting a response from? (i.e. CHAOS TXT hostname.bind). Or is that just asking for trouble when someone finds out they are using an instance that they think is non-optimal? We would need a good explanation of how the route is chosen (i.e. not by the RSS) and how it can change over time
Yes we should, and yes, we should explain that too. Ray
Dear All, I created a Google doc for updating the FAQ. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo... <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qoLCs/>> I made the suggestions I saw on list except I didn’t add anything about ZONEMD or the GWG. If someone would like to add those topics please go ahead. I wasn’t quite sure what to write on them. For now let’s see how much editing we can do on the Google doc. If we need a call we can arrange one, but let’s not do that until we’re sure we do actually need a call. Thanks, Andrew
On 18 Nov 2022, at 21:21, Ray Bellis <ray@isc.org> wrote:
On 18/11/2022 20:12, Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus wrote:
2.<new> What about an entry to show how to identify which RSI instance you are getting a response from? (i.e. CHAOS TXT hostname.bind). Or is that just asking for trouble when someone finds out they are using an instance that they think is non-optimal? We would need a good explanation of how the route is chosen (i.e. not by the RSS) and how it can change over time
Yes we should, and yes, we should explain that too.
Ray
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hello, I tried to add a suggestion of a sentence at the end of section 2.8-ALT which results in an unexpected series of small chunked additions. I'm sorry for bloating edit history. Best Regards, -- Yoshitaka Aharen <aharen@jprs.co.jp> Japan Registry Services Co., Ltd. On Mon, 21 Nov 2022 10:20:00 +0000 Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear All,
I created a Google doc for updating the FAQ. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo... <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qoLCs/>>
I made the suggestions I saw on list except I didn’t add anything about ZONEMD or the GWG. If someone would like to add those topics please go ahead. I wasn’t quite sure what to write on them.
For now let’s see how much editing we can do on the Google doc. If we need a call we can arrange one, but let’s not do that until we’re sure we do actually need a call.
Thanks, Andrew
On 18 Nov 2022, at 21:21, Ray Bellis <ray@isc.org> wrote:
On 18/11/2022 20:12, Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus wrote:
2.<new> What about an entry to show how to identify which RSI instance you are getting a response from? (i.e. CHAOS TXT hostname.bind). Or is that just asking for trouble when someone finds out they are using an instance that they think is non-optimal? We would need a good explanation of how the route is chosen (i.e. not by the RSS) and how it can change over time
Yes we should, and yes, we should explain that too.
Ray
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Dear all, RSSAC Admin Committee decided to organize a teleconference to update the FAQ. I set up a doodle poll to identify a good time between 13-22 December to have such a teleconference. If you are interested in joining, please complete this doodle poll by end of business in your time zone on Thursday, 8 December 2022: https://doodle.com/meeting/participate/id/dGvOP6Jb. Best, Ozan Sahin Policy Development Support Senior Specialist Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +90 533 641 0007 Skype: ozan.sahin.icann www.icann.org<applewebdata://021EB1F1-F6B6-443A-908F-419605BF3A61/www.icann.org> From: rssac-caucus <rssac-caucus-bounces@icann.org> on behalf of Andrew McConachie <andrew.mcconachie@icann.org> Date: 21 November 2022 Monday 13:20 To: RSSAC Caucus <rssac-caucus@icann.org> Subject: Re: [RSSAC Caucus] Annual RSSAC FAQ Review Dear All, I created a Google doc for updating the FAQ. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo...> I made the suggestions I saw on list except I didn’t add anything about ZONEMD or the GWG. If someone would like to add those topics please go ahead. I wasn’t quite sure what to write on them. For now let’s see how much editing we can do on the Google doc. If we need a call we can arrange one, but let’s not do that until we’re sure we do actually need a call. Thanks, Andrew On 18 Nov 2022, at 21:21, Ray Bellis <ray@isc.org<mailto:ray@isc.org>> wrote: On 18/11/2022 20:12, Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus wrote: 2.<new> What about an entry to show how to identify which RSI instance you are getting a response from? (i.e. CHAOS TXT hostname.bind). Or is that just asking for trouble when someone finds out they are using an instance that they think is non-optimal? We would need a good explanation of how the route is chosen (i.e. not by the RSS) and how it can change over time Yes we should, and yes, we should explain that too. Ray _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Dear RSSAC Caucus Members, Thanks for everyone who joined the productive to review the RSSAC FAQ comments on December 15th. I had an action item to clean up the document and merge the decisions that were made on the call. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo... <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qoLCs/>> I’ve done that and there are no outstanding suggestions in the Google doc. If you have any final comments please get them in the Google doc before January 3rd, 2023. Thanks, Andrew
On 5 Dec 2022, at 14:25, Ozan Sahin <ozan.sahin@icann.org> wrote:
Dear all,
RSSAC Admin Committee decided to organize a teleconference to update the FAQ. I set up a doodle poll to identify a good time between 13-22 December to have such a teleconference. If you are interested in joining, please complete this doodle poll by end of business in your time zone on Thursday, 8 December 2022: https://doodle.com/meeting/participate/id/dGvOP6Jb [doodle.com] <https://urldefense.com/v3/__https://doodle.com/meeting/participate/id/dGvOP6...>.
Best,
Ozan Sahin Policy Development Support Senior Specialist Internet Corporation for Assigned Names and Numbers (ICANN)
Mobile: +90 533 641 0007 Skype: ozan.sahin.icann www.icann.org <applewebdata://021EB1F1-F6B6-443A-908F-419605BF3A61/www.icann.org>
From: rssac-caucus <rssac-caucus-bounces@icann.org> on behalf of Andrew McConachie <andrew.mcconachie@icann.org> Date: 21 November 2022 Monday 13:20 To: RSSAC Caucus <rssac-caucus@icann.org> Subject: Re: [RSSAC Caucus] Annual RSSAC FAQ Review
Dear All,
I created a Google doc for updating the FAQ. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo... [docs.google.com] <https://urldefense.com/v3/__https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qoLCs/__;!!PtGJab4!5amsD-jsODTvWz2tN103rElla7j7ounJ4A4WqRvfB0mridZtvmz0nF0Pbzpn8ueHb4KsRFj4tZDeWTlCQ2yGAxhFwTycbX44$>>
I made the suggestions I saw on list except I didn’t add anything about ZONEMD or the GWG. If someone would like to add those topics please go ahead. I wasn’t quite sure what to write on them.
For now let’s see how much editing we can do on the Google doc. If we need a call we can arrange one, but let’s not do that until we’re sure we do actually need a call.
Thanks, Andrew
On 18 Nov 2022, at 21:21, Ray Bellis <ray@isc.org <mailto:ray@isc.org>> wrote:
On 18/11/2022 20:12, Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus wrote:
2.<new> What about an entry to show how to identify which RSI instance you are getting a response from? (i.e. CHAOS TXT hostname.bind). Or is that just asking for trouble when someone finds out they are using an instance that they think is non-optimal? We would need a good explanation of how the route is chosen (i.e. not by the RSS) and how it can change over time
Yes we should, and yes, we should explain that too.
Ray
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Dec 20, 2022, at 4:21 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Thanks for everyone who joined the productive to review the RSSAC FAQ comments on December 15th.
I had an action item to clean up the document and merge the decisions that were made on the call. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo...>
I’ve done that and there are no outstanding suggestions in the Google doc. If you have any final comments please get them in the Google doc before January 3rd, 2023.
I have made a few small editorial changes. However, I still have a deep concern about question 4.2. If we answer it honestly, it's only going to confuse readers. I propose that we remove it. --Paul Hoffman
On 20 Dec 2022, at 16:26, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Dec 20, 2022, at 4:21 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Thanks for everyone who joined the productive to review the RSSAC FAQ comments on December 15th.
I had an action item to clean up the document and merge the decisions that were made on the call. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo...>
I’ve done that and there are no outstanding suggestions in the Google doc. If you have any final comments please get them in the Google doc before January 3rd, 2023.
I have made a few small editorial changes. However, I still have a deep concern about question 4.2. If we answer it honestly, it's only going to confuse readers. I propose that we remove it.
Dear All, This is the one outstanding issue remaining with the FAQ. Paul is suggesting deleting question 4.2, but I would like to hear some other opinions from the Caucus before doing so. Below is the 4.2 question and answer for your review.
4.2 Is there any chance of the root zone files getting corrupted by any attack or malware?
RFC 8976 defines a mechanism for ensuring the integrity of a DNS zone file using a ZONEMD record that "provides a cryptographic message digest over DNS zone data at rest”. As noted in a statement published by the root-server operators, RSOs will not enable ZONEMD verification for the first year after the initial publication of ZONEMD records. This is not deployed yet, but there are plans to do so in the future.
Thanks, Andrew
I also feel uncomfortable trying to address “corruption by attack or malware” here and I agree that the question does not really match the answer. Can we change the question? I think of the answer in 4.2 as an extension of the previous question (4.1 How do operators ensure that the root zone is properly replicated?). The ZONEMD answer applies to the root zone _file_, which can be used outside of RZM-to-RSO distribution, such as fetching root zone files for RFC 8806 operations. Proposed for discussion and word-smithing (new question and added last sentence to existing text): 4.2 Are there [other] ways to verify the integrity of the root zone data? RFC 8976<https://datatracker.ietf.org/doc/html/rfc8976> defines a mechanism for ensuring the integrity of a DNS zone file using a ZONEMD record that “provides a cryptographic message digest over DNS zone data at rest”. As noted in a statement published by the root-server operators, RSOs will not enable ZONEMD verification for the first year after the initial publication of ZONEMD records. This is not deployed yet, but there are plans to do so in the future. ZONEMD verification can also be used by other consumers of the root zone file (for example, recursive operators deploying RFC 8806) to verify the authenticity and integrity of the root zone data. -Ken From: rssac-caucus <rssac-caucus-bounces@icann.org> on behalf of Andrew McConachie <andrew.mcconachie@icann.org> Date: Wednesday, January 4, 2023 at 6:13 AM To: RSSAC Caucus <rssac-caucus@icann.org> Subject: [URL Verdict: Neutral][Non-DoD Source] Re: [RSSAC Caucus] Annual RSSAC FAQ Review All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. ----
On 20 Dec 2022, at 16:26, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Dec 20, 2022, at 4:21 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Thanks for everyone who joined the productive to review the RSSAC FAQ comments on December 15th.
I had an action item to clean up the document and merge the decisions that were made on the call. <Caution-https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo...>
I’ve done that and there are no outstanding suggestions in the Google doc. If you have any final comments please get them in the Google doc before January 3rd, 2023.
I have made a few small editorial changes. However, I still have a deep concern about question 4.2. If we answer it honestly, it's only going to confuse readers. I propose that we remove it.
Dear All, This is the one outstanding issue remaining with the FAQ. Paul is suggesting deleting question 4.2, but I would like to hear some other opinions from the Caucus before doing so. Below is the 4.2 question and answer for your review.
4.2 Is there any chance of the root zone files getting corrupted by any attack or malware?
RFC 8976 defines a mechanism for ensuring the integrity of a DNS zone file using a ZONEMD record that "provides a cryptographic message digest over DNS zone data at rest”. As noted in a statement published by the root-server operators, RSOs will not enable ZONEMD verification for the first year after the initial publication of ZONEMD records. This is not deployed yet, but there are plans to do so in the future.
Thanks, Andrew
I agree with Ken and like the new text. Talking about what we do to try and ensure the integrity of the root zone is one thing. Enumerating the endless ways things can go wrong is another, and IMHO out of scope. Regards, Robert On Wed 2023-01-04 11:46:06+0000 Kenneth D CTR USARMY DEVCOM ARL \(USA\) via rssac-caucus wrote:
I also feel uncomfortable trying to address “corruption by attack or malware” here and I agree that the question does not really match the answer. Can we change the question?
I think of the answer in 4.2 as an extension of the previous question (4.1 How do operators ensure that the root zone is properly replicated?). The ZONEMD answer applies to the root zone _file_, which can be used outside of RZM-to-RSO distribution, such as fetching root zone files for RFC 8806 operations.
Proposed for discussion and word-smithing (new question and added last sentence to existing text):
4.2 Are there [other] ways to verify the integrity of the root zone data?
RFC 8976<https://datatracker.ietf.org/doc/html/rfc8976> defines a mechanism for ensuring the integrity of a DNS zone file using a ZONEMD record that “provides a cryptographic message digest over DNS zone data at rest”. As noted in a statement published by the root-server operators, RSOs will not enable ZONEMD verification for the first year after the initial publication of ZONEMD records. This is not deployed yet, but there are plans to do so in the future. ZONEMD verification can also be used by other consumers of the root zone file (for example, recursive operators deploying RFC 8806) to verify the authenticity and integrity of the root zone data.
-- Robert Story USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
On Jan 4, 2023, at 3:46 AM, Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:
Proposed for discussion and word-smithing (new question and added last sentence to existing text): 4.2 Are there [other] ways to verify the integrity of the root zone data? RFC 8976 [datatracker.ietf.org] defines a mechanism for ensuring the integrity of a DNS zone file using a ZONEMD record that “provides a cryptographic message digest over DNS zone data at rest”. As noted in a statement published by the root-server operators, RSOs will not enable ZONEMD verification for the first year after the initial publication of ZONEMD records. This is not deployed yet, but there are plans to do so in the future. ZONEMD verification can also be used by other consumers of the root zone file (for example, recursive operators deploying RFC 8806) to verify the authenticity and integrity of the root zone data.
This still doesn't seem like a frequently-asked question. Even if it is, an answer that will only be true in the future doesn't seem useful in this version of the FAQ. After ZONEMD is deployed in the foot zone, this might be a more frequently-asked question, and this would be a reasonable answer except for the last sentence. RFC 8806 requires the resolver to use DNSSEC for validating the contents, and does not predict the future where there would be ZONEMD. Without the words in the parentheses, the last sentence is fine (well, will be fine in the future). --Paul Hoffman
This still doesn't seem like a frequently-asked question. Even if it is, an answer that will only be true in the future doesn't seem useful in this version of the FAQ.
These days the FAQ title is badly misnamed, and FAQs seem to be used more to publish answers to "expected questions" even in advance to the publication of the main content. I suspect the interpretation has shifted from truly FAQs to "this is a format that people like reading and can quickly skim to the part they're interested in". -- Wes Hardaker USC/ISI
On Jan 4, 2023, at 7:46 AM, Wes Hardaker <hardaker@isi.edu> wrote:
This still doesn't seem like a frequently-asked question. Even if it is, an answer that will only be true in the future doesn't seem useful in this version of the FAQ.
These days the FAQ title is badly misnamed, and FAQs seem to be used more to publish answers to "expected questions" even in advance to the publication of the main content. I suspect the interpretation has shifted from truly FAQs to "this is a format that people like reading and can quickly skim to the part they're interested in". --
I’m not in favor of removing 4.2. And I agree with Wes. Even though the question may not be frequently asked, this one was in fact asked during one of the RSSAC informational sessions at an ICANN meeting as I recall. DW
On Thu 2023-01-05 00:04:48+0000 Duane via rssac-caucus wrote:
I’m not in favor of removing 4.2.
And I agree with Wes. Even though the question may not be frequently asked, this one was in fact asked during one of the RSSAC informational sessions at an ICANN meeting as I recall.
Ok, what are you thoughts on Ken's changes? If we leave the question as is, then I think we have to say that there is always a chance of the zone being modified by an attack or malware. I'd much rather have the question be about additional protections than all the risks. -- Robert Story USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
Ok, what are you thoughts on Ken's changes? If we leave the question as is, then I think we have to say that there is always a chance of the zone being modified by an attack or malware. I'd much rather have the question be about additional protections than all the risks.
So I made a bunch of additions to 4.2 to hopefully provide better clarity through the question. See if it helps? -- Wes Hardaker USC/ISI
I have made a few clarifications to Wes' text, but it seems fine now. --Paul Hoffman
Dear All, I accepted all the edits and then changed the question 4.2 to, "What is ZONEMD and how can it protect the integrity of root zone data?”. This is the question that’s actually being answered, and I could tell from the discussion on list that no one particularly liked the question as written. Please take a look and provide any further comments if necessary. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo... <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qoLCs/>> Thanks, Andrew
On 5 Jan 2023, at 18:35, Paul Hoffman <paul.hoffman@icann.org> wrote:
I have made a few clarifications to Wes' text, but it seems fine now.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Dear All, Please finalize any comments you may have about the FAQ by January 19th. Unless there are new significant edits before then we will declare the document stable on January 19th. Thanks, Andrew
On 6 Jan 2023, at 12:17, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear All,
I accepted all the edits and then changed the question 4.2 to, "What is ZONEMD and how can it protect the integrity of root zone data?”. This is the question that’s actually being answered, and I could tell from the discussion on list that no one particularly liked the question as written.
Please take a look and provide any further comments if necessary. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo... <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qoLCs/>>
Thanks, Andrew
On 5 Jan 2023, at 18:35, Paul Hoffman <paul.hoffman@icann.org <mailto:paul.hoffman@icann.org>> wrote:
I have made a few clarifications to Wes' text, but it seems fine now.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Dear RSSAC Caucus, The RSSAC FAQ has been updated. Staff will now begin working on translations. <https://www.icann.org/groups/rssac/faq <https://www.icann.org/groups/rssac/faq>> Thanks, Andrew
On 12 Jan 2023, at 13:51, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear All,
Please finalize any comments you may have about the FAQ by January 19th. Unless there are new significant edits before then we will declare the document stable on January 19th.
Thanks, Andrew
On 6 Jan 2023, at 12:17, Andrew McConachie <andrew.mcconachie@icann.org <mailto:andrew.mcconachie@icann.org>> wrote:
Dear All,
I accepted all the edits and then changed the question 4.2 to, "What is ZONEMD and how can it protect the integrity of root zone data?”. This is the question that’s actually being answered, and I could tell from the discussion on list that no one particularly liked the question as written.
Please take a look and provide any further comments if necessary. <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo... <https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qoLCs/>>
Thanks, Andrew
On 5 Jan 2023, at 18:35, Paul Hoffman <paul.hoffman@icann.org <mailto:paul.hoffman@icann.org>> wrote:
I have made a few clarifications to Wes' text, but it seems fine now.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus <https://mm.icann.org/mailman/listinfo/rssac-caucus>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I am not in favor of its omission; instead I would suggest rephrasing it like "is there any chance the root zone files are getting altered in transit or beyond? Dessalegn On Wed, Jan 4, 2023 at 2:12 PM Andrew McConachie < andrew.mcconachie@icann.org> wrote:
On 20 Dec 2022, at 16:26, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Dec 20, 2022, at 4:21 AM, Andrew McConachie < andrew.mcconachie@icann.org> wrote:
Thanks for everyone who joined the productive to review the RSSAC FAQ
comments on December 15th.
I had an action item to clean up the document and merge the decisions
that were made on the call.
< https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo...
I’ve done that and there are no outstanding suggestions in the Google
doc. If you have any final comments please get them in the Google doc before January 3rd, 2023.
I have made a few small editorial changes. However, I still have a deep concern about question 4.2. If we answer it honestly, it's only going to confuse readers. I propose that we remove it.
Dear All,
This is the one outstanding issue remaining with the FAQ. Paul is suggesting deleting question 4.2, but I would like to hear some other opinions from the Caucus before doing so.
Below is the 4.2 question and answer for your review.
4.2 Is there any chance of the root zone files getting corrupted by any attack or malware?
RFC 8976 defines a mechanism for ensuring the integrity of a DNS zone file using a ZONEMD record that "provides a cryptographic message digest over DNS zone data at rest”. As noted in a statement published by the root-server operators, RSOs will not enable ZONEMD verification for the first year after the initial publication of ZONEMD records. This is not deployed yet, but there are plans to do so in the future.
Thanks, Andrew_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi All, I also agree with Paul, memory corruption is a bigger security threat and ZONEMD doesn't protect/address that well. Kind Regards Hafiz --- This message has been scanned via Symantec MessageLabs & SpamDefense Engine On Wed, Jan 4, 2023 at 2:12 PM Andrew McConachie < andrew.mcconachie@icann.org> wrote:
On 20 Dec 2022, at 16:26, Paul Hoffman <paul.hoffman@icann.org> wrote:
On Dec 20, 2022, at 4:21 AM, Andrew McConachie < andrew.mcconachie@icann.org> wrote:
Thanks for everyone who joined the productive to review the RSSAC FAQ
comments on December 15th.
I had an action item to clean up the document and merge the decisions
that were made on the call.
< https://docs.google.com/document/d/1_OOt0EBmEqkH5fCXWK4ts8946C7qeI6okDXtK0qo...
I’ve done that and there are no outstanding suggestions in the Google
doc. If you have any final comments please get them in the Google doc before January 3rd, 2023.
I have made a few small editorial changes. However, I still have a deep concern about question 4.2. If we answer it honestly, it's only going to confuse readers. I propose that we remove it.
Dear All,
This is the one outstanding issue remaining with the FAQ. Paul is suggesting deleting question 4.2, but I would like to hear some other opinions from the Caucus before doing so.
Below is the 4.2 question and answer for your review.
4.2 Is there any chance of the root zone files getting corrupted by any attack or malware?
RFC 8976 defines a mechanism for ensuring the integrity of a DNS zone file using a ZONEMD record that "provides a cryptographic message digest over DNS zone data at rest”. As noted in a statement published by the root-server operators, RSOs will not enable ZONEMD verification for the first year after the initial publication of ZONEMD records. This is not deployed yet, but there are plans to do so in the future.
Thanks, Andrew_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hello, As a comment, in question "2.7 How do I request an anycast instance of a root server for my organization?" probably we can add the text below (btw, I don't want "to sell" LACNIC). "LACNIC has a project called "+ Raices " (more roots), in case you are in the LACNIC's region and you would like to host an anycast root server copy, please contact LACNIC at raices@lacnic.net. More info at: https://www.lacnic.net/1031/2/lacnic/+raices " Regards, Alejandro Acosta, On 18/11/22 9:09 AM, Andrew McConachie wrote:
Dear RSSAC Caucus,
According to the RSSAC work plan the RSSAC reviews and, if necessary, publishes an updated FAQ in December each year. <https://www.icann.org/groups/rssac/faq>
Please take a look at the RSSAC FAQ and if you think there need to be any changes made please suggest them to the list. If there is interest in updating an answer or adding a new question/answer I will start a Google doc and we can work on refining the language.
If there are no suggested changes by *December 2nd* we can consider the FAQ reviewed and not publish an updated one this year.
Thanks, Andrew
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (12)
-
Alejandro Acosta -
Andrew McConachie -
Dessalegn Yehuala -
Hafiz Farooq -
Ozan Sahin -
Paul Hoffman -
Ray Bellis -
Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) -
Robert Story -
Wes Hardaker -
Wessels, Duane -
Yoshitaka Aharen