Dear Partner ! This problem is show below. My DNS response fail when recusive increase to about 4000.
I think Cache DNS have problem. :( Can I help me fix it ? Thanks./. ============%%- Nguyễn Xuân Hùng 0084-966581518 P.ISP– TT CNTT – VTNet. -----Original Message----- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of bind-users-requ...@lists.isc.org Sent: Thursday, August 07, 2014 10:50 AM To: bind-users@lists.isc.org Subject: bind-users Digest, Vol 1909, Issue 1 Send bind-users mailing list submissions to bind-users@lists.isc.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/bind-users or, via email, send a message with subject or body 'help' to bind-users-requ...@lists.isc.org You can reach the person managing the list at bind-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Re: ISP caching server setup (Mark Andrews) 2. Re: ISP caching server setup (Jared Empson) 3. Re: ISP caching server setup (Jared Empson) 4. Value of memory (Robert Moskowitz) 5. Re: ISP caching server setup (Jared Empson) ---------------------------------------------------------------------- Message: 1 Date: Thu, 07 Aug 2014 09:28:45 +1000 From: Mark Andrews <ma...@isc.org> To: Jared Empson <jared.emp...@zitomedia.com> Cc: bind-us...@isc.org Subject: Re: ISP caching server setup Message-ID: <20140806232845.5c2b31b9f...@rock.dv.isc.org> In message <3a1ebfdb-a033-4e07-be61-9f6ba6916...@zitomedia.com>, Jared Empson w rites: > > I manage a small group of cache only servers for an ISP. We run Bind > 9.7 You run BIND 9.7.0 and haven't applied any of the maintainence releases to BIND 9.7. > and have noticed that several domains our customers would like to > access are unavailable from our cache servers. These same domains > work on other provider networks such as Verizon or Google. In BIND 9.7.0 we restored the code to skip to non authorative answers from supposedly authorative servers having fixed a bug in named. Unfortunately there are some zones for which all the servers are broken and don't return authorative (aa=1) answers. BIND 9.7.1 reversed the change to skip non authorative answers despite it being technically correct. > What I have found is that these domains all have misconfigured glue > records. This could be cause by a recent change of registrar or a > misconfigured zone file pointing to NS records that no longer exist as > glue records. Because of this any query of a host from these domains > receive a non-authoratative response and are dropped by our cache servers. > > How do I configure the cache server to accept the non-authoritative > response to provide our customers access to these domains with out > forwarding to Google's caching servers? > An example domain is losscontrol360.com. > What our customers receive: > ; <<>> DiG 9.8.3-P1 <<>> losscontrol360.com ;; global options: +cmd ;; > Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31462 ;; flags: > qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;losscontrol360.com. IN A > > ;; Query time: 1380 msec > ;; SERVER: 10.100.2.11#53(10.100.2.11) ;; WHEN: Wed Aug 6 16:00:55 > 2014 ;; MSG SIZE rcvd: 36 > > What our cache server receives: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38342 ;; flags: > qr ; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT > PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1280 ;; QUESTION SECTION: > ;losscontrol360.com. IN A > > ;; ANSWER SECTION: > losscontrol360.com. 173 IN A 74.208.98.80 > > What Google provides: > ; <<>> DiG 9.8.3-P1 <<>> losscontrol360.com @8.8.8.8 ;; global > options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17193 ;; flags: qr > rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;losscontrol360.com. IN A > > ;; ANSWER SECTION: > losscontrol360.com. 586 IN A 74.208.98.80 > > ;; Query time: 174 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Wed Aug 6 16:01:07 2014 > ;; MSG SIZE rcvd: 52 > > Jared Empson > Systems Administrator > Zito Media -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ------------------------------ Message: 2 Date: Wed, 6 Aug 2014 20:45:38 -0400 From: Jared Empson <jared.emp...@zitomedia.com> To: Mark Andrews <ma...@isc.org> Cc: Dave Bernardi <dave.berna...@zitomedia.com>, bind-us...@isc.org Subject: Re: ISP caching server setup Message-ID: <4ef85fa1-deb0-4a51-b90e-6c5e2cfcf...@zitomedia.com> Content-Type: text/plain; charset=windows-1252 Jared Empson Systems Administrator Zito Media 814.260.9450 On Aug 6, 2014, at 7:28 PM, Mark Andrews <ma...@isc.org> wrote: > > In message <3a1ebfdb-a033-4e07-be61-9f6ba6916...@zitomedia.com>, Jared Empson > w > rites: >> >> I manage a small group of cache only servers for an ISP. We run Bind 9.7 > > You run BIND 9.7.0 and haven't applied any of the maintainence releases > to BIND 9.7. I just updated the bind instance with the Ubuntu Lucid packages so I?m running version BIND 9.7.0-P1. > >> and have noticed that several domains our customers would like to access >> are unavailable from our cache servers. These same domains work on other >> provider networks such as Verizon or Google. > > In BIND 9.7.0 we restored the code to skip to non authorative answers > from supposedly authorative servers having fixed a bug in named. > Unfortunately there are some zones for which all the servers are > broken and don't return authorative (aa=1) answers. > > BIND 9.7.1 reversed the change to skip non authorative answers > despite it being technically correct. Do you suggest we upgrade to bind version 9.7.1? > >> What I have found is that these domains all have misconfigured glue >> records. This could be cause by a recent change of registrar or a >> misconfigured zone file pointing to NS records that no longer exist as >> glue records. Because of this any query of a host from these domains >> receive a non-authoratative response and are dropped by our cache servers. >> >> How do I configure the cache server to accept the non-authoritative >> response to provide our customers access to these domains with out >> forwarding to Google's caching servers? > > >> An example domain is losscontrol360.com. >> What our customers receive: >> ; <<>> DiG 9.8.3-P1 <<>> losscontrol360.com >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31462 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;losscontrol360.com. IN A >> >> ;; Query time: 1380 msec >> ;; SERVER: 10.100.2.11#53(10.100.2.11) >> ;; WHEN: Wed Aug 6 16:00:55 2014 >> ;; MSG SIZE rcvd: 36 >> >> What our cache server receives: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38342 >> ;; flags: qr ; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags: do; udp: 1280 >> ;; QUESTION SECTION: >> ;losscontrol360.com. IN A >> >> ;; ANSWER SECTION: >> losscontrol360.com. 173 IN A 74.208.98.80 >> >> What Google provides: >> ; <<>> DiG 9.8.3-P1 <<>> losscontrol360.com @8.8.8.8 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17193 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;losscontrol360.com. IN A >> >> ;; ANSWER SECTION: >> losscontrol360.com. 586 IN A 74.208.98.80 >> >> ;; Query time: 174 msec >> ;; SERVER: 8.8.8.8#53(8.8.8.8) >> ;; WHEN: Wed Aug 6 16:01:07 2014 >> ;; MSG SIZE rcvd: 52 >> >> Jared Empson >> Systems Administrator >> Zito Media > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ------------------------------ Message: 3 Date: Wed, 6 Aug 2014 22:41:06 -0400 From: Jared Empson <jared.emp...@zitomedia.com> To: bind-users@lists.isc.org Subject: Re: ISP caching server setup Message-ID: <4e051dff-030a-47eb-a146-4232ab254...@zitomedia.com> Content-Type: text/plain; charset=windows-1252 I had my message settings set to digest so I apologize for responding to each of your responses in one email. See all comments below. Jared Empson Systems Administrator Zito Media 814.260.9450 On Aug 6, 2014, at 6:48 PM, bind-users-requ...@lists.isc.org wrote: > > Message: 2 > Date: Wed, 06 Aug 2014 22:20:57 +0200 > From: Reindl Harald <h.rei...@thelounge.net> > To: bind-users@lists.isc.org > Subject: Re: ISP caching server setup > Message-ID: <53e28e29....@thelounge.net> > Content-Type: text/plain; charset="windows-1252" > > interesting, that is indeed wrong configured > http://www.intodns.com/losscontrol360.com > > on the other hand all my recursive bind 9.9.4 nameservers > resolve it as well my homeserver which is using the caching > named on the office as forwarder > > also the unbound instance running as caching server on > our mail-machine using the internal named as forwarders > has the same result > > really interesting "dig NS" ends in a SERVFAIL everywhere > except Google (8.8.8.8) so from where do my named get > the responses at all > > Am 06.08.2014 um 22:03 schrieb Jared Empson: >> I manage a small group of cache only servers for an ISP. We run Bind 9.7 >> and have noticed that several domains our >> customers would like to access are unavailable from our cache servers. >> These same domains work on other provider >> networks such as Verizon or Google. >> >> What I have found is that these domains all have misconfigured glue records. >> This could be cause by a recent >> change of registrar or a misconfigured zone file pointing to NS records that >> no longer exist as glue records. >> Because of this any query of a host from these domains receive a >> non-authoratative response and are dropped by our >> cache servers. >> >> How do I configure the cache server to accept the non-authoritative response >> to provide our customers access to >> these domains with out forwarding to Google?s caching servers? >> >> An example domain is losscontrol360.com <http://losscontrol360.com>. >> What our customers receive: >> ; <<>> DiG 9.8.3-P1 <<>> losscontrol360.com <http://losscontrol360.com> >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31462 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;losscontrol360.com <http://losscontrol360.com>.INA >> >> ;; Query time: 1380 msec >> ;; SERVER: 10.100.2.11#53(10.100.2.11) >> ;; WHEN: Wed Aug 6 16:00:55 2014 >> ;; MSG SIZE rcvd: 36 >> >> What our cache server receives: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38342 >> ;; flags: qr ; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags: do; udp: 1280 >> ;; QUESTION SECTION: >> ;losscontrol360.com <http://losscontrol360.com>.INA >> >> ;; ANSWER SECTION: >> losscontrol360.com <http://losscontrol360.com>.173INA74.208.98.80 >> >> What Google provides: >> ; <<>> DiG 9.8.3-P1 <<>> losscontrol360.com <http://losscontrol360.com> >> @8.8.8.8 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17193 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;losscontrol360.com <http://losscontrol360.com>.INA >> >> ;; ANSWER SECTION: >> losscontrol360.com <http://losscontrol360.com>.586INA74.208.98.80 >> >> ;; Query time: 174 msec >> ;; SERVER: 8.8.8.8#53(8.8.8.8) >> ;; WHEN: Wed Aug 6 16:01:07 2014 >> ;; MSG SIZE rcvd: 52 > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 181 bytes > Desc: OpenPGP digital signature > URL: > <https://lists.isc.org/pipermail/bind-users/attachments/20140806/fb91d94d/attachment-0001.bin> > > ------------------------------ > > Message: 3 > Date: Thu, 07 Aug 2014 08:33:28 +1000 > From: Noel Butler <noel.but...@ausics.net> > To: bind-users@lists.isc.org > Subject: Re: ISP caching server setup > Message-ID: <a9847490b6c454bd815621f7818b6...@ausics.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 07/08/2014 06:03, Jared Empson wrote: > >> >> What our cache server receives: >> >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38342 >> ;; flags: qr ; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags: do; udp: 1280 >> ;; QUESTION SECTION: >> ;losscontrol360.com [2]. IN A >> >> ;; ANSWER SECTION: >> losscontrol360.com [2]. 173 IN A 74.208.98.80 >> >> What Google provides: ; <<>> DiG 9.8.3-P1 <<>> losscontrol360.com [2] >> @8.8.8.8 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17193 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;losscontrol360.com [2]. IN A >> >> ;; ANSWER SECTION: >> losscontrol360.com [2]. 586 IN A 74.208.98.80 >> >> ;; Query time: 174 msec >> ;; SERVER: 8.8.8.8#53(8.8.8.8) >> ;; WHEN: Wed Aug 6 16:01:07 2014 >> >> ;; MSG SIZE rcvd: 52 >> > > > Apart from stupid SOA values, losscontrol360.com seems OK, and from your > two examples here even proves that, if your customers don't see what > your cache server does, they cant be using the same cache server as you > showed here. what error does bind log when your customer looks it up? Actually the response my cache server receives has been pulled from the resolver.log with trace level 10 turned on. If I do a dig from my cache server the cache server will also fail to receive a response. if I do a dig +trace I get a response as +trace bypasses cache. > > > > ------------------------------ > > Message: 4 > Date: Thu, 07 Aug 2014 00:40:16 +0200 > From: Reindl Harald <h.rei...@thelounge.net> > To: bind-users@lists.isc.org > Subject: Re: ISP caching server setup > Message-ID: <53e2aed0....@thelounge.net> > Content-Type: text/plain; charset="windows-1252" > > > > Am 07.08.2014 um 00:33 schrieb Noel Butler: >> Apart from stupid SOA values, losscontrol360.com seems OK > > OK? the failing NS query is caused by the errors below > this domain only works by luck from time to time > > [harry@srv-rhsoft:~]$ dig NS losscontrol360.com > ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 <<>> NS losscontrol360.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49902 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > > http://www.intodns.com/losscontrol360.com > > Error Nameservers are lame ERROR: looks like you have lame > nameservers. The following nameservers are lame: > 54.241.6.128 > 54.243.153.234 > 107.6.6.8 > > Error Missing nameservers reported by parent FAIL: The following > nameservers are listed at your nameservers as > nameservers for your domain, but are not listed at the parent nameservers > (see RFC2181 5.4.1). You need to make > sure that these nameservers are working.If they are not working ok, you may > have problems! > b1.uberns.com > a1.uberns.com > > Error Missing nameservers reported by your nameservers ERROR: One or > more of the nameservers listed at the parent > servers are not listed as NS records at your nameservers. The problem NS > records are: > ns22.netriplex.com > ns21.netriplex.com > ns23.netriplex.com > ns20.netriplex.com > This is listed as an ERROR because there are some cases where nasty problems > can occur (if the TTLs vary from the > NS records at the root servers and the NS records point to your own domain, > for example) > > Error Stealth NS records sent Stealth NS records were sent: > b1.uberns.com > a1.uberns.com > >> if your customers don't see what your cache server does, they cant be using >> the same cache server as you showed here > > true > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 181 bytes > Desc: OpenPGP digital signature > URL: > <https://lists.isc.org/pipermail/bind-users/attachments/20140807/350d67b1/attachment-0001.bin> > > ------------------------------ > > Message: 5 > Date: Thu, 07 Aug 2014 08:48:29 +1000 > From: Noel Butler <noel.but...@ausics.net> > To: bind-users@lists.isc.org > Subject: Re: ISP caching server setup > Message-ID: <90d33a3b80bb02f70dacd57b7711b...@ausics.net> > Content-Type: text/plain; charset="us-ascii" > > > > You are in fact correct Harry, I never bothered with a whois, had I done > so I would have picked it up, put it down to too early in the morning, > so this problem is out of Jared's control, unless he also manages that > domain. This is out of my control. My first step would be to resolve the glue/ns record inconsistency which I have already informed the domain owner of the issue. What I?m looking to accomplish is to have a googleish cache server that will resolve even poorly configured domains for my customers with out actually pointing all of my traffic at Google. > > Ohh and nice to see you are actually behaving yourself on this list :) > > On 07/08/2014 08:40, Reindl Harald wrote: > >> Am 07.08.2014 um 00:33 schrieb Noel Butler: >> >>> Apart from stupid SOA values, losscontrol360.com seems OK >> >> OK? the failing NS query is caused by the errors below >> this domain only works by luck from time to time >> >> [harry@srv-rhsoft:~]$ dig NS losscontrol360.com >> ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 <<>> NS losscontrol360.com >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49902 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> http://www.intodns.com/losscontrol360.com [1] >> >> Error Nameservers are lame ERROR: looks like you have lame nameservers. The >> following nameservers are lame: >> 54.241.6.128 >> 54.243.153.234 >> 107.6.6.8 >> >> Error Missing nameservers reported by parent FAIL: The following nameservers >> are listed at your nameservers as >> nameservers for your domain, but are not listed at the parent nameservers >> (see RFC2181 5.4.1). You need to make >> sure that these nameservers are working.If they are not working ok, you may >> have problems! >> b1.uberns.com >> a1.uberns.com >> >> Error Missing nameservers reported by your nameservers ERROR: One or more of >> the nameservers listed at the parent >> servers are not listed as NS records at your nameservers. The problem NS >> records are: >> ns22.netriplex.com >> ns21.netriplex.com >> ns23.netriplex.com >> ns20.netriplex.com >> This is listed as an ERROR because there are some cases where nasty problems >> can occur (if the TTLs vary from the >> NS records at the root servers and the NS records point to your own domain, >> for example) >> >> Error Stealth NS records sent Stealth NS records were sent: >> b1.uberns.com >> a1.uberns.com >> >>> if your customers don't see what your cache server does, they cant be using >>> the same cache server as you showed here >> >> true >> >> _______________________________________________ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users [2] to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users [2] > > > > Links: > ------ > [1] http://www.intodns.com/losscontrol360.com > [2] https://lists.isc.org/mailman/listinfo/bind-users > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://lists.isc.org/pipermail/bind-users/attachments/20140807/dd0cbb44/attachment.html> > > ------------------------------ > > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > End of bind-users Digest, Vol 1908, Issue 3 > ******************************************* ------------------------------ Message: 4 Date: Wed, 06 Aug 2014 23:39:08 -0400 From: Robert Moskowitz <r...@htt-consult.com> To: bind-us...@isc.org Subject: Value of memory Message-ID: <53e2f4dc.7050...@htt-consult.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I have a server that is only running bind 9.8.2 (Centos 6.5). It has 2Gb memory and free reports ~1.7Gb used. I am looking at replacing this server with an armv7 board running Redsleeve (until Centos 7 is out and stable for armv7). I have a choice of boards, one with 1Gb memory ($60) and one with 2Gb memory ($90). This server servers out my zones and supports the couple handfull of systems on my net. I would like to eventually get to DNSSEC, but that is another stalled project. About the only meaningful difference between the two boards (btw, Cubieboard2 and Cubietruck) for my needs is the memory. I know more memory is better, but how much better? Oh, why the move to arm? Power consumption. ROI for the C2 board is one year just on power saving. ------------------------------ Message: 5 Date: Wed, 6 Aug 2014 23:49:53 -0400 From: Jared Empson <jared.emp...@zitomedia.com> To: Mark Andrews <ma...@isc.org> Cc: Dave Bernardi <dave.berna...@zitomedia.com>, bind-us...@isc.org Subject: Re: ISP caching server setup Message-ID: <c4ff41e6-f3ca-474c-bee3-f71ad4b77...@zitomedia.com> Content-Type: text/plain; charset=windows-1252 I have upgrade the bind version on one of my cache servers to 9.9.5. This has resolved the issue of non-authoritative responses not being passed on to clients. Thank you for your assistance. Jared Empson Systems Administrator Zito Media 814.260.9450 On Aug 6, 2014, at 8:45 PM, Jared Empson <jared.emp...@zitomedia.com> wrote: > > Jared Empson > Systems Administrator > Zito Media > 814.260.9450 > > > > On Aug 6, 2014, at 7:28 PM, Mark Andrews <ma...@isc.org> wrote: > >> >> In message <3a1ebfdb-a033-4e07-be61-9f6ba6916...@zitomedia.com>, Jared >> Empson w >> rites: >>> >>> I manage a small group of cache only servers for an ISP. We run Bind 9.7 >> >> You run BIND 9.7.0 and haven't applied any of the maintainence releases >> to BIND 9.7. > > I just updated the bind instance with the Ubuntu Lucid packages so I?m > running version BIND 9.7.0-P1. > >> >>> and have noticed that several domains our customers would like to access >>> are unavailable from our cache servers. These same domains work on other >>> provider networks such as Verizon or Google. >> >> In BIND 9.7.0 we restored the code to skip to non authorative answers >> from supposedly authorative servers having fixed a bug in named. >> Unfortunately there are some zones for which all the servers are >> broken and don't return authorative (aa=1) answers. >> >> BIND 9.7.1 reversed the change to skip non authorative answers >> despite it being technically correct. > > Do you suggest we upgrade to bind version 9.7.1? > >> >>> What I have found is that these domains all have misconfigured glue >>> records. This could be cause by a recent change of registrar or a >>> misconfigured zone file pointing to NS records that no longer exist as >>> glue records. Because of this any query of a host from these domains >>> receive a non-authoratative response and are dropped by our cache servers. >>> >>> How do I configure the cache server to accept the non-authoritative >>> response to provide our customers access to these domains with out >>> forwarding to Google's caching servers? >> >> >>> An example domain is losscontrol360.com. >>> What our customers receive: >>> ; <<>> DiG 9.8.3-P1 <<>> losscontrol360.com >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31462 >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 >>> >>> ;; QUESTION SECTION: >>> ;losscontrol360.com. IN A >>> >>> ;; Query time: 1380 msec >>> ;; SERVER: 10.100.2.11#53(10.100.2.11) >>> ;; WHEN: Wed Aug 6 16:00:55 2014 >>> ;; MSG SIZE rcvd: 36 >>> >>> What our cache server receives: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38342 >>> ;; flags: qr ; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags: do; udp: 1280 >>> ;; QUESTION SECTION: >>> ;losscontrol360.com. IN A >>> >>> ;; ANSWER SECTION: >>> losscontrol360.com. 173 IN A 74.208.98.80 >>> >>> What Google provides: >>> ; <<>> DiG 9.8.3-P1 <<>> losscontrol360.com @8.8.8.8 >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17193 >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >>> >>> ;; QUESTION SECTION: >>> ;losscontrol360.com. IN A >>> >>> ;; ANSWER SECTION: >>> losscontrol360.com. 586 IN A 74.208.98.80 >>> >>> ;; Query time: 174 msec >>> ;; SERVER: 8.8.8.8#53(8.8.8.8) >>> ;; WHEN: Wed Aug 6 16:01:07 2014 >>> ;; MSG SIZE rcvd: 52 >>> >>> Jared Empson >>> Systems Administrator >>> Zito Media >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ------------------------------ _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users End of bind-users Digest, Vol 1909, Issue 1 ******************************************* _______________________________________________ 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
