Hi Matthijs
On Tue, Jul 04, 2017 at 09:30:55AM +0200, Matthijs Mekking wrote:
> Hi,
>
> I already said this in private, but will also mention it here: I like
> this idea.
>
> Some initial comments:
>
>
> 1. Why actually define a new option for this. Since the option only uses
> one bit to request/acknowledge opportunistic refresh, can't we use one
> bit from the Z field from the OPT Record TTL Field?
>
>
> 2. The draft says:
>
> If Client Subnet [RFC7871] is enabled, resource records in the
> cache may be associated with a subnet. In these cases, the
> resolver MUST ensure that the zone serial number associated with
> such records is obtained from an SOA record associated with the
> identical subnet.
>
> But a SOA record is not associated with a subnet, and most likely will
> return with a SCOPE of 0 since the option is not actually used to
> generate the response. Typically with Client Subnet only address records
> (A, AAAA) will result in a tailored response. Also, an authoritative
> name server may generate a different response for QTYPE=AAAA while the
> SOA record has not changed.
>
> It would be tricky to make opportunistic refresh work with Client
> Subnet. It would definitely require more thought, but I would also be
> fine with just specifying it does not work with ECS.
You're right that ECS makes things a bit tricky.
RFC7871 doesn't say anything about caching SOA, only that the address
prefix in the CLIENT-SUBNET option applies to just things that are
returned in the answer section. SOA can be returned in the answer
section when querying for type SOA.
The SOA serial field is so far only assumed to be defined for zone
transfers, and currently has no use with QUERY. Zone transfers with
address prefixed RRs are not specified by RFC7871.
BIND's resolver ECS does not cache SOA against an address prefix, but on
the authoritative side, note that there is no master file or zone
representation for zones with ECS. It is quite possible that if the auth
side is using different zone sources for different address prefixes,
they may well have different SOA serials. The problem is that none of
these is defined.
What the draft suggests is that on the resolver side, the SOA serial is
maintained for that scope subnet corresponding to the answer. With this,
it will handle cases when there are per-prefix zone sources with
differing SOA serials, albeit at a slight reduction in efficiency of
this scheme because all address prefixes cannot be refreshed at once.
In your example, the QTYPE=AAAA answer will be cached against its
specific scope prefix, and when looking for whether it needs to be
refreshed, the resolver will go looking for the SOA serial associated
with that prefix.
Mukund
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
