[DNSOP] Re: I-D Announcement: draft-teppo-corporate-authenticated-dns-02 - Authenticated DNS Resolution for Enterprise

[Terry Teppo <[e-mail]>]

Ted,

Thanks.  This is what is really is all about:   "No more anonymous query on corporate networks"

Basically, any person on your network that gets an IP address can query DNS via Anonymous query the backbone of the Internet.  Because unlike the Internet internal corporate networks need a way to restrict who can query what records.

There are ways outside of this draft but they more complex than people realize and they open same problem in all reality.  So what do companies do.  Normally, they do not make the DNS records.  They rely on documentation and other tooling like NMS with names not in DNS.  So sometimes it the local host of device sometimes not the local host name that in the management protocols. It can get confusing.

All this was fine and dandy with Ipv4 because we could all memory them, to an extent.   But with IPv6 the address just become not possible to memorize it all.  So we have this disjointed solution the NMS has a name that cant be pinged.  If you look at the IPAM export or the documentation or the address in the NMS you ok to find the address.  But otherwise your screwed.

I never forget the first  time failed PEN test because this problem it was way back in early 2000's.  "We can map your entire network infrastructure with nothing more the DNS lookup tool."  Today we don't make these entries because of the same anonymous query that is required on the Internet.  We cannot get rid on that on the Internet anonymous query has to exist there.  But on the corporate side its a death sentence to DNS.  The rule is never put anything in DNS you don't want everyone to know.  We hide them behind firewall and special segmentations all kind of things to compensate for the fact that anonymous query in corporate private network environments is bad.

This draft says here is a way, we can have resolvable names to devices and not create security problems.  Yet allow the Internet to stay exactly as it is.

Eaxmple:
You have a 500 routers all ipv6 address.  Naming conversion become in pretty handy to help figure out what's going on.   What the IP address on the router in phx, no one really knows anymore.  Because we cannot memorize all the Ipv6 address and constantly have access to an NMS to find the IP.   Imagine the ssh or PKI key on the router actually resolving to name that can be looked up.  Thank will never happen the way it is now.  Everything  else example DHCP itself now have forms of authentication.  Everything around query have forms authentication.  Just not the query.

The draft simply says this is how we get to have names on devices that resolve via DNS for looked up without showing you entire infrastructure to everyone with IP address.

Sorry every this is long Ted.  I been working this for a very long time now.  I kind emotional about it, because for years I was not going to submit.  Everytime I wrote it I could never find all the correct wording refences and citings.  Last Friday was the final kicker, when when talking a local network admin about it and they said "you really should submit it, its logical."

So there you go Ted.  Sure there are run on sentences etc.  It is very emotional which is not professional, but I think that what you asked for right.  I just dumped I not sure what I just typed make sence but here you go.  Please don't get mad.

Regards,

Terry Teppo




________________________________
From: Ted Lemon <[e-mail]>
Sent: Thursday, July 30, 2026 11:19 AM
To: Terry Teppo <[e-mail]>
Cc: Ondřej Surý <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [DNSOP] I-D Announcement: draft-teppo-corporate-authenticated-dns-02 - Authenticated DNS Resolution for Enterprise

Terry, I'm just a random participant here, so take this with a grain of salt, but I'm not going to read the giant pile of slop you just dumped on us. If you want people to pay attention to what you have to say, be brief and succinct. Don't send us the output of an LLM—even if you use the LLM, read its output yourself and send us the points you consider important, in your own words. If these feels like not a good use of your time, that's fine, but that should tell you something important. Say there are 100 people reading this mailing list (a made up number). If it's 1x not a good use of time for you to read and summarize, it's 100x not a good use of time for us to read and try to glean from the slop what is actually useful, because you have context we don't have, so it's even harder for us than it is for you.

On Jul 30, 2026, at 18:00, Terry Teppo <[e-mail]> wrote:

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ý <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 30, 2026 5:09 AM
To: Terry Teppo <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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)
[e-mail]<mailto:[e-mail]>

A gentle nudge is always appreciated if I take a little longer to reply.

> On 29. 7. 2026, at 20:09, Terry Teppo <[e-mail]<mailto:[e-mail]>> 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 -- [e-mail]<mailto:[e-mail]>
> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


_______________________________________________
DNSOP mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>