Hi Ondrej, Thanks for the question.
Short answer: Yes. The core concept, problem statement, architecture, and all technical decisions in the draft are my work and reflect my hands‑on experience. I began diagramming and developing this idea in 2023 after repeatedly observing DNS not being used because of topology exposure issues during penetration tests and security reasons; my first notable encounter with this issue was during a penetration test in the early 2000's. I was talking with a network admin at a community event last Friday; wherein, they confirmed the same reality: internal DNS naming is avoided for fear of exposing network topology, and teams use alternative tooling for operational needs like ITIL inventory reporting and spreadsheets. These are the types of findings over decades directly informed the problem framing and proposed design. I used many AI‑assisted tools during drafting for several purposes, I did not track what AI did what sentence as it aways a cross multiples, yet I want to be transparent about what they did and what I did: 1) **Prior‑art discovery and literature search** - I used AI‑assisted literature search to surface prior art and RFC references. The tool(s) surfaced the vast majority of items in the prior‑art list (roughly 99%); I reviewed, curated, and edited that list and added or removed items based on my domain knowledge. Without that assistance the prior‑art list would not be as complete as it is today. 2) **Reference verification and RFC validation support** - I used multiple AI tools to help assemble references and citations, 99% these would not exist without them, - I also used IETF authoring/validation tooling (including the authoring tools and the validator checks). I iterated the draft until it passed validation, spending several days (almost a month in total) addressing validator flags and ensuring the draft met RFC formatting and reference requirements. I sure there are typos there has to be. 3) **Wording, structure, and editorial assistance** - I provided the technical narrative, diagrams, and architecture. AI assistance helped translate that narrative into RFC structure and concise wording flagging when I was not precise enough. Every AI suggestion was reviewed; I removed or modified suggestions as I felt appropriate to ensured technical accuracy. 4) **Sanity checks / reality checks** - I used multiple AI‑assisted tools as independent sanity checks to confirm references, surface missing items, and flag potential overlaps with existing work. These tools acted as fast search and verification aids; the final decisions about inclusion, exclusion, and interpretation were made by me. 5) **Fundamental use of AI** - No one AI in particular created entire sections alone. I always feed everything an AI said to the other AI's and asked if it with was truthful and correct multiple times. They do not agree all time. Thus, I had to figure out what to actually say in the end; I may have made mistakes in doing this but it is what it is. I may have taken the final sentence from an AI but everything went through multiples. They helped me with grammar, sentence structure, spelling and what does my sentence actually say or mean. They helped organize to make sure I did not miss sections. If all 3 tools said I need a section, I would debate with myself should it be there. Example all three AI's want multiple sections on audit logs, but I considered that operational not protocol. I left some mentions of the audit logging in, so people understand it should exist, but removed all the sections that describe it in detail. I could remove all mention of audit logging. There are some MUST I not 100% sure about, and very open to debate on them. Example: See this is what it looks like if I not have help grammar. One more note on tooling: To reiterate, I used several different AI tools and did not keep a per‑suggestion audit mapping each output to a specific tool, so I cannot precisely attribute every suggested edit or reference to a particular tool after the fact. All surfaced items were reviewed and curated by the me. If the WG requires a precise mapping or the names of the specific tools used, I will provide that in the disclosure. **Technical scope note (brief):** this design enforces authentication at the DNS query level within a managed trust domain by binding client identity to queries and operating resolvers under enterprise control. Because it requires per‑client credentials, a managed identity fabric, and tight operational control over caching and recursion, it is intended for enterprise/internal deployments and not for the public Internet. If the WG prefers a formal disclosure, I will add a “Tools and Contributions” section to the draft that includes: - a per‑section provenance table indicating where AI assistance was used and who reviewed each section, and - an annotated list of references showing which items were surfaced by the AI's and which were added or removed by the author. I can post an updated draft with that disclosure by **EOD Tuesday, 2026‑08‑14** (or sooner if the WG prefers). If the WG requires the names of the specific tools used, I will provide them in the disclosure; otherwise I’ve described the role the tools played and the human review process. If you or the WG would like the detailed list of references the AI surfaced (or a section‑by‑section breakdown), I can provide that as well. Regards, Terry Teppo IT is what we do because IT is fun. ________________________________ From: Ondřej Surý <[email protected]> Sent: Thursday, July 30, 2026 5:09 AM To: Terry Teppo <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [DNSOP] I-D Announcement: draft-teppo-corporate-authenticated-dns-02 - Authenticated DNS Resolution for Enterprise Hi, the correct URL is: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-teppo-corporate-authenticated-dns%2F&data=05%7C02%7C%7Cdcee0ed3424844e0f7e808deee22bb15%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639210030101080871%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nMJqZv5QHducGv8%2Bcya%2FkgLXywRDNdlFyS%2FUhf%2FKcEQ%3D&reserved=0<https://datatracker.ietf.org/doc/draft-teppo-corporate-authenticated-dns/> 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%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-teppo-corporate-authenticated-dns-00%2F&data=05%7C02%7C%7Cdcee0ed3424844e0f7e808deee22bb15%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639210030101124525%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hChttlSz6ojuMGwxscENG8Y3B1R08AtLywccSTwwC5o%3D&reserved=0<https://datatracker.ietf.org/doc/draft-teppo-corporate-authenticated-dns-00/> > > 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]
