Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

Warren Kumari <warren@kumari.net> Wed, 10 January 2018 20:31 UTC

Return-Path: <warren@kumari.net>
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 87A251289B0 for <dnsop@ietfa.amsl.com>; Wed, 10 Jan 2018 12:31:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.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 RSkgn9nAjAxQ for <dnsop@ietfa.amsl.com>; Wed, 10 Jan 2018 12:31:32 -0800 (PST)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 8776612711B for <dnsop@ietf.org>; Wed, 10 Jan 2018 12:31:31 -0800 (PST)
Received: by mail-wr0-x235.google.com with SMTP id 100so246978wrb.7 for <dnsop@ietf.org>; Wed, 10 Jan 2018 12:31:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VGrwk1HuVRAHvv5RkdhmdLb5g2PtcKFLS520vkkdjZg=; b=cB1vzrQat6eNALX2JefUzPTPiUulCuN+8nWtD8/WFfOZYZAEeMNsxVDeWyDuTtUp0a 1QZ6F7AXlRF+vD4TJLlDo+kLLtGbBytXZ0Rb7Hz12iU6lq+dmQUmGVLt+//uvH1ZOxO5 mVaS2f1s+fxG4ABvCH7+F7fJhMTExMeU4TxoTYZYYgyztP/Ol1tj9itYlu97ueDBeM/d JT/+C8mQmsftXxE9i1TGaSiK034OHp2NR/Igww7SXqVhJ+ZmzT0ldTownvBr5Q+3R/lf 26rGP7hzUqF/UutwUiPOR1Ng8FrZ3XbivNyIAY58VgdZBDIMtSe/ltR3TaI3/qWOFx7B fwXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VGrwk1HuVRAHvv5RkdhmdLb5g2PtcKFLS520vkkdjZg=; b=uh/r+2gKkL3WM2Iun0wFhpeME8QVjcXe7IprwKB6ufHM3LiLg8B+8TXV3r5xsd58AA beYpq/MMTt22J/92N+rFZo0X2/APsgRkn+quOhqdDjAg1PsqEmXDSrI1oQ4OH+rLnnGQ JLXenRg3SPV1uMnZW5+OsLC+GU/Hho0G0HIs50LmVfZzjHZ5Botc3eGb094I7Lp+HhE/ c1RQtyHLwIG4lhEILj8COTIuxqBakZqzJuFLldj7le4l91TXiSUiyIzOGZRbgoeqMbnX tP9lTEWcB+dhp0a/k4hUEdF/BB0canoQLBEvaeM0BbpIdAoRCm4VZGQEYWDnuYnTvzCi DN8Q==
X-Gm-Message-State: AKGB3mIlynBjU77UFdMGG/MzPhoz0ikXReowhReyf/7Ar5nOP2xB8ijo WphLFsa0I9WbbPL8b8raSbeWuh5XiE8+w0NmJZGALtpq4Ik=
X-Google-Smtp-Source: ACJfBotVAsFIFd2qm4nv5eLfBuZnwhk8hvMD5QpZWGKjKp5+HL2MvYoDnnDZq0bMNFB4AFwZwpDl7MPizifmUHobusk=
X-Received: by 10.223.197.137 with SMTP id m9mr16797766wrg.140.1515616289739; Wed, 10 Jan 2018 12:31:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.128.165 with HTTP; Wed, 10 Jan 2018 12:30:49 -0800 (PST)
In-Reply-To: <E361FA78-84DF-4B42-AFAC-C8C6CC140158@powerdns.com>
References: <E361FA78-84DF-4B42-AFAC-C8C6CC140158@powerdns.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 10 Jan 2018 15:30:49 -0500
Message-ID: <CAHw9_iL7cOEYPk6KDQRn0UA=Q+A6q7ZP8BtwceE8L4xr2BoMJw@mail.gmail.com>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qDKL7_3XiZdqEjRx0JfybHpFdhc>
Subject: Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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 Jan 2018 20:31:34 -0000

On Wed, Jan 3, 2018 at 1:31 PM, Peter van Dijk
<peter.van.dijk@powerdns.com> wrote:
> Output edited for brevity:
>
> $ dig ds root-servers.net @d.root-servers.net
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17643
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;root-servers.net.              IN      DS
>
> ;; AUTHORITY SECTION:
> root-servers.net.       3600000 IN      SOA     a.root-servers.net.
> nstld.verisign-grs.com. 2017111600 14400 7200 1209600 3600000
>
> $ dig ds root-servers.net @e.root-servers.net
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;root-servers.net.              IN      DS
>
> ;; AUTHORITY SECTION:
> net.                    172800  IN      NS      a.gtld-servers.net.
> net.                    172800  IN      NS      b.gtld-servers.net.
> .. ..
>
> ;; ADDITIONAL SECTION:
> a.gtld-servers.net.     172800  IN      A       192.5.6.30
> b.gtld-servers.net.     172800  IN      A       192.33.14.30
> .. ..
>
>
>
> When running the query in the Subject, these are the two possible outputs I
> have observed from various root servers (with some variation from the same
> letter, presumably because of dual vendor strategies).
>
> From 4035 3.1.4.1, the NODATA response should be sent when:
>
>    o  The name server has received a query for the DS RRset at a zone
>       cut.
>
>    o  The name server is authoritative for the child zone.
>
>    o  The name server is not authoritative for the parent zone.
>
>    o  The name server does not offer recursion.
>
>
> Points 1, 2 and 4 are clear. It is point 3 that hurts here. The root servers
> are authoritative for root-servers.net. and for . , but not for net - and
> they know this because they can see the delegation in the root zone.
>
> It is my suspicion that 3.1.4.1 was not written with this edge case in mind,
> and I think that while 3.1.4.1 favours the NODATA response, the referral is
> much more useful. As a data point, the PowerDNS validator currently gets in
> trouble with the NODATA response:
> https://github.com/PowerDNS/pdns/issues/6138
>
> I think an erratum to 4035 is in order, clarifying the language such that
> servers would return the referral in this case. I have not figured out the
> exact wording yet (but I will).
>

Errata are for fixing bugs ("Errata are meant to fix "bugs" in the
specification and should not be used to change what the community
meant when it approved the RFC." -
https://www.ietf.org/iesg/statement/errata-processing.html), not for
updating documents to add functionality / address cases which were not
originally considered (of course, that page does also say: "Common
sense and good judgment should be used by the IESG to decide what is
the right thing to do." :-))

So, if / when this is reported, please help me justify this as a bug
fix, and not adding functionality / changing the meaning of the
original doc.

W


> What does dnsop think?
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> 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