ISP caching server setup

[Reindl Harald]

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.bin>