Subject: [DNSOP] draft-ietf-dnsop-serve-stale: returning stale answers when faced with SERVFAIL responses

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Jul 2019 23:07:03 +0000

Greetings again. Section 6 says:

   The directive in Section 4 that only NoError and NXDomain responses
   should invalidate any previously associated answer stems from the
   fact that no other RCODEs which a resolver normally encounters makes
   any assertions regarding the name in the question or any data
   associated with it.  This comports with existing resolver behavior
   where a failed lookup (say, during pre-fetching) doesn't impact the
   existing cache state.  Some authoritative servers operators have said
   that they would prefer stale answers to be used in the event that
   their servers are responding with errors like ServFail instead of
   giving true authoritative answers.  Implementers MAY decide to return
   stale answers in this situation.

This last sentence feels wrong to me, as does the desire of "some authoritative servers operators". As the rest of the document explains, stale answers are meant to be served when authoritative servers cannot be reached, not whey they are reachable but giving funny answers. I propose that the last sentence be changed to:

   However, implementations MUST NOT send stale data if they have received
   any answer from an authoritative server.

--Paul Hoffman

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 4 Jul 2019 15:12:28 -0400

>    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.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 4 Jul 2019 21:26:58 -0700

> 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-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 5 Jul 2019 15:41:29 +0000

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 <[email-masked]> wrote:
>

---

From: Bob Harold <[email-masked]>
Date: Wed, 10 Jul 2019 15:53:04 -0400

> infer what to do, but SERVFAIL is overloaded...

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