Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

Paul Wouters <paul@nohats.ca> Wed, 28 July 2021 18:00 UTC

Return-Path: <paul@nohats.ca>
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 F0AC83A0B89 for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 11:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca
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 XW1nX57U5x5r for <dnsop@ietfa.amsl.com>; Wed, 28 Jul 2021 11:00:41 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05933A1A71 for <dnsop@ietf.org>; Wed, 28 Jul 2021 11:00:38 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GZhKH1KBnz5CH; Wed, 28 Jul 2021 20:00:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1627495235; bh=zZvxowHG/Mt1Ox4iCVD9K2kPYFDbhcwTJKhzkQt66IY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VSu7EswBq0Pr8INJbmfLPWM1WCXMX1MmRexEWRCQLzS7Vnemw9uJnvqyyUfj2UKm+ aramK9BRk8RcBXaiSGDjS10+eP+rfxUJ8DYDjKjnz4+LtduCWieca2vfjSnSyXjyZT 9sE6m+X4NWEyIs+ZMmZyA7Ch2WdcYzy2fmSeT6Jo=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id dprzU5ZYWfLw; Wed, 28 Jul 2021 20:00:34 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 28 Jul 2021 20:00:33 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id E56C5D26D8; Wed, 28 Jul 2021 14:00:32 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E459AD26D7; Wed, 28 Jul 2021 14:00:32 -0400 (EDT)
Date: Wed, 28 Jul 2021 14:00:32 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Joe Abley <jabley@hopcount.ca>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <37EC8973-1357-42EF-A589-1CEBCFC9F9D0@hopcount.ca>
Message-ID: <496c910-f5d6-6329-e040-886fb55a2f7b@nohats.ca>
References: <AE200EA2-F856-4921-9C9B-72FF0043BE42@nohats.ca> <37EC8973-1357-42EF-A589-1CEBCFC9F9D0@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/888S-ehG6ChowoiykSig32qms_o>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt
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, 28 Jul 2021 18:00:46 -0000

On Wed, 28 Jul 2021, Joe Abley wrote:

>> Do you want dns servers to spend extra CPU power to lookup whether this is a “non-functional” glue case instead of spending less CPU just looking if it has a glue record and adding it?
>
> I'm not sure I understand your argument about what is more work for the authority server.
>
> Checking whether a referral targets nameservers whose owner name is below the zone cut seems straightforward.

If the zone example contains amongst other content:

foo.example. IN NS ns0.foo.example.
foo.example. IN NS ns0.bar.example.
ns0.foo.example. IN A 1.2.3.4
ns0.bar.example. IN A 1.2.3.5

Then for the DNS server returning an NS query for foo.example, it is
easy to either:

1) return ns0.foo.example's A record

or

2) return ns0.foo.example and ns0.bar.example. A records`

What is harder to do is determining whether it should or should not
include ns0.bar.example's A record based on whether it is "needed" or
not, as there are various kinds of loops possible.


> This is work that authority-only servers already do.

I think I agree, that auth-only servers already do 1) or 2)

> I don't see where the "extra CPU power" you are talking about comes from.

To determine if the glue you know you have is "needed or not".

Paul