Stéphane BortzmeyerIt seems we have now the mandatory very-long-thread-with-a-lot-of-rant on the #IETF125 mailing list about https://datatracker.ietf.org/doc/draft-rescorla-anonymous-network/ and the possibility that it prevents us going to China (and may be other countries).
After a lively discussion on solutions to depend less on the #DNS root (obviously no consensus, despite a tendency to deny there is a problem to solve), another hot question: DNS #censorship and the need to be transparent about it. https://datatracker.ietf.org/doc/draft-nottingham-dnsop-censorship-transparency/
What to display to the end user? (Not anything got from the resolver: security issues.) Lumen Database entry?
DNS Filtering Transparency
[I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This specification allows more specific details of filtering incidents to be conveyed. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mnot/public-resolver-errors.
And now, at last, AI in the dnsop working group. "DNS for AI Discovery"
https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/ https://datatracker.ietf.org/doc/draft-mozley-aidiscovery/ (5 or 6 very similar drafts, often from China)
_agents.ietf.org soon! More seriously, this is a limited (and rightly so) proposal to use DNS just for naming AI agents.
DNS for AI Discovery
This document specifies a method for utilizing the Domain Name System (DNS) to facilitate scalable and interoperable discovery between AI agents. The proposed mechanism, referred to as "DNS AI agent Discovery (DNS-AID)", defines a structured DNS namespace and record usage model to support metadata exchange and capability advertisement. This will allow organisations to publish information about their AI agents on the Internet or internal networks using a well-known label within the organisation's own DNS namespace. This document does not define how the published agent information is accessed or the exact structure of that information. Instead, it specifies a mechanism for indicating which access protocol should be used and what format the agent information will be provided in. This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values.
Global Chat@bortzmeyer Using DNS for agent naming is a pragmatic choice — the infrastructure is already everywhere and trust chains (DNSSEC) are understood.
What is interesting is how this compares to the file-based approaches emerging in parallel: agents.txt (like robots.txt for agents) and AGENTS.md (convention from Pydantic AI).
DNS solves naming. The file-based approaches solve capability description. Neither alone handles trust verification. The layering question is wide open.
bert hubert 🇺🇦🇪🇺🇺🇦@bortzmeyer This, amazingly, is not the first time this has happened! https://berthub.eu/articles/posts/history-of-powerdns-2003-2013/#:~:text=A%20bit%2Dby%2Dbit%20comparison
History of PowerDNS: 2003-2013 - Bert Hubert's writings
This is part two of the PowerDNS history as I recall it. As noted in part one, some of this stuff is rather old, and it is entirely possible I am misremembering things. Please do let me know if you find any important omissions or mistakes! At the end of 2002, beginning of 2003, PowerDNS as a going concern was gone. There were no more employees, there were no paying customers.
@bert_hubert Joe Abley said, indeed, that there are at least three documented cases, just for CNAME/A+AAAA order (see his slides).
Rock'n'Roll_φapy 🔻