bind-users Digest, Vol 1909, Issue 1
Abdul Khader
akhader at ies.etisalat.ae
Thu Aug 7 09:18:29 UTC 2014
what is the value of "recursive-clients" in named.conf
Abdul Khader
On 07-Aug-14 12:54 PM, Xuan Hung wrote:
> 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
> *******************************************
>
> _______________________________________________
> 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
More information about the bind-users
mailing list