In message <20110725045821.GN22405@xxxxxx>, Willy Tarreau writes: > 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. You are missing the point. The following is illegal though some nameservers allow you to load the zone. example.com SOA ... example.com CNAME ... This is not illegal example.com SOA _http._tcp.example.com SRV ... Nor is a fictional HTTP record which adds the same level of indirection as CNAME. example.com SOA ... example.com HTTP <server> > > 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 ser > ver 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. But it adds a lot of value to everyone else using the DNS. By HTTP clients and adminitrators abusing CNAME to achieve what SRV achieves cleanly they cause problems elsewhere. > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf