Hi Aitor,
You may want to take a look at this (expired but recent) draft which is an attempt to answer similar questions.
I agree these are questions worth answering.
Joe
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,
_______________________________________________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]
