[dns-operations] sophosxl.net problem?

[Mark Andrews]

> On 12 Nov 2019, at 06:57, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
>> On Nov 11, 2019, at 2:36 PM, Dave Lawrence <tale at dd.org> wrote:
>> 
>> In the last, AA=0 is a clear standards-noncompliant signalling failure
>> for which it is entirely appropriate to treat the responder as lame.
>> (OTOH, if the data can be DNSSEC-validated, hey then whatever, AA was
>> just redundant -- the data was authoritative even if the responder wasn't.)
> 
> But if the responder is authoritative only for a parent of the requested
> domain, and is willing to do recursion for the child zone, and has the
> answer cached, then if it also serves data from the cache with RD=0, it
> will return AA=0 for the cached data, while the requestor believes the
> server to be authoritative (for at least the top of the subtree).
> 
> And that's the situation in the PowerDNS issue, and it is not clear to
> me that response violates any standards.
> 
> We can't have both of:
> 
>   * It is valid to return non-authoritative cached data for RD=0
>   * It is invalid to return AA=0 in response to RD=0 requests.
> 
> Which shall it be? You say you find the first useful, but then you
> really can't have the second, the responser isn't necessarily lame
> if the qname is not the zone apex.

This is a corner case for which there is no explicit signalling in the
query.  There is decades old advice not to be configured as a recursive
server if you are listed as authoritative for a zone (been delegated to)
because it creates such corner cases.

If we want to solve this one needs to add more signalling.  Using AA=1 in the
QUERY to signal that you don’t want to see answers from the cache would be a
logical way to do this and would allow the client to say what it wants from the
server.  One should, in theory, be able to send AA=1 in queries today without
causing problems as it is supposed to be ignored.  The question then becomes
when do you stop inferring no cache access from RD=0, AA=0 queries when you
are willing to recurse for the client.

Mark

> -- 
> 	Viktor.
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org