Thanks Paul, I think you may have captured my concern, it's not the core BIND (or other) DNS server implementation I worry about, it's the web-interfaces from the likes of GoDaddy, the configuration with Kubernetes, and all the second-level of indirection stuff that makes we wonder whether implementing suitable functionality using PTR, CNAME, SRV, TXT, A and AAAA could do the job.
But I don't have a horse in this race, so I'm just acting as a questioning citizen. Cheers, Rick > -----Original Message----- > From: Paul Vixie [mailto:p...@redbarn.org] > Sent: 27 June 2024 02:58 > To: Mark Andrews > Cc: Rick Taylor; Scott Johnson; Erik Kline; dnsop; sburleig...@gmail.com; > d...@ietf.org > Subject: Re: [DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle > Protocol RFC9171 > > > > Mark Andrews wrote on 2024-06-26 16:02: > > > > > >> ... > > > > Adding a new RRTYPE requires zero infrastructure upgrades. It’s a database > entry at IANA. Every DNS server on the planet should handle these > transparently. That was required by RFC 1034 and RFC 1035. You can even > add them to zones before the parsing software is updated using unknown type > representation (RFC 3597) which was one thing that was missing from RFC > 1035 that would have made adding new types easier. Nameservers and stub > resolvers were always required to treat unknown records as opaque objects. > > in terms of dns infrastructure this is true. while the open source > implementations are fastest to adopt and deploy new rr types, even > proprietary dns implementations are rarely more than a year behind. > > but there's infrastructural middleware for which this is not true. > registries and registrars and things like "webmin" are usually five to > ten years behind on adding support for new rr types. thus, the SPF > debacle in which the application had to back off and go with TXT. and > thus the tendency today to use an existing rr type and a well-known > subdomain beginning with an "_" as a way to deploy more or less > immediately. > > dns itself is not the problem. but there is a real problem here about > which the dns technical community can do precisely nothing. > > > This doesn’t mean that there weren’t mis-implementations of the standards > which failed to handle unknown types correctly but there have been 78 types > added since RFC 1034 and RFC 1035. That’s 2-3 per year. Nameserver > developers know how to add new record types quickly. > > agreed, but that's not the point being argued. > > -- > P Vixie _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org