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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]