[Last-Call] Re: Last Call: <draft-hardaker-dns-wgs-at-ietf-06.txt> (Community considerations on DNS WG structures at IETF) to Historic RFC

[Phillip Hallam-Baker <[e-mail]>]

I was not aware of this, I have quite a few comments.

The problem I see with DNS is that we have a resource that should be the
unified discovery mechanism every Internet application protocol uses but
for various reasons, that has not taken off. The problem with the DNS is
that it is a large and highly critical infrastructure whose architecture
makes it rather vulnerable to abuse and misconfiguration. Legitimate use
turns out to be a rounding error on the load in many parts of the
infrastructure. As a result, there is a risk of being over-protective of it.

I am not sure that extensions to the DNS protocol are actually desirable at
this point. Or at any rate, the notion that we should be minting new DNS
RRs to support new applications using the DNS is a mistaken approach.
Rather than inventing new ways to do things in DNS, we should be looking
for more general approaches to applying DNS Service Discovery [RFC6763].

I am really not sure what the proposed DNSDispatch ends up doing other than
telling people to use DNS Service Discovery or not do something at all.


Similarly, the original DNS protocol has the assumption that the
client-recursive and recursive-authoritative protocols are the same. This
has since been changed with new client protocols such as DNS over HTTP, DNS
over TLS and DNS over QUIC. We have changed the transport but the semantics
of the protocol are still constrained by that original architecture and an
early implementation choice that limits DNS requests to a single query.

There is no need for the client-recursive protocol to be so constrained.
Instead of making multiple queries, a client could make a QUIC request of
the form 'I am on network AS_X and want to connect to example.com using
protocol FOOP version 3, 4 or 5 via IP4 of IPv6' and get back an IP address
and service description including the security enhancements and trust
anchors to use with an optional DNSSEC package providing proof.

This need not mean a change to the negotiation process or the
recursive-authoritative protocol, just a change to where it takes place. It
would however open up the possibility of future protocol options where an
authoritative for a CDN has a DNS that offers to respond to the higher
level query directly.


On Fri, Apr 10, 2026 at 12:21 PM The IESG <[e-mail]> wrote:

>
> The IESG has received a request from an individual submitter to consider
> the
> following document: - 'Community considerations on DNS WG structures at
> IETF'
>   <draft-hardaker-dns-wgs-at-ietf-06.txt> as Historic RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2026-05-08. Exceptionally, comments
> may
> be sent to [e-mail] instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    There has been an increasing level of discussion within the IETF
>    about the best Working Group (WG) structures for handling the wide
>    array of DNS work being conducted within the IETF.  As part of
>    community consultation, a team coordinated by Wes Hardaker was asked
>    to gather information from the community at large through e-mail,
>    hallway discussions, and meetings and create a small team to discuss
>    potential structural changes to be shared with the community.  This
>    document is the result of that effort.
>
>    The outcome of the consultation is retained for historic reference.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-hardaker-dns-wgs-at-ietf/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>