On Tue, Nov 22, 2016 at 2:42 PM, Jared Mauch <jared@xxxxxxxxxxxxxxx> wrote:
(Not going to address things where I perhaps disagree, but focus on areas of concern …)
> On Nov 22, 2016, at 10:04 AM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
>
> I am asking here as there seems to be a disagreement in HTTP land and DNS land.
>
> Here are the constraints as I see them:
>
> 0) For any discovery mechanism to be viable, it must work in 100% of cases. That includes IPv4, IPv6 and either with NAT.
I think must be sufficiently robust, where it’s defined as 98+%. Studies on the operational networks seem to indicate this is the threshold is in the 95-99% range. Saying 100% is a goal, but perhaps unrealistic.
Let us remind ourselves of what the purpose of SRV records originally was. They were developed to improve reliability by enabling fault tolerance.
In the commercial world, systems have been expected to be four nines reliable as a matter of course for a decade. That isn't even state of the art, it is baseline. There are plenty of services built for 99.9999% up time. And that is actually essential because if you have a system that can fail at multiple points, the errors start to accumulate and pretty soon you have a system that is visibly unreliable.
Any Web Service discovery architecture has to be 100% compatible with the legacy infrastructure. Because if it isn't it is going to reduce reliability, not increase it.
Building in SRV means that the cost of achieving 99.99% uptime is reduced. But reducing the SLA to 98% would be vastly cheaper.
On Tue, Nov 22, 2016 at 5:38 PM, Mark Andrews <marka@xxxxxxx> wrote:
In message <CAMm+LwgtJuLdL_RKJNSVNGODGj8D25nfj0jkhnBLFS=a aXG+rA@xxxxxxxxxxxxxx >
, Phillip Hallam-Baker writes:
> 1) Attempting to introduce new DNS records is a slow process. For practical
> purposes, any discovery mechanism that requires more than SRV + TXT is not
> going to be widely used.
Absolute total garbage.
Introducing a new DNS record isn't slow. It take a couple of weeks.
Really. Thats how long it takes to allocate a code point.
RFC 1034 compliant recursive servers and resolver libraries should
handle it the moment you start to use it.
Well until you can persuade the ISPs to provide RFC1034 compliant interfaces in their Web Configuration tools, the majority of sites will not be able to use a new record.
Allocating records isn't the problem. The Internet is defined by running code, not allocated code points. Only a minority of network admins actually edit zone files these days.
CAA was specified several years ago now. We are only just getting to the point where it is viable.
It isn't my job to get your specifications deployed by having my systems break unless people upgrade. It isn't anyone's job.
Besides which, we already have an RFC that says use SRV+TXT - RFC 6763.