In message <20120608011910.GA16069@srv03.cluenet.de>, Daniel Roesen writes:
On Thu, Jun 07, 2012 at 04:43:41PM -0700, David Temkin wrote:
What do you mean? www.netflix.com is dual stacked, which represents availability of our website (and PC/Mac streaming clients) to100% of our users who have IPv6.
The zero TTL on the CNAME an AAAA RRs makes www.netflix.com zero-stacked at least for some resolvers:
$ dig @pdns3.ultradns.org www.netflix.com. A +norec +short wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. $ dig @pdns3.ultradns.org www.netflix.com. AAAA +norec +short dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. $ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec $
Resolving www.netflix.com using ANY RRtype fails with an empty answer section in the DNS response.
Which is just plain BROKEN.
This DNS trickery seems to be from the "taking a shower, trying not to get wet" department. And has adverse effects in corner cases. While playing around, I had periods of time where I couldn't resolve the FQDN at all, possibly due some caching of the empty response.
It's not DNS trickery. It's not reading the RFC or doing any testing for common cases. Not every query has type A. Way too many load balancers get the answers to anything other than A queries wrong. If your load balancer get answers to queries other than A wrong demand your money back. This sort of !@$E in authoritative servers makes it hard for recursive servers to do the right thing. pandora.tv servers are the poster child for getting it wrong currently. * They don't set "aa" as per RFC 103[45]. (If you set it in the query they clear it.) * They don't clear "ad" as per RFC 103[45]. * They have extra data after the DNS response. * They send back malformed responses to EDNS queries. bsdi# dig9 ns pandora.tv @N1.pandora.tv +noedns +norec ; <<>> DiG 9.9.1-P1 <<>> ns pandora.tv @N1.pandora.tv +noedns +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36153 ;; flags: qr ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: Messages has 27 extra bytes at end ;; QUESTION SECTION: ;pandora.tv. IN NS ;; ANSWER SECTION: pandora.tv. 300 IN NS N1.pandora.tv. pandora.tv. 300 IN NS N2.pandora.tv. pandora.tv. 300 IN NS N15.pandora.tv. pandora.tv. 300 IN NS N16.pandora.tv. pandora.tv. 300 IN NS N17.pandora.tv. ;; Query time: 385 msec ;; SERVER: 61.111.8.236#53(61.111.8.236) ;; WHEN: Fri Jun 8 11:56:22 2012 ;; MSG SIZE rcvd: 143 bsdi# dig9 ns pandora.tv @N1.pandora.tv +edns=0 +norec ;; Got bad packet: FORMERR 143 bytes cd c9 80 a0 00 01 00 05 00 00 00 01 07 70 61 6e .............pan 64 6f 72 61 02 74 76 00 00 02 00 01 c0 0c 00 02 dora.tv......... 00 01 00 00 01 2c 00 05 02 4e 31 c0 0c c0 0c 00 .....,...N1..... 02 00 01 00 00 01 2c 00 05 02 4e 32 c0 0c c0 0c ......,...N2.... 00 02 00 01 00 00 01 2c 00 06 03 4e 31 35 c0 0c .......,...N15.. c0 0c 00 02 00 01 00 00 01 2c 00 06 03 4e 31 36 .........,...N16 c0 0c c0 0c 00 02 00 01 00 00 01 2c 00 06 03 4e ...........,...N 31 37 c0 0c 00 00 00 00 00 00 00 00 00 00 00 00 17.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... bsdi# Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org