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 > ******************************************* _______________________________________________ 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
