IETF Logo Mail Archive

Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

Ted Lemon <mellon@fugue.com> Thu, 07 February 2019 12:53 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 5ADE6130EDE for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 04:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Level:
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 gPaPKmlQAGzU for <dnsop@ietfa.amsl.com>; Thu, 7 Feb 2019 04:53:08 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 3332112D4F2 for <dnsop@ietf.org>; Thu, 7 Feb 2019 04:53:07 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id u188so6344635qkh.8 for <dnsop@ietf.org>; Thu, 07 Feb 2019 04:53:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wNKggg90o6tWkKO3tHK2hU31Grq9vnjFn5UjhlYcKDQ=; b=q33eQPN470YZHZKHiQkU/qOq6yVQ+P8ZfsXGCzSas0hsE1Q00TIrjPissZ4mYzsoDe N0zrryG12F/Dntb98dOnYHUbdLyMbRdYRL2RA/HQOOJyU/9MaHlkbf+ScydCiYa94lMw 6AXVUE5cXI5zol2QzaXzOSOESypgZQJkMBv0dH4/JAzY+xgtcKAVYt5BYf9Gxj1RMT/4 liWh2aE+ksVHbMKquvh4s3srITFCU2qhEXbZV8GE1oTxsN3ERti6YWTxsGbRG2OFakkq vj6H8Sf0h5WfVdzGxdALpSW5BgOKVJgw2H3sBJzVb+HZLM6V/e0J84KrEMio26xzMJpr c8RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wNKggg90o6tWkKO3tHK2hU31Grq9vnjFn5UjhlYcKDQ=; b=Gt4v0D3CD1zWt2vG4OTWCJeZ6NuvUnhI5UITyspm0AAI0+WX5wFvwQthwyMCAHyFX8 KQWVAxjbB1B3pWYowbSBo31Okl8A2RaXE9b/FUjocI4FGimZh9ZoAWajZ6k0fEVqmQaE vRkwJdchYKk+TtXWPqOugFPCg85pHN9bTbMXHGw+zvhqfvUY1QaEM098TAVhECTrkiy8 pqrIOtPeWt8ECdaswmSzKqxVgxmi/lbGnO1mIRZTAF+wCiQMCZBSLqx/bq1lSe315N/y jrZ195/g4iwSQ92IwHchV5kLMYmMwur/9EGdDMBOgxCHFibl4rJxqQcY/wJK4xdvMmbi HzJg==
X-Gm-Message-State: AHQUAub3ZyXSJAcd7oX2p7FL3/Q63buXf0xdp77mCpmUakghtCkjd0iO xRvgL1BBH8JK2kBSI3j52MLpBA==
X-Google-Smtp-Source: AHgI3IYgxsEXRF+UhmT70KTHXomQqQLhmZDqPsMT5Nwp6GD7O8bNBqxyag61R2O8UeyTZAtKsqLraQ==
X-Received: by 2002:ae9:d804:: with SMTP id u4mr11603802qkf.322.1549543987079; Thu, 07 Feb 2019 04:53:07 -0800 (PST)
Received: from [10.0.100.12] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id 13sm2234880qtv.78.2019.02.07.04.52.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 04:52:37 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <F821C2A2-BD6F-41D1-A2D6-3928E783614B@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C4A6EE79-A79B-4DDC-A15A-BC6D13C6BEB7"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 07 Feb 2019 07:52:33 -0500
In-Reply-To: <48a12f46-eee1-823e-a448-8f3b0d973f7d@nic.cz>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
To: Petr Špaček <petr.spacek@nic.cz>
References: <fcd790a2-414b-491e-01e2-9aa92f7b1c4e@nic.cz> <CC75C79C-E5FB-4C91-9453-103E36EDC505@fugue.com> <48a12f46-eee1-823e-a448-8f3b0d973f7d@nic.cz>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vK6BzDQljpv4gTwoPs7HbG3Kb4s>
Subject: Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?
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: Thu, 07 Feb 2019 12:53:10 -0000

On Feb 7, 2019, at 7:44 AM, Petr Špaček <petr.spacek@nic.cz> wrote:
> When looking at it from resolver perspective, what is the resolver
> supposed to do with query "zone. NS" if there is no authoritative NS set
> in the zone? Return NOERROR+NODATA?

It should reply with no error and no data.   But this is okay, because you never need to ask this question in order to resolve a name.   If you are looking up an NS record with intent to use it, it’s going to be in the parent zone, where you are looking for a delegation.

The real question is whether the NS record needs to be validated.   If it does, then it needs to be signed, and so it needs to appear in the zone.   But that’s what the DS record is for, right?   :)

v2.23.0 | Report a Bug | By Email