[DNSOP] Input from DNSOP on NCAP proposal

"Thomas, Matthew" <mthomas@verisign.com> Thu, 26 May 2022 12:00 UTC

Return-Path: <mthomas@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 162E1C15EB52 for <dnsop@ietfa.amsl.com>; Thu, 26 May 2022 05:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Status: No, score=-7.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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=verisign.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9lp_XhibA7jq for <dnsop@ietfa.amsl.com>; Thu, 26 May 2022 04:59:55 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com []) (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 CFAC9C159525 for <dnsop@ietf.org>; Thu, 26 May 2022 04:59:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=25413; q=dns/txt; s=VRSN; t=1653566394; h=from:to:subject:date:message-id:mime-version; bh=D3tVjHlyy2ffSs9O0yh9UIWKYEpfenujyjknkPQ/4wM=; b=LP9kKYNQnwT24AQfzS01HVoB+9QgAjR1WRs/vkwVP5nXx2ExqmFVvSzX oKF+nlMFKRtqF+yywt2DE2eNVBD94afdZ5C65Ur0EYIWkwGqQEgTEodQ0 WhIhP2PT7FsozGJG3BIVh8vX+9OpCBF6uFolxRN985n7UnB1L2m31hfO3 WAjQftO4RpiHd6UOKYyXymiKD75/rLvI29t9/Gq0zr6oih27M/QuLysaS C61BJyBUEZMrgP1nR8oOVcBguoSzS3pTQ44djwkUug7bVOEzeUf7uCMxo njwXs6walmbTjI7OjMPouAicBERuvzdwM1DYnCfHbbTFf2joBKao+JIaX g==;
IronPort-Data: A9a23:vRrcuKAfs1WEXhVW/4fhw5YqxClBgxIJ4kV8jS/XYbTApG931zBWz DcZDW2PPPeNZWOnfd5xPdi0/UMD7ZXQyddlTANkpHpgcSlH+JHPbTi7wuUcHAvJd5GeExg3h yk6QoOdRCzhZiaE/n9BClVlxJVF/fngqoDUUYYoAQgsA149IMsdoUg7wbRh39Q22YHR7z6l4 rseneWOYDdJ5BYpagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/Df2VhNrXSq 9Drl+jlozyDr3/BPfv++lrzWhVirrf6Y1DS2iIOM0SoqkAqSicais7XOBeAAKv+Zvrgc91Zk b1wWZKMpQgBEKnUgOcsbQRhC2IgJLMXwa7iPSLgmJnGp6HGWyOEL/RGJnsQZLI+19YvWCdQ/ vsCMHYEYladnfmwhrm8T4GAhOx6dI+yY9hZ4yw7i22JZRolacmrr6Hi4MNY2zI5nehQEOzff MsWb3xkaxGojxhnYwpOWMJjw7nAan/XXiJXqE6LhfQNoFP/5SEt04O2GfeJdYnfLSlStgPCz o7cxEz1BAodLPSexCaLtHW2iYfycTjTUpgUTaK+++4y2RiI2HZVDRwNEFG85/OjjBf4RchEL Qof/S9GQbUOyXFHh+LVB3WQyENodDZFMzaMO4XWMD2w95c=
IronPort-HdrOrdr: A9a23:JTcdfKrU9u9YMaXH+x6CXUMaV5obeYIsimQD101hICG9Kvbo9P xG785rtyMc6QxhIU3I9urgBEDtexnhHP1OkPEs1NWZPDUO0VHAROpfBODZrwEIbheRygcr78 hdmsZFZeEYRmIK6PoSqDPId+rJirO8gceVbMnlvhFQcT0=
X-IronPort-AV: E=Sophos; i="5.91,252,1647302400"; d="scan'208,217"; a="15188576"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ( by BRN1WNEX01.vcorp.ad.vrsn.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Thu, 26 May 2022 07:59:53 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([]) by BRN1WNEX01.vcorp.ad.vrsn.com ([]) with mapi id 15.01.2375.024; Thu, 26 May 2022 07:59:53 -0400
From: "Thomas, Matthew" <mthomas@verisign.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: Input from DNSOP on NCAP proposal
Thread-Index: AQHYcPgbQhJVrw0KZkiKcBNufEo2Vg==
Date: Thu, 26 May 2022 11:59:52 +0000
Message-ID: <63C24D03-1E35-44FF-A611-89A5FBFB9569@verisign.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.59.22031300
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_63C24D031E3544FFA61189A5FBFB9569verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-MU8pH1PON7SQBmmL1NrDt_VmP4>
Subject: [DNSOP] Input from DNSOP on NCAP proposal
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.34
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, 26 May 2022 12:00:00 -0000


The Name Collision Analysis Project (NCAP) group is considering new ways in which additional DNS data can be collected for name collision assessment purposes while attempting to preserve the NXDOMAIN response dependent systems and applications currently receive from the root. We are looking for community input around any known technical challenges or problems with the proposed delegation strategies listed below. Here is some relevant background and context for the proposal.

First, within the context of NCAP, a name collision refers to the situation where a name that is defined and used in one DNS namespace may also appear in another. Users and applications intending to use a name in one namespace may attempt to use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces.

In the 2012 round of new gTLDs, DNS data collected at the root server system via DNS-OARC’s DITL collection was used to assess name collision visibility. The use of DITL data for name collision assessment purposes has growing limitations in terms of accessibility, increasing data anonymization constraints, a narrow data collection time window, and the limited annual collection frequency. Other changes in the DNS, such as Qname Minimization, Aggressive NSEC Caching, etc., also continue to impair name collision measurements at the root.

The 2012 round of new gTLDs used a technique called Controlled Interruption.  Attempts to query a new TLD during the controlled interruption period for an A record would result in an answer of the loopback address The change from NXDOMAIN to an answer was intended to be a gentle disruption to systems experiencing name collisions (i.e., systems that were explicitly or implicitly relying on a NXDOMAIN response) and the mnemonic IP address was intended to lead investigative system administrators to informative web search results telling them about the TLD’s delegation.

In preparation for the next round of TLDs, the NCAP team is examining possible new ways of passively collecting additional DNS data while providing a less disruptive NXDOMAIN response to queries.

Currently, any recursive name server querying for non-delegated TLDs gets a NXDOMAIN from the root. Enumerating all possible ramifications of negative answers on end users and applications is not possible; every application can react differently to negative answers. Regardless of the reason, the errors received when returning a NXDOMAIN answer are both useful to systems and end users (e.g., spam filtering services, search list processing, etc.).

The proposed system below is an attempt to preserve the NXDOMAIN response these name collision systems are currently receiving, while enabling additional data collection capabilities. The NCAP is looking to the DNS community to see if you are aware of any kind of technical implications from a risk perspective that the proposed configurations would a.) cause systems to behave differently or b.) induce harmful collateral damage.


The proposal would involve delegating a candidate TLD. The delegation process of inserting a string into the DNS root zone will make the TLD active in the domain name system. The required delegation information in the referral from the root is a complete set of NS records and the minimal set of requisite glue records. The candidate TLD would be delegated to servers running custom DNS software. The TLD would not be DNSSEC signed.

We would like to understand which of the following configurations would be the least disruptive to systems and applications that were relying on the NXDOMAIN response.

Configuration 1: Generate a synthetic NXDOMAIN response to all queries with no SOA provided in the authority section.

Configuration 2: Generate a synthetic NXDOMAIN response to all queries with a SOA record.  Some example queries for the TLD .foo are below:

1) Query for bar.foo returns NXDOMAIN with SOA
2) Query for .foo returns NXDOMAIN with SOA
3) Query for .foo SOA returns NXDOMAIN with SOA
4) Query for ns1.foo NS or ns2.foo returns NXDOMAIN with SOA

Configuration 3: Use a properly configured empty zone with correct NS and SOA records. Queries for the single label TLD would return a NOERROR and NODATA response.

The level of disruption to existing private use of such labels by this restricted form of name delegation would be reasonably expected to be minimal; however, the series of referrals and responses received by resolvers are different from a direct NXDOMAIN response from the root server system and deviate from the DNS protocol. It is possible that even this slight difference could impact application resolution processes, such as search list processing. The NCAP would appreciate any technical insights from a risk perspective the community may be able to provide regarding the proposal.


Matt Thomas
NCAP Co-chair