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

[Michal 'vorner' Vaner]

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

-- 
In the name of kernel, compiler and holy penguin

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101126/41e1fed7/attachment.bin>