Re: [DNSOP] draft-ietf-dnsop-delegation-only is still not useful

Joe Abley <jabley@hopcount.ca> Sun, 07 March 2021 23:03 UTC

Return-Path: <jabley@hopcount.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 A74053A1E76 for <dnsop@ietfa.amsl.com>; Sun, 7 Mar 2021 15:03:49 -0800 (PST)
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=hopcount.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 I_D5CZbyzNz6 for <dnsop@ietfa.amsl.com>; Sun, 7 Mar 2021 15:03:48 -0800 (PST)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 058773A1E74 for <dnsop@ietf.org>; Sun, 7 Mar 2021 15:03:47 -0800 (PST)
Received: by mail-qv1-xf2b.google.com with SMTP id 2so3828355qvd.0 for <dnsop@ietf.org>; Sun, 07 Mar 2021 15:03:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GP6Owrk5s5tCf/jO/wQUBD/8REdzUtscXX6NTJOKwDs=; b=RQndNfwdWpXit1xtJEszkxae4fhGbHeP7bef7DUv6gbAmU5g8s+RBVCNd/AzjLQOrh 6Tp3CLm/I0VvcjGwP7KIFGCfW8AlBqzYKiX8PLAGZdpFvxjDEcOKPskcCFFtPEAvshHH LpGL1dXOc0KmS+T+lXjqOPtECeT37ONZkswXg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GP6Owrk5s5tCf/jO/wQUBD/8REdzUtscXX6NTJOKwDs=; b=t/TDtcrtzePzyX7w3SIeHwcnGGRTFxOs/E+NQGvz+7F7FUrwE5xL9/lBngh6plTua2 t3UGNf5aMBoNApuNCr5RrjEC6Z0BRNvqsCo+/xjFK6r/C74cdAvHEdN+FLZaHhh6kHb5 Hu5WSSUTxwMoyGtkqKoMXRBrBxGEzirZ6OsBwftNBielBzwrh22fSWZNK+LbrBuiy7qu SIc/OMolXq3Oe4WQfW9EeB6XwYxx6v01Ps28Tw4Rfv3Z2S70ox5bnEHm4uW2pQO1dCAW 96wRnFkd3OAg4C3IBOUh0Ghc9jocJFvB7Ld/EWKnMJyD6C4yIJVUTv9Zl2jQ116w1fVf MCWQ==
X-Gm-Message-State: AOAM53021I11qFGHd04602o6NbQ/kL2pRss00HjQW4fI4UD8RRZ5pL+W ouKVZJe59D6P8N8bo5vw/o+IBA==
X-Google-Smtp-Source: ABdhPJwoFjezXaG9MTz7KbLFNZUffRFY61lQu36Nv6UTCrmF+/ZyPNAUQ2WhlpMRDJmn8I7d4oZfDA==
X-Received: by 2002:a0c:fdec:: with SMTP id m12mr18662138qvu.11.1615158224812; Sun, 07 Mar 2021 15:03:44 -0800 (PST)
Received: from ?IPv6:2607:f2c0:e784:c7:ac10:16f7:564e:c254? ([2607:f2c0:e784:c7:ac10:16f7:564e:c254]) by smtp.gmail.com with ESMTPSA id d84sm6477283qke.53.2021.03.07.15.03.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Mar 2021 15:03:43 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <9691651a-ee7e-7884-64f9-a2274a9d897f@nohats.ca>
Date: Sun, 7 Mar 2021 18:03:41 -0500
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2BE744A8-3186-4284-ACB8-E29480901DBA@hopcount.ca>
References: <20201103221931.C535A2556CB7@ary.qy> <A0E0A513-5FE6-4201-8028-6D2E303B97E6@dukhovni.org> <9691651a-ee7e-7884-64f9-a2274a9d897f@nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UDoH4d6kLIjtPJiFaOtOdvQ9rqs>
Subject: Re: [DNSOP] draft-ietf-dnsop-delegation-only is still not useful
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: Sun, 07 Mar 2021 23:03:50 -0000

On 7 Mar 2021, at 15:23, Paul Wouters <paul@nohats.ca> wrote:

