when i check resolver.log just now , i found some error info about AAAA ( ipv6)

[Mark Andrews]

In message <a166653da9f5441ab61b933c2f2338d3 at 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-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.o
> rg] On Behalf Of Barry Margolin
> Sent: Wednesday, April 13, 2016 4:45 PM
> To: comp-protocols-dns-bind at 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-users at lists.isc.org>,
>  "Darcy Kevin (FCA)" <kevin.darcy at 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 at 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 at 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: marka at isc.org