On Sun, Jul 24, 2011 at 03:49:33PM -1000, David Conrad wrote: > [I haven't been following hybi and haven't read the draft, but as this is posted to the ietf list and there are a bunch of assertions here about the DNS I consider ... odd, I thought I'd chime in] > > On Jul 24, 2011, at 8:59 AM, Willy Tarreau wrote: > > A lost UDP packet is not retransmitted nor signaled as lost, so the browser has to retry. > > This sounds like a seriously broken resolver. All resolvers I'm aware of have timeouts and retry if no response is received within the timeout. A resolver that gives up after a first time out is equivalent to a TCP stack that doesn't retransmit a SYN. A bug should be filed with the vendor. What are you saying ? Your browser embeds the resolved as a library, so when I'm saying that "the browser has to retry", I mean the resolver part of the browser has to retry. > On Jul 24, 2011, at 9:16 AM, Willy Tarreau wrote: > > CNAME is the exact equivalent of SRV. > > No. According to the RFCs and most implementations, you can't have CNAME with other data (A, MX, SOA, NS, etc). With SRV, you can have anything at the same label. This does not change anything, because the CNAME is on the hostname while the SRV is on the service name, so there is nothing wrong with having both. > On Jul 24, 2011, at 9:29 AM, Willy Tarreau wrote: > > DNS provides geolocation and proposes you the closest working datacenter. > > >> Anyhow, don't forget that SRV is not just for failover, but also for load-balancing > > > This is already addressed by DNS round robin and used by a lot of sites. > > Only at the grossest level. What a client get back from a query depends on who has queried the same cache and authoritative server and what policy the authoritative server has for returning answers. In reality, 'round robin' is 'random'. Yes but in practice, this randomness offers very smooth distribution. > This is qualitatively different than the prioritization offered by SRV. Indeed this is different, but this does not mean there is a huge need for the minor improvements provided by SRV in this context. I'm not saying that SRV is useless but that it adds little value to HTTP and even smaller to WS without HTTP, and comes at a non-zero cost, whatever people are saying. I'm also certain that if a new record were to be invented (eg: report the server's load in real time), there would be major proponents to make it mandatory for everything because it would be what would save the world from an upcoming disaster. I'm convinced we can find good use cases for SRV combined with either HTTP or WS once we admit it is optional and the user controls this option. Try to imagine what you could do if you knew that 50% of your visitors would consider your SRV records. Maybe you could use them to progressively test service updates. You could possibly get a better distribution, or serve a maintenance page to some of them during maintenance operations instead of leaving them in the dark. You have to think what the benefit can be for the user to enable the option, not how to push it down his throat. Regards, Willy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf