<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Michal,<br>
<br>
I don't think you want to keep the TTL in the NSAS. The NSAS has
zones and IP addresses. The TTLs are on NS rrs and A/AAAA rrs, which
are not the same. This was part of the knot that Stephen got into
when he started on this.<br>
<br>
Other than resource limits, there is really no reason to remove
anything from the NSAS. If a NS records for a zone expire, you can't
delete the IP and its rtt because that may be shared with other
zones. You could delete the zone and wait for the next query to
rebuild it, but why bother unless there are resource limits. If the
A/AAAA expires for a nameserver in a zone, you could kill it, but
the odds are that you would just end up rebuilding it and you would
lose the rtt information in the process.<br>
<br>
It seems to me like that you do some sort of simple LRU for all the
zones and IPs for resource management. The IP LRU needs to be
updates if the ttl is examined, not just if it was selected.<br>
<br>
jerry<br>
<br>
On 11/26/2010 11:08 AM, Michal 'vorner' Vaner wrote:
<blockquote cite="mid:20101126190841.GA27071@hydra" type="cite">
<pre wrap="">Hello
Damn, again, I need to learn to send to the list as well. Sorry.
On Fri, Nov 26, 2010 at 10:49:28AM -0800, Jerry Scharf wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Am I missing something? I thought the NSAS was independent of RR TTLs.
This is how I think it works.
When you need to answer a query for a zone, NSAS and its associated
algorithms select which nameserver to use. Each query generated by the
resolver gets the IP set for the zone and then uses that set in the
selection process in some way depending on the rtt times in the NSAS.
</pre>
</blockquote>
<pre wrap="">
Yes, that is more or less what happens.
</pre>
<blockquote type="cite">
<pre wrap="">One important thing is that you only go through the NSAS server check if
the NS rrset or the associated A/AAAA rrsets have changed. Since the
cache has to decide whether to add/replace cached rrsets vs. updating
the TTL only, having that drive the NSAS update will make a difference
in heavily loaded recursive servers. (Having rare NS changes and short
A/AAAA TTLs for zone entries is extremely common, making this a
significant optimization.)
</pre>
</blockquote>
<pre wrap="">
That is what we got to on the chat later on as well, that update of the TTL in
NSAS is useless when the data is in the cache, because when the data in NSAS
expires (we need to know when this happens, we shouldn't use too old data), we
can just pick it out of the cache, which is cheap. I asked about this because I
didn't really think about the cache at the time and throwing away data too soon
seemed wasteful. You know, this is the first DNS server I work on, so I do not
have the overview others have ;-).
However, we keep TTL in the NSAS as well, to know when we need to
rebuild/recheck the list of nameservers and IP addresses. I think we could make
the cache even more clever and tell NSAS not just about data changes, but about
time when item in cache expires. But it might be more complicated (we might
want to use the same lazy approach in the cache, throw data out because of TTL
when we discover it, not time it out explicitly).
Thanks a lot
Have a nice day
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
bind10-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind10-dev@lists.isc.org">bind10-dev@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind10-dev">https://lists.isc.org/mailman/listinfo/bind10-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>