bind-users Digest, Vol 1909, Issue 1
Xuan Hung
hungnx15 at viettel.com.vn
Thu Aug 7 08:54:51 UTC 2014
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-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of bind-users-request at lists.isc.org
Sent: Thursday, August 07, 2014 10:50 AM
To: bind-users at lists.isc.org
Subject: bind-users Digest, Vol 1909, Issue 1
Send bind-users mailing list submissions to
bind-users at 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-request at lists.isc.org
You can reach the person managing the list at
bind-users-owner at 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 <marka at isc.org>
To: Jared Empson <jared.empson at zitomedia.com>
Cc: bind-users at isc.org
Subject: Re: ISP caching server setup
Message-ID: <20140806232845.5C2B31B9FA2B at rock.dv.isc.org>
In message <3A1EBFDB-A033-4E07-BE61-9F6BA6916406 at 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: marka at isc.org
------------------------------
Message: 2
Date: Wed, 6 Aug 2014 20:45:38 -0400
From: Jared Empson <jared.empson at zitomedia.com>
To: Mark Andrews <marka at isc.org>
Cc: Dave Bernardi <dave.bernardi at zitomedia.com>, bind-users at isc.org
Subject: Re: ISP caching server setup
Message-ID: <4EF85FA1-DEB0-4A51-B90E-6C5E2CFCFF5F at 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 <marka at isc.org> wrote:
>
> In message <3A1EBFDB-A033-4E07-BE61-9F6BA6916406 at 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: marka at isc.org
------------------------------
Message: 3
Date: Wed, 6 Aug 2014 22:41:06 -0400
From: Jared Empson <jared.empson at zitomedia.com>
To: bind-users at lists.isc.org
Subject: Re: ISP caching server setup
Message-ID: <4E051DFF-030A-47EB-A146-4232AB2549C9 at 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-request at lists.isc.org wrote:
>
> Message: 2
> Date: Wed, 06 Aug 2014 22:20:57 +0200
> From: Reindl Harald <h.reindl at thelounge.net>
> To: bind-users at lists.isc.org
> Subject: Re: ISP caching server setup
> Message-ID: <53E28E29.301 at 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.butler at ausics.net>
> To: bind-users at lists.isc.org
> Subject: Re: ISP caching server setup
> Message-ID: <a9847490b6c454bd815621f7818b63b6 at 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.reindl at thelounge.net>
> To: bind-users at lists.isc.org
> Subject: Re: ISP caching server setup
> Message-ID: <53E2AED0.901 at 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 at 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.butler at ausics.net>
> To: bind-users at lists.isc.org
> Subject: Re: ISP caching server setup
> Message-ID: <90d33a3b80bb02f70dacd57b7711b99b at 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 at 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 at 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 at 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 <rgm at htt-consult.com>
To: bind-users at isc.org
Subject: Value of memory
Message-ID: <53E2F4DC.7050606 at 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.empson at zitomedia.com>
To: Mark Andrews <marka at isc.org>
Cc: Dave Bernardi <dave.bernardi at zitomedia.com>, bind-users at isc.org
Subject: Re: ISP caching server setup
Message-ID: <C4FF41E6-F3CA-474C-BEE3-F71AD4B7792A at 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.empson at zitomedia.com> wrote:
>
> Jared Empson
> Systems Administrator
> Zito Media
> 814.260.9450
>
>
>
> On Aug 6, 2014, at 7:28 PM, Mark Andrews <marka at isc.org> wrote:
>
>>
>> In message <3A1EBFDB-A033-4E07-BE61-9F6BA6916406 at 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: marka at isc.org
>
------------------------------
_______________________________________________
bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
End of bind-users Digest, Vol 1909, Issue 1
*******************************************
More information about the bind-users
mailing list