Got it. Given that, the current wording is reasonable, so I withdraw my request.
--Paul Hoffman > On Jul 4, 2019, at 9:26 PM, Warren Kumari <war...@kumari.net> wrote: > > On Thu, Jul 4, 2019 at 12:12 PM Dave Lawrence <t...@dd.org> wrote: >> >> Paul Hoffman writes: >>> However, implementations MUST NOT send stale data if they have received >>> any answer from an authoritative server. >> >> I personally strongly disagree with this. >> >> ServFail is a signal from the authoritative operator that something is >> amiss, and is in practical terms is not really distinguishable from >> being unable to reach them. It's not just a "funny answer". If the >> resolver was previously able to get good answers for the same query >> but is now getting the server declaring things are whack, I don't see >> how passing through the ServFail helps anything, and it harms the >> intended resiliency of this whole endeavour. > > I believe that we ended up here because we wanted to make sure that we > support the takedown ability, and some servers return SERVFAIL when > lame. They should probably be returning REFUSED (or something, see > draft-sullivan-dnsop-refer-down for options :-)), but, well, we live > in an imperfect world... > > As an example: > dig +norec thisisalamename.info @a2.verisigndns.com. > > ; <<>> DiG 9.12.4-P1 <<>> +norec thisisalamename.info @a2.verisigndns.com. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2377 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > [SNIP] > > If you were getting answers from a2.verisigndns.com for > im-an-evil-jerk.net, and it gets taken down and you are now getting > SERVFAIL, you cannot differentiate between "someone messed up" and > "this domain was removed from the server". If we had way more info in > the response (cough extended-error cough) we could differentiate and > infer what to do, but SERVFAIL is overloaded... _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
