[bind10-dev] NSAS Using Authority/Additional Information?

[Jerry Scharf]

Michal,

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.

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.

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.

jerry

On 11/26/2010 11:08 AM, Michal 'vorner' Vaner wrote:
> 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:
>> 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.
> Yes, that is more or less what happens.
>
>> 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.)
> 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
>
>
>
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101126/f1a826a2/attachment.html>