[Sorry, got Cullens' out of thread, did not realize there was more debate
since, replying to a number of different posters here]
I really do not like the idea of a new RR unless it can be shown that SRV is
not sufficient.
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(_at_)example(_dot_)com 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf