Internet Architecture Board

RFC2850

IAB Minutes 2022-11-10

Home»Documents»Minutes»Minutes 2022»IAB Minutes 2022-11-10

Minutes of the 2022-11-10 IAB Business Meeting, London

1. Attendance

Present:

Jari Arkko
Deborah Brungard
Lars Eggert (IETF Chair)
Wes Hardaker
Cullen Jennings
Mallory Knodel
Mirja Kühlewind (IAB Chair)
Warren Kumari (IESG Liaison)
Zhenbin Li
Cindy Morgan (IAB Executive Administrative Manager)
Karen O’Donoghue (ISOC Liaison)
Colin Perkins (IRTF Chair)
David Schinazi
Russ White
Qin Wu
Jiankang Yao

Guests:

Harald Alvestrand (ICANN Board Liaison)
Olaf Kolkman (Internet Society)
Eliot Lear (Independent Submissions Editor)
Daniel Migault (ICANN RSSAC Liaison)
Éric Vyncke (IESG)
Rob Wilton (IESG)
Suzanne Woolf (DNSOP Chair)

Regrets:

Tommy Pauly

2. DNS and Alternate Name Spaces

Suzanne Woolf briefed the IAB on special use domain names.

DNS is the Internet default application-independent naming system. It has been enormously successful in that role. The technical and economic model of allocating domain names for use by the DNS protocol works fairly well. The IETF delegated policy responsibility to ICANN for that model in RFC 2860. However, sometimes people want or need other naming systems. There have always been other naming systems and there will always be. However, trouble can arise because: it is easy to re-use existing or previous domain name conventions (GNS, namecoin, mDNS, etc. use DNS naming-like conventions), and may not be consistent with the established conventions of the global DNS.

The value of DNS is in being a useful default for resolving things that use the (relatively simple) domain naming conventions. This enables permissionless innovation. However, this usefulness relies upon unique names and a default resolution protocol that doesn’t need to be specified. Without it, the overall usefulness of the DNS as a default, application-agnostic naming protocol for the global Internet is undermined. RFC 2826, “IAB Technical Comment on the Unique DNS Root,” explains why globally unique names and resolution are essential to the value of the DNS. RFC 6761 explains why there might need to be special cases, and gives some guidance on how to identify where one might be needed.

There is an active draft in DNSOP, draft-ietf-dnsop-alt-tld (The ALT Special Use Top Level Domain), that discusses an Alt-TLD proposal. The draft solves the problem of potential ambiguity with non-DNS protocols also using domain naming conventions and provides a “protocol switch” that DNS resolvers can ignore requests below the .alt switch point. This may enable a replacement to DNS, or may just prevent experiments from conflicting with DNS integrity.

Mirja Kühlewind asked why this can’t use .arpa instead. Suzanne Woolf replied that .alt is expected to function as a signal that it is not operating as DNS resolution at all. DNS resolution relies on .arpa being signed.

The main open issue in DNSOP is whether to have normative language regarding how DNS servers handle .alt names. The WG is close to consensus, but it as to fit into the framework of RFC 2860 and RFC 6761: ICANN is responsible for the DNS root zone, i.e. what top-level domains exist to be resolved by DNS, and the IETF has to retain the ability to determine where there might be exceptions “for technical use.”

The Independent Submissions Editor (ISE) has been asked to publish a draft, draft-schanzen-gns, on GNS (The GNU Name System). GNS re-uses the domain name format, but its names are an overlay on the familiar root of the DNS tree; it generates its own “TLDs,” and there’s no mechanism for avoiding collision with DNS names. If the ISE publishes this draft, it will look in certain circles like the IETF is blessing alternate roots. The authors have suggested that they would ask (but not require) that people use gns.alt for GNS names. This is much like the .onion reservation, except that it’s a single label that can be used ad-hoc at the second level.

Eliot Lear said that the GNS proposal came to the ISE before he took on the role. The draft is currently awaiting RFC 5742 conflict review by the IESG.

Updates have been suggested to RFC 6761. In addition to RFC 8244 (Special-Use Domain Names Problem Statement), there is a draft proposing that the guidance to the IESG and the community in RFC 6761 Section 5 should be done away with. Regardless of what we want to say about “alternate roots” and “pseudo-TLDs,” the IETF needs guidance for WGs and IETF protocols, including when to use .arpa for special use names. DNSOP has made little progress; drafts updating 6761 have been introduced but gotten little traction. Some DNSOP participants actively oppose doing this work in DNSOP, or in the IETF at all.

There are architecture-level naming issues:

  • DNS will not last forever.
    • It is important to preserve the current architecture around naming while it’s useful.
    • There is a need to leave (interoperable) room for something better that could come along.
  • This is an Internet-architecture level concern.
    • DNS has been fantastically useful
    • It is flexible partly because it was not overly specified at the beginning.
    • It has continued to develop and evolve, with its death periodically predicted.
    • DNS v2.0 has been dreamed about but always put off.
  • There is no obvious home for this broader work
    • RG?
    • New WG?
    • IAB program (has been tried, without notable success)?
    • BOF to decide (has been tried, without notable success)?
    • Academic exercise?
    • Leave it to ICANN?

Potential next steps include:

  • DNSOP WG Last Call for draft-ietf-dnsop-alt-tld
  • Getting ahead of any narratives that the IETF is blessing alternate roots or stepping on ICANN’s authority
  • Putting focused attention on the questions at https://www.ietf.org/blog/onion/
  • Taking a closer look at architecture issues

The IAB owns the IETF’s relationship with ICANN and choices of how to approach outreach. Key points for the background to any correspondence include:

  • IETF consensus to add .alt to the Special Use Names registry is considered within the RFC 2860 framework.
  • .alt is not intended in any way to give anyone a TLD, or compromise the agreement in RFC 2860.
  • .alt is expected to relieve pressure on the IETF for future single-label name requests, by giving them an anchor at the second level (.gns.alt, instead of .gns).
  • The advantage to interoperability could be described clearly to technical and policy communities.

Ideally, ICANN would acknowledge that this action is within the 2680 framework. It would be helpful for ICANN to add .alt to its list of reserved names that will not be delegated in any future new gTLD process.

ICANN has been moving forward slowly on defining a reserved root-level name for “private use DNS” (SSAC113), which is names that are intended to be resolved with DNS protocol but are not globally scoped (cf. RFC 1918 and locally-routed IP addresses). Correspondence regarding SAC113 could provide a model (https://www.icann.org/en/system/files/correspondence/marby-to-cooper-kuhlewind-22oct20-en.pdf), but it is not clear what form this should take.

Rob Wilton said that draft-ietf-dnsop-alt-tld is close to Working Group Last Call, and while there are some who do not want the document to be published, they are not objecting to it going ahead. Rob suggested that after the document completes WGLC, they should send a liaison statement to ICANN about what they are planning to do and ask if there are any concerns. This matches the decision made by the IAB in the past to wait until WGLC before sending a liaison statement to ICANN.

The IAB thanked Suzanne Woolf for the update.