[DNSOP] Re: [dtn] Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

[Rick Taylor <[e-mail]>]

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:[e-mail]]
> Sent: 27 June 2024 02:58
> To: Mark Andrews
> Cc: Rick Taylor; Scott Johnson; Erik Kline; dnsop; [e-mail];
> [e-mail]
> 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