ISP caching server setup

[Jared Empson]

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
>