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

[Jerry Scharf]

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.

The updating of TTLs from data in the additional section of a query is a 
function of the recursive cache and has no direct bearing on the NSAS. 
When the set of NS rrset for a zone is received, logically the set of 
nameserver IPs for the zone is sent to the NSAS to check if the IP set 
needs updating. If the TTLs of the NS records expire and a new set if 
fetched, the NSAS is unchanged as long as the list of IPs for the zone 
is unchanged. Same is true for a set of NS RRs in the additional 
section. All the NSAS cares about is which IPs are current for each zone.

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.)

jerry

On 11/26/2010 4:51 AM, Stephen Morris wrote:
> Michal Vorner asked in the Jabber room:
>
>> I was interested, will NSAS use authority and additional sections of normal queries?
>> Like if I ask for A record, it gives me authority section for the zone, with full TTL,
>> so I could increase it for example. Is it allowed by RFC? How about data in additional?
>> Do we want something like that in future?
> … to which I replied:
>
>> You can't increase the TTL.  The TTL puts an absolute limit on how long the information is
>> valid.  Once this time has passed, the information must be fetched anew.
> I should have added that if you already have the A record stored, you can use the received TTL to update its validity period so that the record expires at (now + TTL).  But you should not use a higher value than the received TTL.  (There is nothing that prevents you using a lower value though.)
>
> The question of using the information in the authority/additional sections requires a longer answer, which is why I've sent it to the list rather than reply in the Jabber room.  In summary I don't think that the NSAS ought to use it directly in the query answering logic, but it should take account of it.
>
> To expand:
>
> Suppose a query comes in for www.example.com, but that the resolver has not seen a request for anything in the example.com zone before.  A query will be sent to a .com nameserver and the referral received in reply will contain the nameservers for example.com together with possible glue information.  The resolver passes this information to the NSAS together with its request for an address of a nameserver for example.com. (In this discussion I refer to "resolver" as meaning everything in the resolver apart from the NSAS.)
>
> The NSAS should create the entry for zone using information for any nameservers it already knows about.  For any nameservers it does not know about it should request the main resolver code to get the A records.  Even if glue information is present in the referral, the NSAS should ignore it and request information from the resolver.
>
> The reasoning here is that the information may already known to the resolver although not to the NSAS: the address of the nameserver may have been fetched in response to an explicit query (and this authoritative information is to be preferred over a glue hint).  If this is not the case, then for nameservers with no glue information, the request will lead to the resolver issuing a fetch for the information.  If glue information was present in the referral and the resolver has no other information, the resolver will pass back the glue.  (This has the implication that the resolver should process and cache information in authority/additional sections in a query response before making a request to the NSAS.)  Putting this processing in the main resolver code will allow the resolver to handle issues about the precedence of authoritative information over glue information.  It will also remove any questions about DNSSEC validation of addresses from the NSAS.
>
> Concerning authority/additional information, the information in a referral comes from the parent zone and is only a hint - the authoritative data about which nameservers serve a zone come from the zone itself.  So it is entirely possible that a misconfiguration in the parent zone includes a nameserver which is not authoritative for the zone or may include incorrect glue information.  For this reason, when the resolver receives authority/additional information in response to a query, it should pass it to the NSAS;  the NSAS should inspect its information for the zone and update it if necessary.  However, I see this as being a separate function within the NSAS instead of being done as part of the query processing.
>
>
> Stephen
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev