Ted,
Thanks. This is what is really is all about: "No more anonymous query
on corporate networks."
I got carried away there trying to explain everything all at once. The
core point is the first sentence. "No more anonymous query on corporate
networks."
------------------------------------------------------------------------
*From:* Terry Teppo <[email protected]>
*Sent:* Thursday, July 30, 2026 1:52 PM
*To:* Ted Lemon <[email protected]>
*Cc:* Ondřej Surý <[email protected]>; [email protected] <[email protected]>
*Subject:* Re: [DNSOP] I-D Announcement: draft-teppo-corporate-
authenticated-dns-02 - Authenticated DNS Resolution for Enterprise
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 <[email protected]>
*Sent:* Thursday, July 30, 2026 11:19 AM
*To:* Terry Teppo <[email protected]>
*Cc:* Ondřej Surý <[email protected]>; [email protected] <[email protected]>
*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 <[email protected]>
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ý <[email protected] <mailto:[email protected]>>
*Sent:* Thursday, July 30, 2026 5:09 AM
*To:* Terry Teppo <[email protected]
<mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]> <[email protected]
<mailto:[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] <mailto:[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]
<mailto:[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] <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
DNSOP mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected] <mailto:dnsop-
[email protected]>
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
