[rssac-caucus] REMINDER - FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Dear RSSAC Caucus, This is a reminder for you to review the draft report on TTLs for the root zone. The review is due by close of business 15 June 2015. In particular in your review, it would be great if you could comment on: 1) whether there are any factual errors with the document. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies 3) whether you agree with the findings of the report 4) whether you agree with the recommendations in this report 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred? Also, are there any interest to have a briefing call on this report? Right now, the most likely time would be Monday 15 June. Thanks, Steve From: Steve Sheng <steve.sheng@icann.org> Date: Monday, June 8, 2015 at 1:37 PM To: "rssac-caucus@icann.org" <rssac-caucus@icann.org> Subject: [rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Dear RSSAC Caucus,
On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt.
Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today¹s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review.
One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone¹s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area.
The work party chair requests you provide your review by close of business (anywhere around the world) 15 June 2015, if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires.
All the best, Steve
Hi, Please find my comments. I found the document very interesting, and pleasant to read. Regarding Steve's questions, here is my opinions. 1) whether there are any factual errors with the document. I did not see any factual error. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies Regarding the methodology, my understanding is that there is an impressive survey of the TTL values used that are related to the one specified in the root zone. In addition to this section I think it would be beneficial to have: - 1) a description of the impact of the TTL on ICANN operations on the root zone. Such operations may be for example addition/removal of a new gTLD, key roll over, emergency key roll-over - of course, the topic should remain the TTLs. - 2) a "theoretical" section that details what RFCs recommends for the various TTL settings. From this section I believe we should be able to be able to have a theoretical model, and describe theoretically how TTLs impact the ICANN operations on the root zone as well as the expected impacts on the traffic. I would also see that section 6.4 can fall into such a section. 3) whether you agree with the findings of the report I agree with the findings. However, saying that the value should not be changed because most client ignore it does not seems satisfactory. First I would say that the boundary seems to be the "max-cache-ttl" value, and having TTL values below it would probably have a major impact. In fact for most of the traffic, max-cache-ttl overwrites the TTL and becomes the de-facto TTL. I think we should elaborate a bit more about has the right TTL value (the root zone or the max-cache-ttl), and see if there are any recommendations to do for the max-cache-ttl value. I also understand it may be out of scope of the root zone TTL, but change of this value probably impact more the root zone traffic than the current TTL. 4) whether you agree with the recommendations in this report I agree with the recommendations. However, I think we should also comment on the max-cache-ttl. As TTL is related to caching, I also think there should be some additional items on how these caches may be flushed by an authoritative party -- I am really thinking of the red button Joe Abley talked about in case of a emergency key-roll over, but it looks this could be useful in other situations. Maybe we should also see some debugging indications when a badly cached value is stored -- again I am mostly thinking of outdated signatures RRsets cached. 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred? I also found I couple of nits in the document. 1) introduction: The document uses the term "Internet Community": I am wondering whether this community is identified enough to named as such or if Internet community would be more appropriated. 2) section 3: Types of data in the DNS Root zone: I think that some clarifications should be made in section 3 regarding the type of data. I found it quite confusing to read that most authoritative data are 1d TTL as most NS have 2d TTLs. This comes from the fact that TLD NS are not part of the authoritative data. I looked at dratf-ietf-dnsop-dns-terminology and checked that whether TLD NS are authoritative data or not is somehow confusing. So I would suggest to explicitly state it. The text I would propose could be something like: "In this section we considered three types of DNS data. - authoritative data : the data the root zone has authority for. In our case, we did not consider the TLD NS nor the TLD Glue RRsets (A, AAAA). - delegation: The definition provided by the terminology section does not fit here as it is not a process. - glue: (cf terminology section) " Another alternative could also consists in clarifying the usage in the terminology section. At last is there any need to have a specific terminology for these authoritative RRsets and have it mentioned in the dns-terminology draft ? 3) section 3 "glue TTLs match their associated NS TTLs" I think we should specify whether this is something observed or if this follows some operational guidance. 4) section 3.1 "which means it has a negative caching TTL of 1 day". I think this may impact the publication of gTLD. as well as emergency key-roll over. 5) section 6.1.1 The graph below shows each TLD’s authoritative NS TTL (y-axis) and its query count in the 2014 DITL data (x-axis). While there are certainly a large number of less-popular TLDs with large RTTs, by looking at the lower right section of the graph we can see that the more-popular TLDs tend to have larger RTTs (Round Trip Times). In other words, there are no popular TLDs with small RTTs. Overall, 90% of queries in 2014 DITL data were to TLDs having NS TTLs greater than or equal to 1 day. I do not see the relation with RTT. Isn't misspelling of TTL? 6) section 6.2 "The authoritative server returns the TXT record without a 10-day TTL." Shouldn't be "with" instead of without? 7) section 6.3 "The study team did find 20% of the IPs made only one request for delegated TLDs during collection . ". Shouldn't it be "data collection period" instead? idem for "Nearly 20% of the IPs made only request for delegated TLDs during collection". 8) Section 6.3 "IPs sending queries (red line) and providing measurements (blue line)." or the legend Queries/Measures in figure 4 does not make obvious the difference between the two lines. Maybe that would be better to clarify that explicitly. 9) section 6.3 "Figure 6 and Table 8 below shows" Shouldn't it be "show" 10) section 6.4.1/ section 7 Findings 4: lots of missing white space after ".". 11) section 6.4.1 Is there any reason the relation between the different Time is not expressed. SOA_Expire + NS_TTL <= ZSK_validity 12) section 6.4.2 "Just before day 10, a root server instance experiences a problem which prevents the it from receiving zone" Shouldn't we remove "the"? 13) Findings 2: "This likely means that root zone TTLs could be reduced to 1 day without any significant impact on traffic levels to root name servers" Is that intentional to repeat the sentence? 14) Findings 6: "In Section 6.4, the study team identifies two situations whereby a root name server would return data and signatures that will be cached beyond the signature validity end time. Specifically, in certain situations: " Do we have any kind of formal proof that there is no other corner cases. 15) section 9: Don't we need DNSSEC mitigation mechanisms to flush cache for example.? On Thu, Jun 11, 2015 at 12:41 PM, Steve Sheng <steve.sheng@icann.org> wrote:
Dear RSSAC Caucus,
This is a reminder for you to review the draft report on TTLs for the root zone. The review is due by close of business *15 June 2015.*
In particular in your review, it would be great if you could comment on:
1) whether there are any factual errors with the document. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies 3) whether you agree with the findings of the report 4) whether you agree with the recommendations in this report 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
Also, are there any interest to have a briefing call on this report? Right now, the most likely time would be Monday 15 June.
Thanks, Steve
From: Steve Sheng <steve.sheng@icann.org> Date: Monday, June 8, 2015 at 1:37 PM To: "rssac-caucus@icann.org" <rssac-caucus@icann.org> Subject: [rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Dear RSSAC Caucus,
On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt.
Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today’s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review.
One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone’s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area.
The work party chair requests you provide your review by close of business (anywhere around the world) *15 June 2015, *if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires.
All the best, Steve
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160
Thanks Daniel! Steve On Jun 15, 2015, at 8:57 AM, Daniel Migault <mglt.biz@gmail.com<mailto:mglt.biz@gmail.com>> wrote: Hi, Please find my comments. I found the document very interesting, and pleasant to read. Regarding Steve's questions, here is my opinions. 1) whether there are any factual errors with the document. I did not see any factual error. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies Regarding the methodology, my understanding is that there is an impressive survey of the TTL values used that are related to the one specified in the root zone. In addition to this section I think it would be beneficial to have: - 1) a description of the impact of the TTL on ICANN operations on the root zone. Such operations may be for example addition/removal of a new gTLD, key roll over, emergency key roll-over - of course, the topic should remain the TTLs. - 2) a "theoretical" section that details what RFCs recommends for the various TTL settings. From this section I believe we should be able to be able to have a theoretical model, and describe theoretically how TTLs impact the ICANN operations on the root zone as well as the expected impacts on the traffic. I would also see that section 6.4 can fall into such a section. 3) whether you agree with the findings of the report I agree with the findings. However, saying that the value should not be changed because most client ignore it does not seems satisfactory. First I would say that the boundary seems to be the "max-cache-ttl" value, and having TTL values below it would probably have a major impact. In fact for most of the traffic, max-cache-ttl overwrites the TTL and becomes the de-facto TTL. I think we should elaborate a bit more about has the right TTL value (the root zone or the max-cache-ttl), and see if there are any recommendations to do for the max-cache-ttl value. I also understand it may be out of scope of the root zone TTL, but change of this value probably impact more the root zone traffic than the current TTL. 4) whether you agree with the recommendations in this report I agree with the recommendations. However, I think we should also comment on the max-cache-ttl. As TTL is related to caching, I also think there should be some additional items on how these caches may be flushed by an authoritative party -- I am really thinking of the red button Joe Abley talked about in case of a emergency key-roll over, but it looks this could be useful in other situations. Maybe we should also see some debugging indications when a badly cached value is stored -- again I am mostly thinking of outdated signatures RRsets cached. 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred? I also found I couple of nits in the document. 1) introduction: The document uses the term "Internet Community": I am wondering whether this community is identified enough to named as such or if Internet community would be more appropriated. 2) section 3: Types of data in the DNS Root zone: I think that some clarifications should be made in section 3 regarding the type of data. I found it quite confusing to read that most authoritative data are 1d TTL as most NS have 2d TTLs. This comes from the fact that TLD NS are not part of the authoritative data. I looked at dratf-ietf-dnsop-dns-terminology and checked that whether TLD NS are authoritative data or not is somehow confusing. So I would suggest to explicitly state it. The text I would propose could be something like: "In this section we considered three types of DNS data. - authoritative data : the data the root zone has authority for. In our case, we did not consider the TLD NS nor the TLD Glue RRsets (A, AAAA). - delegation: The definition provided by the terminology section does not fit here as it is not a process. - glue: (cf terminology section) " Another alternative could also consists in clarifying the usage in the terminology section. At last is there any need to have a specific terminology for these authoritative RRsets and have it mentioned in the dns-terminology draft ? 3) section 3 "glue TTLs match their associated NS TTLs" I think we should specify whether this is something observed or if this follows some operational guidance. 4) section 3.1 "which means it has a negative caching TTL of 1 day". I think this may impact the publication of gTLD. as well as emergency key-roll over. 5) section 6.1.1 The graph below shows each TLD’s authoritative NS TTL (y-axis) and its query count in the 2014 DITL data (x-axis). While there are certainly a large number of less-popular TLDs with large RTTs, by looking at the lower right section of the graph we can see that the more-popular TLDs tend to have larger RTTs (Round Trip Times). In other words, there are no popular TLDs with small RTTs. Overall, 90% of queries in 2014 DITL data were to TLDs having NS TTLs greater than or equal to 1 day. I do not see the relation with RTT. Isn't misspelling of TTL? 6) section 6.2 "The authoritative server returns the TXT record without a 10-day TTL." Shouldn't be "with" instead of without? 7) section 6.3 "The study team did find 20% of the IPs made only one request for delegated TLDs during collection . ". Shouldn't it be "data collection period" instead? idem for "Nearly 20% of the IPs made only request for delegated TLDs during collection". 8) Section 6.3 "IPs sending queries (red line) and providing measurements (blue line)." or the legend Queries/Measures in figure 4 does not make obvious the difference between the two lines. Maybe that would be better to clarify that explicitly. 9) section 6.3 "Figure 6 and Table 8 below shows" Shouldn't it be "show" 10) section 6.4.1/ section 7 Findings 4: lots of missing white space after ".". 11) section 6.4.1 Is there any reason the relation between the different Time is not expressed. SOA_Expire + NS_TTL <= ZSK_validity 12) section 6.4.2 "Just before day 10, a root server instance experiences a problem which prevents the it from receiving zone" Shouldn't we remove "the"? 13) Findings 2: "This likely means that root zone TTLs could be reduced to 1 day without any significant impact on traffic levels to root name servers" Is that intentional to repeat the sentence? 14) Findings 6: "In Section 6.4, the study team identifies two situations whereby a root name server would return data and signatures that will be cached beyond the signature validity end time. Specifically, in certain situations: " Do we have any kind of formal proof that there is no other corner cases. 15) section 9: Don't we need DNSSEC mitigation mechanisms to flush cache for example.? On Thu, Jun 11, 2015 at 12:41 PM, Steve Sheng <steve.sheng@icann.org<mailto:steve.sheng@icann.org>> wrote: Dear RSSAC Caucus, This is a reminder for you to review the draft report on TTLs for the root zone. The review is due by close of business 15 June 2015. In particular in your review, it would be great if you could comment on: 1) whether there are any factual errors with the document. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies 3) whether you agree with the findings of the report 4) whether you agree with the recommendations in this report 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred? Also, are there any interest to have a briefing call on this report? Right now, the most likely time would be Monday 15 June. Thanks, Steve From: Steve Sheng <steve.sheng@icann.org<mailto:steve.sheng@icann.org>> Date: Monday, June 8, 2015 at 1:37 PM To: "rssac-caucus@icann.org<mailto:rssac-caucus@icann.org>" <rssac-caucus@icann.org<mailto:rssac-caucus@icann.org>> Subject: [rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs Dear RSSAC Caucus, On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt. Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today’s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review. One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone’s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area. The work party chair requests you provide your review by close of business (anywhere around the world) 15 June 2015, if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires. All the best, Steve _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org<mailto:rssac-caucus@icann.org> https://mm.icann.org/mailman/listinfo/rssac-caucus -- Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160<tel:%2B1%20514-452-2160>
Hi Steve-san, Please check the below comments. Sorry for my late response that I missed the CoB of 15 June in Japan, but I believe it is still okay in other countries. ---------------- 1) whether there are any factual errors with the document. I didn't see the factual errors, but came up with some questions and editorial comments. These should be addressed. - The expressions in the terminology part varies. - reference to the RFCs exists or not - way to refer the RFCs - link to the URL exists or not - Some abbreviation and words are used without enough descriptions. ex) AA, TLD, Root Glue, TLD Glue, NS RRset TTL (whether glue of root(.) itself or TLD delegation?) - In the description of the SOA, nothing is mentioned for the REFRESH and RETRY. These can be described in combination with EXPIRE, as the parameters for the secondary name servers to determine the zone transfer timing. - In the last paragraph of 6.1.1, the word RTT is used to explain the Figure 2. I could not understand this expression because the Figure 2 does not contain any information about RTT. The figure might be wrong. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies I could not find specific problem statement throughout the document. Thus, the motivation of this study is not clear enough. It would be better if we can set up the problem with case examples or specific patterns. 3) whether you agree with the findings of the report no objections. 4) whether you agree with the recommendations in this report no objections. If the issue is logically problematic, it should be fixed. But the other issues which has not been seen as the current operational problem do not need to be actively addressed. The recommendations match this way. 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred? The parameters which is not causing the operational problem directly should not be changed easily. If we shorten the Expire period, there may be negative operational impact in the case of communication trouble between root-zone distributor and root-servers. The parameter of the DNSSEC validity period is the place we can be changed without other impact. ---------------- Just let me know if you have any questions in above comments. Best Regards, Shinta Sato <shinta@jprs.co.jp> Japan Registry Services Co., Ltd. On Thu, 11 Jun 2015 16:41:37 +0000 Steve Sheng <steve.sheng@icann.org> wrote:
Dear RSSAC Caucus,
This is a reminder for you to review the draft report on TTLs for the root zone. The review is due by close of business 15 June 2015.
In particular in your review, it would be great if you could comment on:
1) whether there are any factual errors with the document. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies 3) whether you agree with the findings of the report 4) whether you agree with the recommendations in this report 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
Also, are there any interest to have a briefing call on this report? Right now, the most likely time would be Monday 15 June.
Thanks, Steve
From: Steve Sheng <steve.sheng@icann.org> Date: Monday, June 8, 2015 at 1:37 PM To: "rssac-caucus@icann.org" <rssac-caucus@icann.org> Subject: [rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Dear RSSAC Caucus,
On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt.
Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today1s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review.
One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone1s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area.
The work party chair requests you provide your review by close of business (anywhere around the world) 15 June 2015, if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires.
All the best, Steve
Thanks Shinta! Steve On 6/15/15, 11:06 PM, "Shinta Sato" <shinta@jprs.co.jp> wrote:
Hi Steve-san,
Please check the below comments. Sorry for my late response that I missed the CoB of 15 June in Japan, but I believe it is still okay in other countries.
---------------- 1) whether there are any factual errors with the document.
I didn't see the factual errors, but came up with some questions and editorial comments. These should be addressed.
- The expressions in the terminology part varies. - reference to the RFCs exists or not - way to refer the RFCs - link to the URL exists or not
- Some abbreviation and words are used without enough descriptions. ex) AA, TLD, Root Glue, TLD Glue, NS RRset TTL (whether glue of root(.) itself or TLD delegation?)
- In the description of the SOA, nothing is mentioned for the REFRESH and RETRY. These can be described in combination with EXPIRE, as the parameters for the secondary name servers to determine the zone transfer timing.
- In the last paragraph of 6.1.1, the word RTT is used to explain the Figure 2. I could not understand this expression because the Figure 2 does not contain any information about RTT. The figure might be wrong.
2) whether you agree with the study methodology and the conclusions that are drawn from these studies
I could not find specific problem statement throughout the document. Thus, the motivation of this study is not clear enough. It would be better if we can set up the problem with case examples or specific patterns.
3) whether you agree with the findings of the report
no objections.
4) whether you agree with the recommendations in this report
no objections.
If the issue is logically problematic, it should be fixed. But the other issues which has not been seen as the current operational problem do not need to be actively addressed. The recommendations match this way.
5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
The parameters which is not causing the operational problem directly should not be changed easily. If we shorten the Expire period, there may be negative operational impact in the case of communication trouble between root-zone distributor and root-servers. The parameter of the DNSSEC validity period is the place we can be changed without other impact. ----------------
Just let me know if you have any questions in above comments.
Best Regards,
Shinta Sato <shinta@jprs.co.jp> Japan Registry Services Co., Ltd.
On Thu, 11 Jun 2015 16:41:37 +0000 Steve Sheng <steve.sheng@icann.org> wrote:
Dear RSSAC Caucus,
This is a reminder for you to review the draft report on TTLs for the root zone. The review is due by close of business 15 June 2015.
In particular in your review, it would be great if you could comment on:
1) whether there are any factual errors with the document. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies 3) whether you agree with the findings of the report 4) whether you agree with the recommendations in this report 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
Also, are there any interest to have a briefing call on this report? Right now, the most likely time would be Monday 15 June.
Thanks, Steve
From: Steve Sheng <steve.sheng@icann.org> Date: Monday, June 8, 2015 at 1:37 PM To: "rssac-caucus@icann.org" <rssac-caucus@icann.org> Subject: [rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Dear RSSAC Caucus,
On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt.
Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today1s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review.
One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone1s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area.
The work party chair requests you provide your review by close of business (anywhere around the world) 15 June 2015, if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires.
All the best, Steve
Whooo. Something I don;t think we remembered to mention in the doc -- perhaps we should toss in a mention? http://www.mail-archive.com/bind-users@lists.isc.org/msg21023.html Basically upwards referrals triggering fetches (and cache exhaustion, which we *might* have mentioned). Related to the topic, perhaps worth mentioning just for completeness? W On Tue, Jun 16, 2015 at 11:06 AM, Steve Sheng <steve.sheng@icann.org> wrote:
Thanks Shinta!
Steve
On 6/15/15, 11:06 PM, "Shinta Sato" <shinta@jprs.co.jp> wrote:
Hi Steve-san,
Please check the below comments. Sorry for my late response that I missed the CoB of 15 June in Japan, but I believe it is still okay in other countries.
---------------- 1) whether there are any factual errors with the document.
I didn't see the factual errors, but came up with some questions and editorial comments. These should be addressed.
- The expressions in the terminology part varies. - reference to the RFCs exists or not - way to refer the RFCs - link to the URL exists or not
- Some abbreviation and words are used without enough descriptions. ex) AA, TLD, Root Glue, TLD Glue, NS RRset TTL (whether glue of root(.) itself or TLD delegation?)
- In the description of the SOA, nothing is mentioned for the REFRESH and RETRY. These can be described in combination with EXPIRE, as the parameters for the secondary name servers to determine the zone transfer timing.
- In the last paragraph of 6.1.1, the word RTT is used to explain the Figure 2. I could not understand this expression because the Figure 2 does not contain any information about RTT. The figure might be wrong.
2) whether you agree with the study methodology and the conclusions that are drawn from these studies
I could not find specific problem statement throughout the document. Thus, the motivation of this study is not clear enough. It would be better if we can set up the problem with case examples or specific patterns.
3) whether you agree with the findings of the report
no objections.
4) whether you agree with the recommendations in this report
no objections.
If the issue is logically problematic, it should be fixed. But the other issues which has not been seen as the current operational problem do not need to be actively addressed. The recommendations match this way.
5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
The parameters which is not causing the operational problem directly should not be changed easily. If we shorten the Expire period, there may be negative operational impact in the case of communication trouble between root-zone distributor and root-servers. The parameter of the DNSSEC validity period is the place we can be changed without other impact. ----------------
Just let me know if you have any questions in above comments.
Best Regards,
Shinta Sato <shinta@jprs.co.jp> Japan Registry Services Co., Ltd.
On Thu, 11 Jun 2015 16:41:37 +0000 Steve Sheng <steve.sheng@icann.org> wrote:
Dear RSSAC Caucus,
This is a reminder for you to review the draft report on TTLs for the root zone. The review is due by close of business 15 June 2015.
In particular in your review, it would be great if you could comment on:
1) whether there are any factual errors with the document. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies 3) whether you agree with the findings of the report 4) whether you agree with the recommendations in this report 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
Also, are there any interest to have a briefing call on this report? Right now, the most likely time would be Monday 15 June.
Thanks, Steve
From: Steve Sheng <steve.sheng@icann.org> Date: Monday, June 8, 2015 at 1:37 PM To: "rssac-caucus@icann.org" <rssac-caucus@icann.org> Subject: [rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Dear RSSAC Caucus,
On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt.
Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today1s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review.
One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone1s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area.
The work party chair requests you provide your review by close of business (anywhere around the world) 15 June 2015, if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires.
All the best, Steve
_______________________________________________ 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 having a hard time believing that an upward referral is or should trigger a fetch. It seems like standard cache poisoning protection that the recursive should ignore the out-of-baliwick upward referral. So if we are to include this I think we need confirmation either from a BIND developer or from running our own tests. Do we want to delay the document for that? (my thought while reading that bind-users thread was that maybe the OP's named was repeatedly crashing and restarting). DW
On Jun 17, 2015, at 6:32 AM, Warren Kumari <warren@kumari.net> wrote:
Whooo. Something I don;t think we remembered to mention in the doc -- perhaps we should toss in a mention?
http://www.mail-archive.com/bind-users@lists.isc.org/msg21023.html
Basically upwards referrals triggering fetches (and cache exhaustion, which we *might* have mentioned). Related to the topic, perhaps worth mentioning just for completeness?
W
On Tue, Jun 16, 2015 at 11:06 AM, Steve Sheng <steve.sheng@icann.org> wrote:
Thanks Shinta!
Steve
On 6/15/15, 11:06 PM, "Shinta Sato" <shinta@jprs.co.jp> wrote:
Hi Steve-san,
Please check the below comments. Sorry for my late response that I missed the CoB of 15 June in Japan, but I believe it is still okay in other countries.
---------------- 1) whether there are any factual errors with the document.
I didn't see the factual errors, but came up with some questions and editorial comments. These should be addressed.
- The expressions in the terminology part varies. - reference to the RFCs exists or not - way to refer the RFCs - link to the URL exists or not
- Some abbreviation and words are used without enough descriptions. ex) AA, TLD, Root Glue, TLD Glue, NS RRset TTL (whether glue of root(.) itself or TLD delegation?)
- In the description of the SOA, nothing is mentioned for the REFRESH and RETRY. These can be described in combination with EXPIRE, as the parameters for the secondary name servers to determine the zone transfer timing.
- In the last paragraph of 6.1.1, the word RTT is used to explain the Figure 2. I could not understand this expression because the Figure 2 does not contain any information about RTT. The figure might be wrong.
2) whether you agree with the study methodology and the conclusions that are drawn from these studies
I could not find specific problem statement throughout the document. Thus, the motivation of this study is not clear enough. It would be better if we can set up the problem with case examples or specific patterns.
3) whether you agree with the findings of the report
no objections.
4) whether you agree with the recommendations in this report
no objections.
If the issue is logically problematic, it should be fixed. But the other issues which has not been seen as the current operational problem do not need to be actively addressed. The recommendations match this way.
5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
The parameters which is not causing the operational problem directly should not be changed easily. If we shorten the Expire period, there may be negative operational impact in the case of communication trouble between root-zone distributor and root-servers. The parameter of the DNSSEC validity period is the place we can be changed without other impact. ----------------
Just let me know if you have any questions in above comments.
Best Regards,
Shinta Sato <shinta@jprs.co.jp> Japan Registry Services Co., Ltd.
On Thu, 11 Jun 2015 16:41:37 +0000 Steve Sheng <steve.sheng@icann.org> wrote:
Dear RSSAC Caucus,
This is a reminder for you to review the draft report on TTLs for the root zone. The review is due by close of business 15 June 2015.
In particular in your review, it would be great if you could comment on:
1) whether there are any factual errors with the document. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies 3) whether you agree with the findings of the report 4) whether you agree with the recommendations in this report 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
Also, are there any interest to have a briefing call on this report? Right now, the most likely time would be Monday 15 June.
Thanks, Steve
From: Steve Sheng <steve.sheng@icann.org> Date: Monday, June 8, 2015 at 1:37 PM To: "rssac-caucus@icann.org" <rssac-caucus@icann.org> Subject: [rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Dear RSSAC Caucus,
On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt.
Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today1s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review.
One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone1s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area.
The work party chair requests you provide your review by close of business (anywhere around the world) 15 June 2015, if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires.
All the best, Steve
_______________________________________________ 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 _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
On Thursday, June 18, 2015, Wessels, Duane <dwessels@verisign.com> wrote:
I'm having a hard time believing that an upward referral is or should trigger a fetch. It seems like standard cache poisoning protection that the recursive should ignore the out-of-baliwick upward referral.
So if we are to include this I think we need confirmation either from a BIND developer or from running our own tests. Do we want to delay the document for that?
Nah, not worth delaying for this... And I'd thought it was a BIND person who replied to the thread with that info, but we'd need a better understanding before putting it in the doc. I think upwards referrals do trigger a fetch at the parent, but don't know all the details/ circumstances... W
(my thought while reading that bind-users thread was that maybe the OP's named was repeatedly crashing and restarting).
DW
On Jun 17, 2015, at 6:32 AM, Warren Kumari <warren@kumari.net <javascript:;>> wrote:
Whooo. Something I don;t think we remembered to mention in the doc -- perhaps we should toss in a mention?
http://www.mail-archive.com/bind-users@lists.isc.org/msg21023.html
Basically upwards referrals triggering fetches (and cache exhaustion, which we *might* have mentioned). Related to the topic, perhaps worth mentioning just for completeness?
W
On Tue, Jun 16, 2015 at 11:06 AM, Steve Sheng <steve.sheng@icann.org <javascript:;>> wrote:
Thanks Shinta!
Steve
On 6/15/15, 11:06 PM, "Shinta Sato" <shinta@jprs.co.jp <javascript:;>> wrote:
Hi Steve-san,
Please check the below comments. Sorry for my late response that I missed the CoB of 15 June in Japan, but I believe it is still okay in other countries.
---------------- 1) whether there are any factual errors with the document.
I didn't see the factual errors, but came up with some questions and editorial comments. These should be addressed.
- The expressions in the terminology part varies. - reference to the RFCs exists or not - way to refer the RFCs - link to the URL exists or not
- Some abbreviation and words are used without enough descriptions. ex) AA, TLD, Root Glue, TLD Glue, NS RRset TTL (whether glue of root(.) itself or TLD delegation?)
- In the description of the SOA, nothing is mentioned for the REFRESH and RETRY. These can be described in combination with EXPIRE, as the parameters for the secondary name servers to determine the zone transfer timing.
- In the last paragraph of 6.1.1, the word RTT is used to explain the Figure 2. I could not understand this expression because the Figure 2 does not contain any information about RTT. The figure might be wrong.
2) whether you agree with the study methodology and the conclusions that are drawn from these studies
I could not find specific problem statement throughout the document. Thus, the motivation of this study is not clear enough. It would be better if we can set up the problem with case examples or specific patterns.
3) whether you agree with the findings of the report
no objections.
4) whether you agree with the recommendations in this report
no objections.
If the issue is logically problematic, it should be fixed. But the other issues which has not been seen as the current operational problem do not need to be actively addressed. The recommendations match this way.
5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
The parameters which is not causing the operational problem directly should not be changed easily. If we shorten the Expire period, there may be negative operational impact in the case of communication trouble between root-zone distributor and root-servers. The parameter of the DNSSEC validity period is the place we can be changed without other impact. ----------------
Just let me know if you have any questions in above comments.
Best Regards,
Shinta Sato <shinta@jprs.co.jp <javascript:;>> Japan Registry Services Co., Ltd.
On Thu, 11 Jun 2015 16:41:37 +0000 Steve Sheng <steve.sheng@icann.org <javascript:;>> wrote:
Dear RSSAC Caucus,
This is a reminder for you to review the draft report on TTLs for the root zone. The review is due by close of business 15 June 2015.
In particular in your review, it would be great if you could comment on:
1) whether there are any factual errors with the document. 2) whether you agree with the study methodology and the conclusions that are drawn from these studies 3) whether you agree with the findings of the report 4) whether you agree with the recommendations in this report 5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?
Also, are there any interest to have a briefing call on this report? Right now, the most likely time would be Monday 15 June.
Thanks, Steve
From: Steve Sheng <steve.sheng@icann.org <javascript:;>> Date: Monday, June 8, 2015 at 1:37 PM To: "rssac-caucus@icann.org <javascript:;>" <rssac-caucus@icann.org <javascript:;>> Subject: [rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Dear RSSAC Caucus,
On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt.
Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today1s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review.
One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone1s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area.
The work party chair requests you provide your review by close of business (anywhere around the world) 15 June 2015, if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires.
All the best, Steve
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <javascript:;> 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 _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org <javascript:;> 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
participants (5)
-
Daniel Migault -
Shinta Sato -
Steve Sheng -
Warren Kumari -
Wessels, Duane