Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

Ted Lemon <mellon@fugue.com> Wed, 01 December 2021 01:05 UTC

Return-Path: <mellon@fugue.com>
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 259E83A07BE for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 17:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
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 bu_VmBO1HrQR for <dnsop@ietfa.amsl.com>; Tue, 30 Nov 2021 17:05:03 -0800 (PST)
Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 4B0543A07C1 for <dnsop@ietf.org>; Tue, 30 Nov 2021 17:05:02 -0800 (PST)
Received: by mail-oi1-x234.google.com with SMTP id bj13so45002285oib.4 for <dnsop@ietf.org>; Tue, 30 Nov 2021 17:05:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vEc5UEZDYoqsojynnJH47pYbBAvEB/AP6G35Mx318w0=; b=6Fg2rc55Mk7Scc2dUJNN7zttb6/7L7Bn7eTUud9OMJBTKjQgg/fwDUQ3/fPpberI96 RGm9u0AFDH39SefH78bgjWcjj/Wf/oiF4WyQMj137Dr2R815aeRn9JWA27GNtYmldt4/ jiEMgq+/LZy+vbzfflbC7XgzqLwxv5V4VevQM8I0YPzQS32tMXNz4+vjZgD0BPWvitNN lrLHe5LLOeZqA8nCwtcXxlDRvAHkcHRnKmYVDZkg/dBTvhalIA45wb1JAxfZMstkZKC4 AKTZcY55/zXkt1oo9mLz6oCeYTuEecZgV6oqkgEqBFfxrluh1k5hqpGCf79neCn+qUem F6pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vEc5UEZDYoqsojynnJH47pYbBAvEB/AP6G35Mx318w0=; b=FCVIDl6h8gVxKcN4zPYF3hB6tI7x29xJbPnYQuldbap8bSHnR2YU0pvUdBNnDnX0Ey UsgM16zs8v6qqdfIdTHIvVVhcgv66brGEtK5RD7ZggYEvj9mi6HaiRpUFUlS/Jnru+SZ LSrAYiGhFmlGQI7N8maBOYi27BgdQIyDvMcjC1xhT3RJsJZ94SlL62EOhDJ+ifPb8r/k DgfpYxVzULIBikXOGb0sXv/qxBUq+mEf4LZVRTYP4CXGz3gtIOlH4ZSFSdDPT5Xn0Tad zNUMNyfRG8KDY3N0HBwcM4ftlzYw2W8Xz9fHKRziRM0kubJqcamVQGAMbgyAUJnpQ7IF +hZQ==
X-Gm-Message-State: AOAM5327n1EV/B9VJV7BjbVUb1/7NIyKnftZvrRV5ChQHXN9FnCaqPv4 F34ZFJN6uv5Opo7aFM3txijyBWD9OCKj4qmafwSgjQ==
X-Google-Smtp-Source: ABdhPJzAHpyrrvzw0AlFG+4pE/UXt2NcfHnTJ8ua1aXdBiEcOJTknNYAcdlL+iFq+PbBn1eJJHL30kl8iVx3l+svi3U=
X-Received: by 2002:aca:ac8e:: with SMTP id v136mr2848785oie.19.1638320700908; Tue, 30 Nov 2021 17:05:00 -0800 (PST)
MIME-Version: 1.0
References: <20211129190711.E4E9B36417@rfc-editor.org> <19c96ba9-a582-a24-b73-8e86a08c7b68@nohats.ca> <794d45f4b9093a019b94aee4730161d358b5ba79.camel@powerdns.com> <198228F8-F970-47E3-8690-5B13FB324231@hopcount.ca> <d3957532-33e8-f79f-a94f-8775948c886b@iecc.com> <28d5129a-b543-7d65-6d91-c87b421bbe1c@nic.cz> <d666dd21-10b2-c8d2-16b8-c5c723712613@redbarn.org> <9dacfae6-0dca-8687-466a-6ce20b7d9e88@nic.cz>
In-Reply-To: <9dacfae6-0dca-8687-466a-6ce20b7d9e88@nic.cz>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 30 Nov 2021 19:04:50 -0600
Message-ID: <CAPt1N1nei=QUcXji9XqD5q75XQnNYkn5ZEWMoJs6k_OahdOSUA@mail.gmail.com>
To: "libor.peltan" <libor.peltan@nic.cz>
Cc: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>, dnsop@ietf.org
Content-Type: multipart/alternative; boundary="00000000000067fedc05d20b4379"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dXX2IVdxlBuxmT8TjfrgeryJMf0>
Subject: Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
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, 01 Dec 2021 01:05:08 -0000

I don’t see how any answer from an authoritative server other than REFUSED
really makes sense for a domain for which that server is not authoritative.
It hasn’t failed. It’s been asked a bogus question. It doesn’t make sense
for it to theorize that it might be misconfigured.

On Tue, Nov 30, 2021 at 15:06 libor.peltan <libor.peltan@nic.cz> wrote:

> Hi Paul,
> >
> > for any non-root server, an RD=0 question for example.onion should be
> > answered with SERVFAIL. this is a condition signal, and the condition
> > is "since i'm hearing this query, someone thinks i'm holding a
> > delegation, and i'm not, so i might be lame for some zone, so the
> > server (me, this authority server) has failed."
> >
> from what I've observed so far, there seem to be a consensus among the
> authoritative servers out there :) They all answer out-of-bailiwick
> queries with REFUSED. I haven't met any that would say SERVFAIL or
> NOTAUTH or anything else. If you propose to normatively change this,
> with the idea that it would make more sense, then OK, but dunno if it
> has any benefit.
>
> $ kdig @d.in-addr-servers.arpa. nonexistent-tld. +nordflag +noall +header
> ;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 2834
> ;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
> $ kdig @a.ns.nic.cz. nonexistent-tld. +nordflag +noall +header
> ;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 63681
> ;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
> $ kdig @a0.org.afilias-nst.info. nonexistent-tld. +nordflag +noall +header
> ;; ->>HEADER<<- opcode: QUERY; status: REFUSED; id: 45946
> ;; Flags: qr; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0
>
> If you propose that onion. TLD (non-existing) and its subtree shall be
> an exception (for very all auth servers) and answered differently than
> other non-existent TLDs, then OK, but I simply don't like the idea.
>
> Libor
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>