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

[Stephen Morris]

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