- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 14 Nov 2012 10:59:18 -0800
- To: Eliot Lear <lear@cisco.com>
- Cc: "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 14 November 2012 04:21, Eliot Lear <lear@cisco.com> wrote: > 3. An as-of-yet undefined record that describes what services are running > over what protocols on a host. Think of it as the old WKS record on > steroids. I've actually spec'd out the record and written some code for > bind to test this idea, but it has its own set of costs: the first – and > biggest – is that it scales linearly with the number of services that are to > be advertised for a given host. Put another way: you could just see the > advice in an applicability statement "don't use me unless you really have > to." Just on this, it seems reasonable that the only necessary axis here is version. Having multiple records of the same type at the same node is already possible for SRV for load balancing and failover reasons; this would add one more reason: versioning. Two axes is already a lot, a third is bad enough. > Use of SRV of any form with regard to TLS would require a substantial change > in how we clients validate hostnames. I tell you from personal experience > that having a new SAN "Other" type is not an easy thing to ask of CAs. I don't see how you would conclude that. If you are seeking 'example.com', then that is what you should look for in the certificate. It doesn't matter what you had to query the DNS for to get an IP and port to get there. This happens all the time already with CNAME records - the browser still uses the *input* name to validate the certificate, not some intermediate gunk. --Martin
Received on Wednesday, 14 November 2012 18:59:46 UTC