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