> Note that the count presented has other issues too. For example,
> the first pseudo random domain I picked to look further from the top
> of the file:
> 
> info.txt.gz:ns1.breeat.info.	86400	in	rrsig	a	7	3	86400	20201123152255	20201102142255	27464	info.	cDhuFyGRJqi2uJnAuYMuHguwvHQx498oIQawSOXNBMxewSnudEeeElsgXXw3vuN1t+tOX2v9Y+WMdB5Wh3I1gkon3xxC6ZX2njDq5wcqDNFIm/pGpZkM2Bwv/7uzU9Hx8r+Lmn3lNgyhEKFc0f/H8ESveGw93jK/bkoQnjQf5qI=
> info.txt.gz:ns1.breeat.info.	86400	in	rrsig	a	8	3	86400	20201123152255	20201102142255	44286	info.	Kx2nR9MxG2NDbO8pYGlwET5JFjvIJnYMswvptkU/oqj2a5bb4i1qU9cBQg6P5zZ7ekstxCJjV08HyUkh30b9Sn/sCJovVA+OEoOEef4r+yij2XQN93kvli19fqNDfNPEnO8fQqZ3ifcvFvs8S1EEJKlcPVSsnlSVnFPPRVlye/U=
> info.txt.gz:ns2.breeat.info.	86400	in	rrsig	a	7	3	86400	20201123152255	20201102142255	27464	info.	mVxcu2heoUVOuahh9GODtZBMomdYZ1MsiJ41nYAgf0SCUy8oD9qJ/7yCFZg7WOyiGNUHEtuyBBAyj6DxKbSURDOhZ3Auarha298bo2z4n8Q4HIBMjFWE4imQ9K9ZayB8j2uG8i7V8l7asnbGKvM1b4C7fnB43pY7L9pt8xcAIZc=
> info.txt.gz:ns2.breeat.info.	86400	in	rrsig	a	8	3	86400	20201123152255	20201102142255	44286	info.
> 
> These are 4 RRSIG for 2 name servers with an A record for which the
> domain no longer exists.

Just a point of clarification -- the domain does exist; it's just suppressed from publication in the DNS.

jabley@manta ~ % whois -h whois.afilias.net breeat.info | fgrep Status
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverHold https://icann.org/epp#serverHold
Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
jabley@manta ~ % 

When it comes to TLD zones, it's necessary to consider the registry data as well as the DNS if you want to be sure you are seeing the whole picture.

>  Note that ns1 and ns2 point to the same single
> IP address. I don't know how many other zones use these two nameservers,
> but a quick check shows that there are no DNS server running on that IP
> address anyway.
> 
> The TLD might as well just remove the glue. It is just garbage. It only
> causes users longer timeouts into the inevitable failure of reaching those
> nameservers. That is, actually not having these records is an _advantage_
> over having them.

gTLD operators can't just remove things that in its opinion are not working or not necessary. The things they can and can't do are constrained by contract. I appreciate that there are many registries that are not run by contracted parties, of course.

In general, it's difficult to know for sure what the impact of removing a linked glue record is. A nameserver that doesn't respond today might be fixed tomorrow, or might never be fixed for particular clients due to some other local policy. There may well be extraneous orphan glue records (in the DNS sense) in the ORG zone that could safely be removed, but it's difficult to know for sure unless you have certain knowledge about the names concerned and the intensions of the organisations involved in them. There are definitely orphan glue records (same sense) whose removal would cause operational problems for other domains.

[...]

> Regardless, as explains before. The problem is not hard to solve by
> moving the signed glue into its own delegated special zone, which would
> have the benefit of _clearly_ indicating to anyone who sees these NS
> records that the domain is about to fall over. It is an improvement to
> do this even if you don't do it to prepare for being a delegation_only
> zone.
> 
> Based on this and the recent .org glue cleanup, I think there might even
> be a good reason to write up a new draft about promoting-stale-glue-is-bad.

You should feel very free to write up whatever you want :-) but as I have mentioned a few times, so long as there are reasons to suppress publication of zone cuts for particular domains, e.g. for reasons of abuse management, and so long as it's possible to link subordinate host objects to other domain objects that *are* published, and so long as the data model specified in EPP remains as it is, the number of promoted glue records in zones like ORG are not going to reach zero and suppressing orphan glue (orphan in the DNS sense, not the registry sense) definitely has the potential to break things.

I don't think you make something a problem by calling it one. These things are only problems because you have a use-case for zones like these being delegation only, and the reality of how these zones are constructed doesn't fit nicely with that. I also don't think you can solve a problem by declaring the solution to be simple on the grounds that you've ignored all the things that would otherwise make the solution complicated :-)


Joe