On 04/11/2018 06:53, Paul Vixie wrote:

the arguments against SRV in that document are unsupported and wrong.

They are something of a straw man, yes.

We did hear unequivocally at the side meeting in Montreal that SRV is not acceptable to the HTTP folks, though, for the broad reasons mentioned in my draft.

SRV responses include additional data.

AFAIK, BIND does not currently do this. That said, MarkA has a patch that supports it, so we do know it's possible.

i think that makes HTTP as fast in terms of round trips as SRV is.

The intent is to make it as fast as CNAME, and faster than SRV currently is.

so use "0" for the port number, and don't include more than one SRV RR.

If the record supports it, people will want to use it, and complain when they can't.

so just keep using non-DNS solutions.

No argument from me, I've always strongly believed that if load-balancing and/or failover are the question then DNS is not the answer.

there's no benefit to accompany the cost of this proposal compared to re-use of existing code points which are already broadly implemented.

There appear to be political benefits, though. Code points are cheap these days, and the point of this document is to try to introduce something where the DNS folk and the HTTP folks can "meet in the middle" with a mutually acceptable solution.

the HTTP folks are obviously not interested in round trips, anyway:

Sometimes the content folk appear less interested in this than the UI folk.


DNSOP mailing list

Reply via email to