[DNSOP] Re: Client authentication for encrypted DNS — interest check

Hi Aitor,

Tommy's memory of the details are no doubt better than mine, although I seem to remember the open question at the time was one of appropriate venue, not approach.

Let's talk off-list as you suggested.

Joe

On 10 Jul 2026, at 14:44, Aitor Santos <[email protected]> wrote:



Hi, Joe:

Thanks for the suggestion. I’ve reviewed the “draft-jaked-cared,” and it’s clearly the closest existing work to what I have in mind. I see that it expired without being adopted by the working group; do you have any idea what was missing for it to move forward,
or if there was interest at the time that simply didn’t materialize?

My current approach is slightly different: instead of recommendations, my goal is to develop a problem statement and a requirements document that can serve as the basis for a subsequent draft of solutions. If you’re interested in taking a look, I’d be happy
to share a pre-presentation version.

Best regards,

Aitor Santos

Técnico SOC

https://www.irontec.com

Uribitarte Kalea, 6, 48001 Bilbo, Bizkaia

+ 34 944 048 182 — [email protected] — www.irontec.com

LinkedIn — GitHub

Encontrará información detallada sobre el tratamiento de sus datos personales en www.irontec.com

----------

De: Joe Abley <[email protected]>

Enviado: viernes, 10 de julio de 2026 15:09

Para: Aitor Santos <[email protected]>

Cc: [email protected] <[email protected]>; Tommy Jensen <[email protected]>

Asunto: Re: [DNSOP] Client authentication for encrypted DNS — interest check

Hi Aitor,

You may want to take a look at this (expired but recent) draft which is an attempt to answer similar questions.

https://datatracker.ietf.org/doc/draft-jaked-cared/

I agree these are questions worth answering.

Joe

On 10 Jul 2026, at 13:24, Aitor Santos <[email protected]> wrote:



Hi all,

I'm working on a draft addressing a gap in the current encrypted DNS ecosystem: while DoH [RFC8484], DoT [RFC7858], and DoQ [RFC9250] protect DNS queries from on-path observers, none of them define a standard mechanism for a resolver to authenticate its clients.

This matters in practice for private and restricted resolvers — self-hosted instances, enterprise deployments, ISP subscription services, and parental control resolvers — where the operator has a legitimate need to limit access to authorized clients only. Today
each deployment invents its own approach (token in the URL, IP allowlist, custom headers), with no interoperability.

The draft (draft-santos-dnsop-encrypted-dns-client-auth) describes the problem space, the requirements any solution must satisfy, and the constraints each transport imposes on an authentication mechanism.

Before I submit the -00, I wanted to check:

• Is there existing or ongoing work in this area I should be aware of?

• Is there appetite in the WG for a problem statement document, or would a solutions-oriented draft be more appropriate?

Happy to share a pre-submission version off-list if anyone wants to take a look.

Thanks,

Aitor Santos

Técnico SOC

https://www.irontec.com

Uribitarte Kalea, 6, 48001 Bilbo, Bizkaia

+ 34 944 048 182 — [email protected] — www.irontec.com

LinkedIn — GitHub

Encontrará información detallada sobre el tratamiento de sus datos personales en www.irontec.com

_______________________________________________

DNSOP mailing list -- [email protected]

To unsubscribe send an email to [email protected]

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]