Primary logo
DNSRF Corporate Logo - words and line shorter version
{item._type | case 'page' 'Web page' 'blog/blog' publication 'adnewsfeed/news' 'News'}  | {category.title}
{item.publishDate | date 'DD MMM YYYY' | append ': '}


I'm not pulling your LEG; an update

Media current

Not long ago, I described DELEG, a proposed protocol to change some of the signaling in the DNS. At the recent IETF 119 in Brisbane, Australia, there was a Birds of a Feather session for DELEG. Along with the interim meeting I reported on earlier, the BoF showed substantial interest in the topic — probably enough to form a new working group separate from DNSOP.

About the BoF

Roy Arends from ICANN began the proceedings by providing a high-level description of the goals for improving signalling information about delegations. During that presentation, Roy indicated two critical requirements for any new protocol: cryptographic security against downgrade attacks and backward compatibility. Manu Bretelle gave a short presentation about how DELEG would work in a setting where secure transports (e.g. DoH) were used for the DNS.

Ben Schwartz from Meta gave a quick talk about how RFC9539 was insufficient to provide real security for the DNS. Finally, there was a presentation on the basic draft that started the DELEG discussion.

After the BoF

One of the Operations Area directors agreed to create a mailing list for further discussions around DELEG. Specifically, the working group needs a revised charter. The details for the mailing list can be found here. A copy of the current draft of the proposed charter is here.

The draft charter has four deliverables:

  • A document listing the requirements for a new signalling mechanism allowing parents to return additional information when communicating about a delegated child. This is expected to be published as an informational RFC.
  • A specification defining the new delegation information distribution mechanism. The WG will carry out an operational impact assessment and include corresponding operational and deployment considerations sections in the specification. The specification will include a concept of operations that describes how both current and future systems will interact in an Internet-wide interoperable way. This is expected to be published as a standards-track RFC.
  • A specification for how to use the new delegation information to perform aliasing of delegation information. This is expected to be published as a standards-track RFC.
  • A specification for facilitating the use of additional transports for DNS. This is expected to be published as a standards-track RFC.

The next steps for DELEG are continuing the discussion on the new “DD” mailing list and submitting a charter to the IESG for a proposed new working group. The mailing list is already in place, and discussions on it (while mainly on the charter so far) have been active.

Thank you for signing up for our mailing list.
Unfortunately we could not sign you up for our mailing list at this time. Please try again later

Latest posts here