IETF Logo Mail Archive

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

Ólafur Guðmundsson <olafur@cloudflare.com> Thu, 11 January 2018 01:05 UTC

Return-Path: <olafur@cloudflare.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 2992F12422F for <dnsop@ietfa.amsl.com>; Wed, 10 Jan 2018 17:05:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 U5klOt84v_he for <dnsop@ietfa.amsl.com>; Wed, 10 Jan 2018 17:05:02 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 84E59120454 for <dnsop@ietf.org>; Wed, 10 Jan 2018 17:05:02 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id i11so2281950wmf.4 for <dnsop@ietf.org>; Wed, 10 Jan 2018 17:05:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x2D53p6Kjw5M98+oIlyTH4namC5DrPCNL/Fnd7RXuuI=; b=gXXUkpZ+WWNS396WkqCrXNJGLvG4LrYwT7trA1gAWPodH8cO9CioziwhwdVRD90Hxj 7BvTdfOUsXhRip/RaarMkuMkqmVlLxGm+o2YYolv8q8eIRwu1c8N0mwyvpYMWQ/YkdHf bM8nXPSQde5MT/+nP8UFtaPH9c6Y5SG7MN4go=
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=x2D53p6Kjw5M98+oIlyTH4namC5DrPCNL/Fnd7RXuuI=; b=g8Al1Q/ZnwvePHRf7xaaLaugp17zD4s3PMuGpn58NayjtWWwy0Unu4OKIel5FCncbX JHObvlkkEJDBWXPp0b5xV5WZ+Et8mQ+k1dfXaJT4oxfIlrJWCVPDcBZcPNrE6+Ot/LiN 7i2BygCiOTa6JkrlPNAGJTu967U1Z8XLNsqxvppeMtUOQQe3XbBUjfA653BPOS2JsE8c jaxXe8jy+CuSJxNLf6AQsGIfGAAThrJncKeNqtqRb5plQUEA3omKejp6g3/q0LGwxdOb 2w2rLcuzjEmKlVjYABEQeOnG7EE7Ge3T6YBd+lqbO7E2Ypoi1GiUNfWBmFXbGoByLhz1 48KA==
X-Gm-Message-State: AKwxytdhIGweD/Kjby+znYe/j8iaJ5pjqLsWJyzZbnzAouO2Fge6Y6kE vhuYbz7/9i/+BrA1LrbfhPXN5qSM3Dwel01Hl6IukA==
X-Google-Smtp-Source: ACJfBouDpXGfp9J8h0H/3TjMdT3uqdxeIbdf10PabI013B17BMeEWplNShsSiWz5WHgWcqv/WQH77Uelu9FUrVnRUmI=
X-Received: by 10.28.232.131 with SMTP id f3mr6745727wmi.69.1515632700848; Wed, 10 Jan 2018 17:05:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.172.79 with HTTP; Wed, 10 Jan 2018 17:05:00 -0800 (PST)
In-Reply-To: <CAJE_bqeUjtFfWzJA56O-Y68Zbke3U4w-PUFhaC4nfcsy0a3J8A@mail.gmail.com>
References: <E361FA78-84DF-4B42-AFAC-C8C6CC140158@powerdns.com> <7EF7E67D-E013-44FF-83D5-C35E197F4B8B@isc.org> <CAJE_bqeUjtFfWzJA56O-Y68Zbke3U4w-PUFhaC4nfcsy0a3J8A@mail.gmail.com>
From: Ólafur Guðmundsson <olafur@cloudflare.com>
Date: Wed, 10 Jan 2018 17:05:00 -0800
Message-ID: <CAN6NTqy=aQFRBDZVba6NzsoBq7CWKU9c5tB971VArsPSjZpN0w@mail.gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Cc: Mark Andrews <marka@isc.org>, dnsop <dnsop@ietf.org>, Peter van Dijk <peter.van.dijk@powerdns.com>
Content-Type: multipart/alternative; boundary="001a11466f7cbe9861056275bc16"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4Q1kdyT9yYIX9Z824u-QeKuiMJI>
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: Thu, 11 Jan 2018 01:05:05 -0000

On Fri, Jan 5, 2018 at 10:27 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:

> At Thu, 4 Jan 2018 08:12:26 +1100,
> Mark Andrews <marka@isc.org> wrote:
>
> > The reply also has to work for STD13 clients which already know
> > about the child zone. The NODATA response is the correct one despite
> > it requiring more work for a DNSSEC client.
>
> Section 2.2.1.1 of RFC 3658 also explains that point:
>
>    [...]  As these queries are only expected to originate
>    from recursive nameservers which are not DS-aware, the authoritative
>    nameserver MUST answer with:
>
>       RCODE:             NOERROR
>       AA bit:            set
>       Answer Section:    Empty
>       Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
>
>    That is, it answers as if it is authoritative and the DS record does
>    not exist.  DS-aware recursive nameservers will query the parent zone
>    at delegation points, so will not be affected by this.
>
>
I hate having my own RFC thrown at me,
but it may or may not apply as there is another corner case that I/WG did
not consider,
what if the NameServer is authoritative for a zone above the parent.
In this case it has to select does it answer from the closest zone that can
answer DS record or
from the zone it self.

In the spirit of being helpful to recursive resolvers the right answer IMHO
is the referral from the
zone above the query name.

  Olafur


> --
> JINMEI, Tatuya
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

v2.23.0 | Report a Bug | By Email