[DNSOP] Client authentication for encrypted DNS — inte rest check

Aitor Santos <[email protected]> Fri, 10 Jul 2026 11:06:53 +0000
Newsgroups gmane.ietf.dnsop
Message-ID <AM8P189MB122002B1E02C38D8A97B23D9A8FD2@AM8P189MB1220.EURP189.PROD.OUTLOOK.COM>
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

[Irontec] <https://www.irontec.com>

Uribitarte Kalea, 6, 48001 Bilbo, Bizkaia

+ 34 944 048 182 <tel:%20+34%20944%20048%20182> — [email protected] <mailto:[email protected]> — www.irontec.com<https://www.irontec.com>

LinkedIn <https://es.linkedin.com/company/irontec-internet-y-sistemas-sobre-gnu-linux> — GitHub<https://github.com/irontec>

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]