[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.
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
None is cheaper nor better than the other.
CNAME results in the resolver doing additional work, generally resulting in no
need for an additional query but is not applicable in all situations (e.g.,
putting a CNAME at a zone apex is a gamble). SRV is far more general solution
with additional benefits (e.g., priority) but requires an additional query.
The two RR type solve different problems. CNAME is an alias for a host. SRV
provides information about services at a host.
On Jul 24, 2011, at 9:29 AM, Willy Tarreau wrote:
DNS provides geolocation and proposes you the closest working datacenter.
No it doesn't. The DNS _may_ provide a reasonable facsimile to geolocation if
and only if the resolver is co-located with the requester. In a world of Google
DNS, OpenDNS, ISP-wide anycast resolvers, etc., the assumption that the
location associated with the IP of a DNS query correlates to the IP address of
the HTTP initiator becomes increasingly dangerous.
Anyhow, don't forget that SRV is not just for failover, but also for
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'. This is qualitatively different than the prioritization offered by
Ietf mailing list