[Sorry, got Cullens' out of thread, did not realize there was more debate since, replying to a number of different posters here]
There are still issues deploying new RRs. Windows DNS does not provide an administrator interface for new RRs. Plugging them into BIND is not exactly simple either. At root DNS remains a binary protocol and that means that no DNS server is going to have decent support for unknown RRs until it gets an update.
The mere ability to dynamic update a new RR into a server is not the same thing as being able to use that RR in a production environment. You have to be able to update the RR using the same tools you use for the rest of the zone.
What really worries me is that there are people who are busy inventing new discovery mechanisms for Internet protocols via HTTP who are completely ignoring the existing DNS infrastructure.
For example, why does OpenID not just use user@xxxxxxxxxxx as the identifier for a user and SRV to discover the authentication server that can give an answer for that domain? It would be job done five years ago.
At the moment OpenID has a discovery mechanism via HTTP and a proprietary lookup scheme via XRI that isn't proprietary really because the people who control the rights tell us they trust themselves.
A proposal for a new RR in that debate is the last thing we need. It suggests that the IETF does not understand how to do service discovery and opens up the field for XRI.
For caldav over HTTP, SRV works fine.
For finding the right protocol amongst a number of options (e.g. finding the right authentication protocol from Kerberos, SAML, OpenID, KitchenSink, etc.) we need something additional. I can see that a new RR could add value there if it provided a list of protocols on offer, protocol options, version numbers etc.
In other words a Service DESCRIPTION record.
I think that that would be a very valuable thing for the IETF to work on. The functionality I need is not considered in NAPTR.
As for the interaction with DNSSEC, I think it is double ended. At the moment DNSSEC has no particular function. If we only implement what is described to date there is nothing that DNSSEC can do that is not already done better by the existing infrastructure of SSL and CA issued Domain Validated X.509 certs.
Now consider what would happen if we added the ability to use the DNS to distribute statements of the form 'this SMTP server always offers STARTTLS", "This Caldev server always offers SSL"
Suddenly DNSSEC not only has a point, it has a point that cannot be supported using any other infrastructure.
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf