In message <a166653da9f5441ab61b933c2f233...@mxph4chrw.fgremc.it>, "Darcy Kevin (FCA)" writes: > I don't know about other GSLBs, but Cisco GSSes could be made to respond > relatively sanely, with some careful configuration. We had to set up a > "shadow" version of each GSLB-delegated subzone on BIND, and the GSSes > would proxy all queries they couldn't handle themselves to/from this > "shadow" version. The _piece_de_resistance_ is to add an obscure wildcard > entry in each zone so that all non-apex proxied queries get a NODATA > response. This is to inhibit inappropriate NXDOMAIN responses when the > name is defined in the GSS, but the type is not handled, e.g. MX, TXT, > AAAA or whatever. Such inappropriate NXDOMAIN queries generate negative > cache entries for the name, which can then interfere with the A queries. > Not a perfect solution, but it got us by until we could migrate off that > horrible platform.
The shadow zone needs default values for whatever is being answered by the load balancer. Whether these are wildcards depends upon the front end configuration. This also means NSEC/NSEC3 records have the right type maps etc. when you start returning signed answers. Unfortunately you can't get this through some DNS operators heads. Yes, I'm talking to Adobe's adminstrators who appear to be incapable of configuring download.wip4.adobe.com properly. The only difference in these two queries is the presence or not of a EDNS cookie option. Yes, they were informed over a year ago about this isssue. ; <<>> DiG 9.11.0a1 <<>> @du1gtm001.adobe.com download.wip4.adobe.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45738 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;download.wip4.adobe.com. IN A ;; AUTHORITY SECTION: wip4.adobe.com. 30 IN SOA sj1gtm001.adobe.com. hostmaster.sj1gtm001.adobe.com. 1375 10800 3600 604800 60 ;; Query time: 495 msec ;; SERVER: 193.104.215.247#53(193.104.215.247) ;; WHEN: Thu Apr 14 08:27:22 EST 2016 ;; MSG SIZE rcvd: 109 ; <<>> DiG 9.11.0a1 <<>> @du1gtm001.adobe.com download.wip4.adobe.com +nocookie ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60620 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;download.wip4.adobe.com. IN A ;; ANSWER SECTION: download.wip4.adobe.com. 600 IN CNAME download.adobe.com.edgesuite.net. ;; Query time: 446 msec ;; SERVER: 193.104.215.247#53(193.104.215.247) ;; WHEN: Thu Apr 14 08:27:37 EST 2016 ;; MSG SIZE rcvd: 98 Given BIND 9.11.0 sends a EDNS COOKIE option with every request they may want to actually fix this ASAP or all their customers downloads will be failing. BIND 9.10.x on Windows already sees this misconfiguration. Mark > - Kevin > > -----Original Message----- > From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.o > rg] On Behalf Of Barry Margolin > Sent: Wednesday, April 13, 2016 4:45 PM > To: comp-protocols-dns-b...@isc.org > Subject: Re: when i check resolver.log just now , i found some error info abo > ut AAAA ( ipv6) > > In article <mailman.548.1460561615.73610.bind-us...@lists.isc.org>, > "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote: > > > Really, there's no excuse, in this day and age, for a DNS-serving > > device -- even a load-balancer pretending to be a nameserver -- to > > botch its responses to AAAA queries. > > Load balancers routinely botch requests for any type other than the specific > type they're programmed to balance. There's never been an excuse for it in th > e first place (how hard would it have been for them to return NOERROR?), so t > here's no reason to expect them to treat AAAA any differently from other type > s that they don't know about. > > -- > Barry Margolin > Arlington, MA > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
