when i check resolver.log just now , i found some error info about AAAA ( ipv6)
Hello Dear Sir : when i check resolver.log just now , i found some error info about ( ipv6) although i search some helpful info from ask.com , but i can't find the config file , maybe the reason is i compiled via source file ( ./configure --prefix=/mydic ). Whether i need build the config file ? This of course won't stop bind from blindly trying to use ipv6 though, so you also need to alter |/etc/default/bind9| like so: |# run resolvconf? RESOLVCONF=yes # startup options for the server OPTIONS="-4 -u bind" | 13-Apr-2016 11:49:11.858 DNS format error from 106.38.226.245#53 resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325: non-improving referral 13-Apr-2016 11:49:11.898 DNS format error from 111.206.208.224#53 resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325: non-improving referral 13-Apr-2016 11:49:11.939 DNS format error from 117.121.2.237#53 resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325: non-improving referral ___ 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
Re: when i check resolver.log just now , i found some error info about AAAA ( ipv6)
Just another broken nameserver that doesn't handle queries correctly. It answers authoritatively for dlb.g5.letvlb.com/A but returns a referral for dlb.g5.letvlb.com/ with unrelated additional records. Mark % dig dlb.g5.letvlb.com @106.38.226.245 ; <<>> DiG 9.11.0a1 <<>> dlb.g5.letvlb.com @106.38.226.245 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61581 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;dlb.g5.letvlb.com. IN A ;; ANSWER SECTION: dlb.g5.letvlb.com. 600 IN A 123.59.122.228 ;; Query time: 359 msec ;; SERVER: 106.38.226.245#53(106.38.226.245) ;; WHEN: Wed Apr 13 14:16:20 EST 2016 ;; MSG SIZE rcvd: 68 % dig dlb.g5.letvlb.com @106.38.226.245 ; <<>> DiG 9.11.0a1 <<>> dlb.g5.letvlb.com @106.38.226.245 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;dlb.g5.letvlb.com. IN ;; AUTHORITY SECTION: dlb.g5.letvlb.com. 600 IN NS ns1.letvlb.com. dlb.g5.letvlb.com. 600 IN NS ns2.letvlb.com. dlb.g5.letvlb.com. 600 IN NS ns3.letvlb.com. ;; ADDITIONAL SECTION: au.ns1.letvlb.com. 600 IN A 111.206.208.224 au.ns2.letvlb.com. 600 IN A 106.38.226.245 au.ns3.letvlb.com. 600 IN A 117.121.2.237 ;; Query time: 492 msec ;; SERVER: 106.38.226.245#53(106.38.226.245) ;; WHEN: Wed Apr 13 14:16:25 EST 2016 ;; MSG SIZE rcvd: 269 % In message <570dc310.1060...@yahoo.com>, johnzeng writes: > > Hello Dear Sir : > > when i check resolver.log just now , i found some error info about > ( ipv6) > > although i search some helpful info from ask.com , but i can't find the > config file , maybe the reason is i compiled via source file ( > ./configure --prefix=/mydic ). > > Whether i need build the config file ? > > > > This of course won't stop bind from blindly trying to use ipv6 though, > so you also need to alter |/etc/default/bind9| like so: > > |# run resolvconf? > RESOLVCONF=yes > # startup options for the server > OPTIONS="-4 -u bind" > | > > > > > 13-Apr-2016 11:49:11.858 DNS format error from 106.38.226.245#53 > resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325: > non-improving referral > 13-Apr-2016 11:49:11.898 DNS format error from 111.206.208.224#53 > resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325: > non-improving referral > 13-Apr-2016 11:49:11.939 DNS format error from 117.121.2.237#53 > resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325: > non-improving referral > > ___ > 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
RE: when i check resolver.log just now , i found some error info about AAAA ( ipv6)
To be clear, "turning off" IPv6 in named (via the -4 flag or other means), doesn't mean named won't try to resolve any records, especially if one of your (presumably IPv6-enabled) clients requests them. So, even with IPv6 "turned off", if there are nameservers on the Internet that -- for whatever reason -- have trouble resolving records, you'll see errors in the logs when you try to resolve records from those nameservers. 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 queries. For that matter, if your clients are enabled for IPv6, and you have good IPv6 connectivity to the Internet, especially in the APAC region where IPv6 is, I hear, ubiquitous (and yes, I did verify that all of the IP addresses in your email were assigned to Chinese ISPs/telcos), why are you turning off IPv6 on your nameserver? Embrace it. - Kevin -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Andrews Sent: Wednesday, April 13, 2016 12:33 AM To: johnzeng Cc: bind-us...@isc.org Subject: Re: when i check resolver.log just now , i found some error info about ( ipv6) Just another broken nameserver that doesn't handle queries correctly. It answers authoritatively for dlb.g5.letvlb.com/A but returns a referral for dlb.g5.letvlb.com/ with unrelated additional records. Mark % dig dlb.g5.letvlb.com @106.38.226.245 ; <<>> DiG 9.11.0a1 <<>> dlb.g5.letvlb.com @106.38.226.245 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61581 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;dlb.g5.letvlb.com. IN A ;; ANSWER SECTION: dlb.g5.letvlb.com. 600 IN A 123.59.122.228 ;; Query time: 359 msec ;; SERVER: 106.38.226.245#53(106.38.226.245) ;; WHEN: Wed Apr 13 14:16:20 EST 2016 ;; MSG SIZE rcvd: 68 % dig dlb.g5.letvlb.com @106.38.226.245 ; <<>> DiG 9.11.0a1 <<>> dlb.g5.letvlb.com @106.38.226.245 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;dlb.g5.letvlb.com. IN ;; AUTHORITY SECTION: dlb.g5.letvlb.com. 600 IN NS ns1.letvlb.com. dlb.g5.letvlb.com. 600 IN NS ns2.letvlb.com. dlb.g5.letvlb.com. 600 IN NS ns3.letvlb.com. ;; ADDITIONAL SECTION: au.ns1.letvlb.com. 600 IN A 111.206.208.224 au.ns2.letvlb.com. 600 IN A 106.38.226.245 au.ns3.letvlb.com. 600 IN A 117.121.2.237 ;; Query time: 492 msec ;; SERVER: 106.38.226.245#53(106.38.226.245) ;; WHEN: Wed Apr 13 14:16:25 EST 2016 ;; MSG SIZE rcvd: 269 % In message <570dc310.1060...@yahoo.com>, johnzeng writes: > > Hello Dear Sir : > > when i check resolver.log just now , i found some error info about > ( ipv6) > > although i search some helpful info from ask.com , but i can't find > the config file , maybe the reason is i compiled via source file ( > ./configure --prefix=/mydic ). > > Whether i need build the config file ? > > > > This of course won't stop bind from blindly trying to use ipv6 though, > so you also need to alter |/etc/default/bind9| like so: > > |# run resolvconf? > RESOLVCONF=yes > # startup options for the server > OPTIONS="-4 -u bind" > | > > > > > 13-Apr-2016 11:49:11.858 DNS format error from 106.38.226.245#53 > resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325: > non-improving referral > 13-Apr-2016 11:49:11.898 DNS format error from 111.206.208.224#53 > resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325: > non-improving referral > 13-Apr-2016 11:49:11.939 DNS format error from 117.121.2.237#53 > resolving dlb.g5.letvlb.com/ for client 127.0.0.1#53325: > non-improving referral > > ___ > 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 ___ Plea
Re: when i check resolver.log just now , i found some error info about AAAA ( ipv6)
In article , "Darcy Kevin (FCA)" 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 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 the first place (how hard would it have been for them to return NOERROR?), so there's no reason to expect them to treat any differently from other types 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
RE: when i check resolver.log just now , i found some error info about AAAA ( ipv6)
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, 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. - Kevin -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] 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 about ( ipv6) In article , "Darcy Kevin (FCA)" 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 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 the first place (how hard would it have been for them to return NOERROR?), so there's no reason to expect them to treat any differently from other types 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
Re: when i check resolver.log just now , i found some error info about AAAA ( ipv6)
In message , "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, > 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. 600IN 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 ( ipv6) > > In article , > "Darcy Kevin (FCA)" 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 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 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
