IETF Logo Mail Archive

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

Bob Harold <rharolde@umich.edu> Wed, 10 July 2019 19:53 UTC

Return-Path: <rharolde@umich.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C11120043 for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2019 12:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level:
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRe3XAQi6YhO for <dnsop@ietfa.amsl.com>; Wed, 10 Jul 2019 12:53:18 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7FDC12004A for <dnsop@ietf.org>; Wed, 10 Jul 2019 12:53:17 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id m8so3305444lji.7 for <dnsop@ietf.org>; Wed, 10 Jul 2019 12:53:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6CZugKuJxP7gaEl6dhsxlukPO5x7l0CkAPdTZ3yqqWY=; b=qotaAhVpkDQEGfXi4Lakjr7F2+ejCwmZ5ScDLVSsf7+ds3zNvgIPYVzbvFqNp2B6nN eV5K9CjaGlo7Ybggtf4vCt03SdrzGWt6W/nqoDWFh1vv9/jxaQcSeaNwbR3eYhY/z8Pj 84eDfxjJVaVm7w9HcrQEHCNB4NW5G8shbXw0olKIh1WG6WpC2lb7Nk/36V4m6+GLFSPd AINSPMmB22heq3pbToTsUcqM4sRGbhm2u402Vht2bIrnqAOfAS70TIBlYbCwXCO3BJPm SIfLffgoFIs8FIxBVoyfOpslRTlg7mj3khGA84ZPcivBJVIyDpWuyFnEgi//fSBMJcA1 ArWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6CZugKuJxP7gaEl6dhsxlukPO5x7l0CkAPdTZ3yqqWY=; b=iWuyzIFu+MRUxT/v8W9lFItJBt5HNnjsF0ndjySRKqJIDtPSUbzBKlQpg8bN63vKaI 1bUK2sigdUXVtoRvacAGlRrY3CgzgQJ/h6+HyH/gNrev+aRWTp3q+KZUPMJYJC5lLQuF Sn6+T6069Y/ABHq05SOXUfGfQTsFW0HeoSQLf4OYpIn2d4vsF5NHWSOb3m5eiJAkwBE0 p7dAcbhV+o7945Ky9lnOWiiK7Y96RX/vs7is/irNQheReXpU6bg76LPl8i1EMuw9tqYz eei/5uTNczWwgHsvnWEYpPEPIrSCmzoS1Utxg8zRXhSpN1eY1m3GpqUxbTRhTIu0NycF Pqpg==
X-Gm-Message-State: APjAAAWKCP3yJQZG2wEi+V6oWVCzE1naz6FTR+BupM1UDJQej16XlT1p bM6lJDKwtFACG3ncN44e5dsN9z4iGpb44WWao3Dg/akl
X-Google-Smtp-Source: APXvYqzNtNYr8RAoHP7s7EwWk6aCSdk0h+AqPRDgP0YGCBppAEOdRaqTW6eFkAL8GWahUZOaQ7SceDBqoHl+UfRDON8=
X-Received: by 2002:a2e:5d1:: with SMTP id 200mr15304ljf.10.1562788395583; Wed, 10 Jul 2019 12:53:15 -0700 (PDT)
MIME-Version: 1.0
References: <F3EF6B22-43E2-4581-B836-5C7A39F88E46@icann.org> <23838.20380.277572.704690@gro.dd.org> <CAHw9_iJDvvY_SF=KahpyrJ-zdLk4GAfRdwL8sRKrina=1Wuw8Q@mail.gmail.com>
In-Reply-To: <CAHw9_iJDvvY_SF=KahpyrJ-zdLk4GAfRdwL8sRKrina=1Wuw8Q@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
Date: Wed, 10 Jul 2019 15:53:04 -0400
Message-ID: <CA+nkc8DRXJm_zzXeusbLOAZ3NX0WVpT8jHbz6fSEKrs3gLMm=g@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: Dave Lawrence <tale@dd.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002d9798058d5907f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dFk7Mc1K_yNmEXgsmsyXKCEs95s>
Subject: Re: [DNSOP] draft-ietf-dnsop-serve-stale: returning stale answers when faced with SERVFAIL responses
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 19:53:21 -0000

On Fri, Jul 5, 2019 at 12:27 AM Warren Kumari <warren@kumari.net> wrote:

> On Thu, Jul 4, 2019 at 12:12 PM Dave Lawrence <tale@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


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

v2.23.0 | Report a Bug | By Email