On 6 Mar 2019, at 08:03, Tony Finch <d...@dotat.at> wrote: > Dave Lawrence <t...@dd.org> wrote: > >> REFUSED is slightly murkier as to its exact meaning, thanks to >> overloading, but in its most commonly seen usage for lameness >> indicates a clear problem with the delegation. Even in its other use >> cases, notably an EDNS Client Subnet error or an actual "I am >> authoritative for the name but administratively denying your >> resolution of it", I submit that if the resolver has a stale answer >> then serving it is reasonable. > > This sounds like it will lead to stale answers being given instead of > re-trying other potentially working servers. I think this is wrong, and > it's inconsistent with your other reply, so I am confused. > > https://mailarchive.ietf.org/arch/msg/dnsop/HIUK2ME8uHbA-cwztnrNVYRtqLc > > I think serve-stale should only cover cases where servers are unreachable > or unresponsive.
That phrase sounds concise and definitive, but it's not really. How recently should a server have been checked and found not to respond to conclude that it's unresponsive? What does unresponsive mean? Presumably this involves a timeout; how long? Perhaps these questions are already answered in practice by existing implementations, but I don't know that they are written down anywhere. If a server responds to some queries but not others (e.g. same QNAME, different QTYPEs) is that unresponsive across the board? Or does responsiveness depend on the precise (QNAME, QCLASS, QTYPE) tuple? This is not only a pedantic, annoying observation (you're welcome) but I think the last question provides an attack vector; if you can find a set of DNS authority servers that silently discards a particular kind of query, sending such queries through resolvers that are known to support serve-stale might suppress other queries and trigger the serve-stale behaviour even though the authority servers are not actually unresponsive for them. I think it's a fair observation that such authoritative servers are broken, but I seem to think they exist e.g. due to the ongoing existence of poorly-conceived middleboxes. If I'm mistaken about that last part then I guess we're back to pedantic and annoying. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
