[rssac-caucus] REMINDER - FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Wessels, Duane
dwessels at verisign.com
Thu Jun 18 15:19:08 UTC 2015
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 at 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 at icann.org> wrote:
>> Thanks Shinta!
>>
>> Steve
>>
>> On 6/15/15, 11:06 PM, "Shinta Sato" <shinta at 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 at jprs.co.jp>
>>> Japan Registry Services Co., Ltd.
>>>
>>> On Thu, 11 Jun 2015 16:41:37 +0000
>>> Steve Sheng <steve.sheng at 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 at icann.org>
>>>> Date: Monday, June 8, 2015 at 1:37 PM
>>>> To: "rssac-caucus at icann.org" <rssac-caucus at 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 at 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 at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4676 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20150618/e3785139/smime.p7s>
More information about the rssac-caucus
mailing list