Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Tony Finch <dot@dotat.at> Thu, 30 July 2020 22:30 UTC

Return-Path: <dot@dotat.at>
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 E40993A048D for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 15:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EdQX4OIGrArK for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 15:30:12 -0700 (PDT)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 500493A048A for <dnsop@ietf.org>; Thu, 30 Jul 2020 15:30:12 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:60534) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1k1H3x-000e8c-1i (Exim 4.92.3) (return-path <dot@dotat.at>); Thu, 30 Jul 2020 23:30:09 +0100
Date: Thu, 30 Jul 2020 23:30:09 +0100
From: Tony Finch <dot@dotat.at>
To: John Levine <johnl@taugh.com>
cc: Joe Abley <jabley@hopcount.ca>, dnsop@ietf.org
In-Reply-To: <rfv9s4$2mta$1@gal.iecc.com>
Message-ID: <alpine.DEB.2.20.2007302306530.16320@grey.csi.cam.ac.uk>
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <alpine.LRH.2.23.451.2007301253530.416340@bofh.nohats.ca> <F16107A1-669C-41AD-9F59-1794C64B0737@hopcount.ca> <alpine.LRH.2.23.451.2007301446380.418549@bofh.nohats.ca> <rfv9s4$2mta$1@gal.iecc.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ipB44rN8ycvHemTy7SM89fCsqRY>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
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, 30 Jul 2020 22:30:14 -0000

John Levine <johnl@taugh.com> wrote:
> Paul Wouters  <paul@nohats.ca> wrote:
> >
> > Has anybody done a survey to find out how many TLD zones actually
> > fits the description of "delegation-only"?
>
> I did some greppage, and found that all of the domains run by Verisign
> and Nominet have signed non-glue A records. I think there are a lot of
> TLDs run by others that are delegation only but they're mostly tiny
> vanity domains.

If there are RRSIG(A) records in .com and .net there must have been a
policy change since 2010?

There was a very subtle behaviour tweak implemented by Verisign for orphan
glue aka host objects that have lost their domain objects: although the
address records appear in the zone file, the name servers do not answer
queries for them authoritatively: the addresses only appear in additional
sections in referrals, and are not signed according to this:

https://seclists.org/nanog/2010/Jan/298

I don't know if other nameservers implement the same behaviour. AFAIK it
isn't possible to represent orphan glue in standard zone files or zone
transfers, so I think this is an ATLAS special.

Also despite having discussed this several times before I have not
previously thought properly about how signing such a zone works! I suppose
the assumption is that most resolvers are delegation-centric by default so
they won't normally come back to validate the glue in the referral and
won't discover it has been orphaned. So it usually won't matter if
gtld-servers.net return an NSEC3 opt-out denial in response to a direct
query for an orphaned glue record..

Maybe an NSEC3 opt-out covering these address records is enough to imply
that they are orphan glue without needing new zone file or zone transfer
syntax...

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Viking: West backing southeast 2 to 4, increasing 5 or 6 later. Slight or
moderate. Occasional rain. Good, occasionally poor in north.