On Fri, Jul 5, 2019 at 12:27 AM Warren Kumari <[email protected]> wrote:
> On Thu, Jul 4, 2019 at 12:12 PM Dave Lawrence <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/dnsop It depends on how it was "taken down". I thought a proper take-down was to change or remove the NS records from the parent zone. Then we would get an authoritative NXDOMAIN and not a lame response. In that case, a lame response should still serve stale. -- Bob Harold
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
