[rssac-caucus] REMINDER - FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Daniel Migault
mglt.biz at gmail.com
Mon Jun 15 12:57:14 UTC 2015
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 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 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20150615/5160d3d6/attachment.html>
More information about the rssac-caucus
mailing list