Ben, I reviewed CARED, and as I understand it, the draft focuses on endpoint authentication for encrypted DNS - specifically mutual authentication over TLS, where client and server certificates establish trust between the resolver and the endpoint. They were close to the problem space, but they did not go far enough down. First, I also do not believe every DNS query needs to be encrypted, and CARED’s approach stays strictly within TLS-based transports. That begins to overlap with DNSSEC territory, which I intentionally avoided. I mentioned CARED informally in my draft, but I did not cite it because the document expired and was never adopted. I can add it as an informative reference if needed. My draft is about the DNS query itself, not the transport. It authenticates the DNS message and binds identity to the query, enabling per‑query authorization and policy enforcement. For example, an internal resolver could allow queries for tucson.entS00.rt01.phx.network.example.com only from members of a specific network group. This is query‑level authorization, not endpoint‑level authentication. Hope this helps.
Regards, Terry Teppo, IT is what we do because IT is fun. ________________________________ From: Ben Schwartz <[email protected]> Sent: Thursday, July 30, 2026 7:08 AM To: Ondřej Surý <[email protected]> Cc: Terry Teppo <[email protected]>; [email protected] <[email protected]> Subject: Re: [DNSOP] Re: I-D Announcement: draft-teppo-corporate-authenticated-dns-02 - Authenticated DNS Resolution for Enterprise This sounds like it's essentially a repeat of draft-tjjk-cared. I recommend starting by talking to the authors of that draft and reviewing some of the discussions about it. --Ben Schwartz On Thu, Jul 30, 2026 at 6:11 AM Ondřej Surý <[email protected]> wrote: > > > > Hi, > > the correct URL is: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-teppo-corporate-authenticated-dns%2F__%3B!!Bt8RZUm9aw!5bBdWkr4CjGLqRpUT-ZTxlNe8pZk-dM65JQChqp3IPUlO2tLnFyHopDs9SBgGVmkFby90O81gA%24&data=05%7C02%7C%7Cac6a20916dba424d229008deee334f99%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639210101335169096%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jYc%2F%2F2q5bRsKom4kT6HuvHuDhMFDC3o8NsA26xXNz1g%3D&reserved=0<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-teppo-corporate-authenticated-dns/__;!!Bt8RZUm9aw!5bBdWkr4CjGLqRpUT-ZTxlNe8pZk-dM65JQChqp3IPUlO2tLnFyHopDs9SBgGVmkFby90O81gA$> > > But I am going to ask a different question: How much of the draft has been > generated using > tools and not written by yourself? > > IETF and dnsop WG is now in process of drafting a policy, but I am 100% sure > that we will > require a full transparency about the tools used to generate the draft > (similar to what other > publishers currently have). > > Ondrej > -- > Ondřej Surý (He/Him) > [email protected] > > A gentle nudge is always appreciated if I take a little longer to reply. > > > On 29. 7. 2026, at 20:09, Terry Teppo <[email protected]> wrote: > > > > Hello DNSOP, > > > > I have submitted an Internet-Draft titled "Authenticated DNS Resolution > > (ADR) for Enterprise DNS" as an independent submission: > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-teppo-corporate-authenticated-dns-00%2F__%3B!!Bt8RZUm9aw!5bBdWkr4CjGLqRpUT-ZTxlNe8pZk-dM65JQChqp3IPUlO2tLnFyHopDs9SBgGVmkFbzxUj7wYA%24&data=05%7C02%7C%7Cac6a20916dba424d229008deee334f99%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639210101335273649%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Z3e6CBLSjphJdojNg%2F4xVaUKLzCd%2FBuVSm82yhRlsWM%3D&reserved=0<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-teppo-corporate-authenticated-dns-00/__;!!Bt8RZUm9aw!5bBdWkr4CjGLqRpUT-ZTxlNe8pZk-dM65JQChqp3IPUlO2tLnFyHopDs9SBgGVmkFbzxUj7wYA$> > > > > ADR proposes query-plane RBAC for enterprise DNS resolvers — controlling > > who may resolve DNS records at query time, bound to authenticated machine > > and user identity via Kerberos, X.509 client certificates, or OAuth/OIDC > > tokens. > > > > The motivation is a gap that existing mechanisms do not address: > > enterprises already authenticate DNS writes (RFC 2136, TSIG), restrict zone > > transfers, and block external queries, but reads remain open to any > > authenticated principal with network access to a resolver. A domain-joined > > workstation operated by a helpdesk technician can resolve router, firewall, > > and WAN transit records with no credentials and no audit trail. ADR > > completes the access control model enterprises have already been building > > by applying RBAC at query time. > > > > Key points: > > - ADR carries identity in the transport layer (Kerberos, mTLS, DoH+OIDC) > > and does not modify DNS message format, opcodes, EDNS options, or resource > > record types > > - Scoped strictly to enterprise private namespaces; no impact on Internet > > DNS, DNSSEC, or public resolvers > > - Introduces AUTH-NXDOMAIN to distinguish "record does not exist" from > > "record exists but you lack permission" > > - Fully compatible with DNSSEC; ADR resolvers validate before returning > > answers > > - Supports incremental deployment alongside legacy unauthenticated DNS > > > > I searched the datatracker and found no prior drafts addressing query-plane > > DNS authorization. The draft includes a prior art section covering DNSSEC, > > AD-integrated DNS, split-horizon, DoT/DoH, mDNS, RFC 2136, TSIG, SIG(0), > > DNS Cookies, RPZ, DNS ACLs, and 802.1X/NAC. > > > > I would welcome feedback on technical gaps, pointers to related work I may > > have missed, or interoperability concerns. I am not requesting WG adoption > > at this stage but would welcome guidance if the WG has interest. > > > > Thank you for your time. > > _______________________________________________ > > 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]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
