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. If all a zone's servers start to reply REFUSED, that's a deliberate decision to disable the zone, and resolvers should not try to keep it alive beyond its TTL. (This is important for the take-down situations that Paul Vixie is concerned about.) I'm more ambivalent about the SERVFAIL case but it seems simpler to treat it the same as REFUSED, i.e. server is working but not for this zone. There's a big difference between the RFC 4697 (Observed DNS Resolution Misbehavior) section 2.2 (Repeated Queries to Lame Servers) lame server cache time of 30 minutes and the serve-stale retry time of 30 seconds, which makes me think the serve-stale spec should explicitly update RFC 4697. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ Lyme Regis to Lands End including the Isles of Scilly: South, veering west or northwest 5 to 7, occasionally gale 8 later. Moderate or rough, becoming very rough for a time in far west. Thundery showers. Good, occasionally poor. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
