ietf
[Top] [All Lists]

Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

2011-07-24 20:50:13
[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 
label.

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 
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'.  This is qualitatively different than the prioritization offered by 
SRV.

Regards,
-drc

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>