The 122nd IETF meeting took place in Bangkok, Thailand between 15 and 21 March 2025 with over 150 working group sessions, a 2-day hackathon, and a wide range of side events. Pawel Kowalik and Christian Simmen from DENIC attended the meeting and have written a summary of the main points of relevance for the CENTR members.
A pdf version of this report an be downloaded here.
Introduction
The mission of the Internet Engineering Taskforce (IETF) is to make the internet better. Most of the IETF's work is done online, but the organisation also holds 3 meetings a year. The 122nd IETF meeting was held in Bangkok, Thailand, from 15 to 21 March 2025.
With 1,424 registered participants, the meeting saw a lower number of participants than IETF 121 in Dublin, which is not unusual for the Asian spring edition. Around half of the participants (765 or 54%) were present on site. The remainder participated in the meeting online via the Meetecho platform.
The IETF Hackathon in the weekend prior to the meeting had 476 registered participants (403 on site, 73 remote), working on 36 different projects. There was also a 'code sprint', at which a small group of volunteers worked at improving the tools made available by the IETF, such as the well-known Datatracker.
Every IETF meeting has a packed programme. The latest week-long gathering featured over 150 working group sessions, the IEPG meeting, HotRFC Lightning Talks, a plenary session, and a wide variety of side meetings.
Informal activities
During the weekend prior to the main meeting, there were various informal activities: a Hackathon, the IEPG, and the HotRFC Lightning Talks.
Hackathon
The now traditional Hackathon got under way on the Saturday prior to the main proceedings. At the Hackathon, the applicability and interoperability of new concepts were tested on a collaborative, non-competitive basis. Groups were formed spontaneously to work on a range of experiments from a list of 36 projects. A total of 476 participants interacted and programmed together intensively throughout the weekend. The Hackathon concluded with result presentations.
Experimenting with post quantum cryptography in internet protocols was in full swing during the hackathon. As many as 4 projects were working on code in these areas. Notably two of them related to DNS.
The "PQC DNSSEC Metrics with MTL Mode" focused on collecting metrics related to the operation of PQC DNSSEC and the use of MTL mode for zone signing and query/responses. The team, led by Joe Harvey and Swapneel Sheth (both Verisign), measured response size and query time across different networks using various NIST PQC signature algorithms and MTL mode DNSSEC signatures. This work built upon previous IETF Hackathon efforts in implementing and demonstrating MTL mode for DNSSEC.
The other project, titled "PQC DNSSEC New Kids on the Block", was led by Ondřej Surý from ISC. This project focused on testing new PQC algorithms for DNSSEC. The algorithms that were implemented and tested included HAWK-256, HAWK-512, SQIsign, MAYO, and ANTRAG-512.
The RPP Hackathon Project had a goal to develop a testbed of RESTful Provisioning Protocol and was able to present a first working end-2-end use case binding RPP provisioninig interface with an EPP server.
IEPG
The Sunday morning of an IETF meeting traditionally begins with the IEPG (Internet Engineering and Planning Group), where attention is focused on topics with some form of operational significance.
Presentations at IETF 122 included:
- Geoff Huston discussing ECN (Explicit Congestion Notification) deployment statistics.
- Tobias Fiebig presenting on interactions between DNS(SEC), MTU, and IPv6.
- Joe Clarke sharing experiences from Cisco Live Amsterdam, focusing on IPv6 Mostly.
- Mohit P. Tahiliani detailing the challenges and opportunities of migrating the NITK Surathkal campus network to IPv6.
- Ondřej Surý presenting SIEVE, a new eviction algorithm for web caches.
HotRFC Lightning Talks
The Sunday ended with the HotRFC Lightning Talks, where speakers talked on a wide variety of topics and pitched ideas. In this context, 'RFC' doesn't stand for 'Request for Comments' but for 'Request for Conversation'. The HotRFC session is a fast-paced affair, designed to spark discussion.
From the number of presentations during the session the one on DNS Handles by Phillip Hallam-Baker presented yet another approach of using DNS-based identifiers in order to build open and global identity schema supported by BlueSky’s AT Protocol. Details also in the related Internet-Draft.
Formal proceedings
A few of the many working group sessions are outlined below. Because many of the sessions take place in parallel, it can be difficult to choose which one(s) to attend - therefore the list might not cover all the topics from all the working groups, it is the authors’ choice of relevant ones to the CENTR community.
DNSOP WG
As always, the DNSOP Working Group, which is concerned with the evolution of (the operational aspects of) the DNS protocol, was very active and its sessions were well attended. A few highlights are presented below.
Since the previous IETF meeting, several drafts have been ratified as RFCs. These include:
- RFC 9609, "Initializing a DNS Resolver with Priming Queries". This Best Current Practice RFC describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS resource record set (RRset) for the root zone and the necessary address information for reaching the root servers. This document obsoletes RFC 8109.
- RFC 9715, "IP Fragmentation Avoidance in DNS over UDP". This Informational RFC describes techniques to avoid IP fragmentation in DNS. It notes that DNS over UDP can lead to IP fragmentation when packets exceed the Maximum Transmission Unit (MTU) and discusses methods to prevent this by limiting response sizes and using EDNS(0) to signal receiver capacity.
- RFC 9718, "DNSSEC Trust Anchor Publication for the Root Zone". This Informational RFC describes the format and publication mechanisms IANA uses to distribute the DNSSEC trust anchors for the root zone. A client must configure a suitable trust anchor to obtain secure answers from the root zone using DNSSEC, and this RFC details how IANA provides this information. This document obsoletes RFC 7958.
- RFC 9660, "The DNS Zone Version (ZONEVERSION) Option". This Proposed Standard RFC defines a new EDNS0 option called ZONEVERSION. This option allows DNS clients to request and authoritative DNS servers to provide information regarding the version of the zone from which a response is generated, with the SERIAL field from the SOA RR being the initial version type defined. This can improve debugging and diagnostics by providing the zone version atomically with the DNS answer.
Several drafts were discussed during the sessions, indicating progress in different areas of DNS operations, mentioning here some of relevant ones:
- 'draft-ietf-dnsop-cds-consistency' (Clarifications on CDS/CDNSKEY and CSYNC Consistency) was presented by Peter Thomassen. The draft aims to prevent malicious take-over of keys by ensuring consistency among authoritative name servers regarding CDS/CDNSKEY/CSYNC records. It is being implemented by SWITCH for .ch/.li.
- 'draft-ietf-dnsop-domain-verification-techniques' (Domain Control Validation using DNS) was discussed by Shumon Huque. The draft provides recommendations for DNS ownership validation, including the use of TXT records with random challenges and the use of CNAME for delegated validation.
- 'draft-nottingham-public-resolver-errors' (DNS Filtering Details for Applications) was presented by Mark Nottingham. This draft addresses the lack of feedback to users when DNS filtering occurs. It proposes a mechanism to provide more details about DNS filtering to applications, potentially through extended DNS error codes and a registry of URLs providing further information. There was significant discussion regarding the complexity, potential for misuse, and existing browser behavior in handling such errors.
- 'draft-hoffman-duj' (DNS Update with JSON) was presented by Paul Hoffman. This draft proposes a simple JSON-based format (DUJ) for users to copy and paste DNS update information, simplifying the process of providing instructions for zone changes.
- 'draft-yorgos-dnsop-dry-run-dnssec' (dry-run DNSSEC) was presented by Yorgos Thessalonikefs. This draft introduces a "dry run" mechanism for deploying DNSSEC by using a special dry run DS record algorithm, allowing resolvers to validate without the risk of breaking resolution for non-supporting resolvers.
- 'draft-davies-internal-tld' ("A Top-level Domain for Private Use") was presented by Warren Kumari. Following ICANN's reservation of ".internal" for private use, this draft proposes adding it to the Special Use Domain Names registry (RFC 6761) to raise awareness and guide users who need a private namespace.
- 'draft-leon-dnsop-signaling-zone-owner-intend' ("Signaling Zone Owner Intend") was presented by Johan Stenstam. It describes mechanisms for zone owners to signal authorization of providers to serve and/or sign a zone using a new record type HSYNC. This is especially useful in a distributed multi-signer scenario with several independent providers.
DELEG WG
The Delegation (DELEG) working group is relatively new and chartered to define requirements for new DNS signaling mechanisms that allow parent zones to return additional delegation information about their children like alternative DNS transports (DoH, DoT, DoQ) and delegation aliasing (pointing to service providers for delegation details), which on a long term would replace the function of current NS resource records.
The working group’s focus was to reach a consensus around choosing one of the two alternative solutions. One specified in draft-wesplaap-deleg and draft-wesplaap-deleg-transport proposes a new parent-side resource record DELEG, which would be signed similarly like DS record currently and carry additional delegation information. The other one in draft-homburg-deleg-incremental-deleg takes an alternative approach of defining a parent-side subtree _deleg, where the delegation information would be delivered by new IDELEG resource record type.
Example delegation using DELEG and draft-wesplaap-deleg:
foo.example. IN DELEG 1 ns1.foo.example. ( ipv4hint=192.0.2.1 )
Example delegation using IDELEG and draft-homburg-deleg-incremental-deleg:
foo._deleg.example. IN IDELEG 1 ns1.foo.example. ( ipv4hint=192.0.2.1 )
The proponents of IDELEG highlighted possibly faster adoption due to the fact, that only resolver software would require an update whereas DELEG requires also change for authoritative server software. The opposite side highlighted maintaining the current structure of the DNS tree as a value which shall take precedence in the long run.
To gauge the prevailing view, a show of hands was taken to assess preferences between the two main proposals. The result, similarly, like during IETF 121, showed a majority in favor of DELEG proposal, with a notable minority in favor of the other one. The session concluded without a formal decision, indicating that further analysis, refinement, and discussion are necessary until the working group commits to a specific direction.
REGEXT WG
The REGEXT working group at IETF 122 held a session on Tuesday, March 18, 2025. The working group is mainly tasked with maintenance of EPP and RDAP protocols and their extensions.
There were no drafts ratified as RFCs since the last IETF meeting, however worth mentioning is 'draft-ietf-regext-epp-delete-bcp' which is now in the RFC editor queue. The draft aims to minimize unintended DNS resolution disruptions, hijacking scenarios and data inconsistencies by analyzing various practices related to deletion of host objects and recommending specific actions for EPP servers and clients.
The working group didn’t discuss any of the current adopted documents, there were two presentations of potential future work:
- ‘draft-brown-rdap-referrals’ (“Efficient RDAP Referrals”) was presented by Gavin Brown. The presentation highlighted the issue caused by full zone RDAP scans experienced by TLD RDAP services of potentially low cache rates (20-30%) of those RDAP queries causing great resource consumption, even though the clients are not interested about the whole payload but just the referral link to a registrar RDAP. The draft proposes a combination of HEAD method and a Link HTTP Header to limit the number of database lookups and the size of returned payloads in this use case.
- ‘draft-zzn-authcodesec’ ("Domain Transfer Authorization Using Cryptographic Signatures") was presented by Victor Zhou. This draft proposes extending EPP with public key authentication to make domain transfers faster and safer. In the second iteration of this draft the number of use-case scenarios was reduced for simplicity as well as the possibility for the losing registrar to still deny a transfer was added.
RPP WG
This new working group was chartered out of the discussions started in REGEXT working group during IETFs 118 through 120 and finally holding a BoF (Birds of Feather) session during IETF 121. The task of this working group is to work on an alternative provisioning protocol to EPP, which would be based on HTTP and JSON, following RESTful design principles.
The first session was filled with organizational topics about the working group process, but also some valuable presentations aimed to kick-off the work:
As a basis for compatibility with EPP James Gould presented preliminary results of “EPP Extensibility and Extension Analysis” and Pawel Kowalik presented CENTR Survey results on EPP Extensions.
In the further proceedings Maarten Wullink led the discussion on RPP requirements and Pawel Kowalik presented initial draft of work on RPP architecture.
Epilogue
IETF 122 was another successful gathering, for which the host and the sponsors deserve congratulations. There was once again a full and stimulating program, and ample opportunity for participants to network. The focus is firmly on the future, within both the IETF working groups and the IRTF working groups. And, because the future is exciting, IETF meetings are consistently stimulating and relevant.
The next IETF meeting is scheduled for 19 to 25 July 2025 in Madrid.
