Strange problem with a query deleting a record...
John E.P. Hynes
johnh at primebuchholz.com
Sat Aug 24 12:55:57 UTC 2013
On 08/24/2013 12:46 AM, Barry Margolin wrote:
> In article <mailman.1159.1377301811.20661.bind-users at lists.isc.org>,
> Mark Andrews <marka at isc.org> wrote:
>
>> In message <52177D81.8020206 at chrysler.com>, Kevin Darcy writes:
>>> On 8/22/2013 12:55 PM, johnh at primebuchholz.com wrote:
>>>> Greetings All,
>>>>
>>>> First of all, I apologize if this is out of place - I'm having a very
>>>> strange issue that is either a problem with bind itself, or at least,
>>>> affecting it. Summary:
>>>>
>>>> For only ONE address, whenever I attempt to access it through my squid
>>>> proxy, the record disappears from DNS, and the retry time changes too.
>>>> Essentially, accessing www.thisdomain.com works, but a link to a portal
>>>> on
>>>> that page to the subdomain login.thisdomain.com causes the problem. I'm
>>>> willing to bet the problem lies with squid, but as to how it could
>>>> possibly change a record in bind... Well, I'm stumped. If you don't go
>>>> through squid, everything works. All other requests to bind for the
>>>> address of the host in question work fine. Here's a the output of dig
>>>> from
>>>> before accessing the page through squid:
>>>>
>>>> ; <<>> DiG 9.4.1-P1 <<>> login.thisdomain.com
>>>> ;; global options: printcmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45037
>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;login.thisdomain.com. IN A
>>>>
>>>> ;; ANSWER SECTION:
>>>> login.thisdomain.com. 17 IN A 111.222.333.123
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> thisdomain.com. 168319 IN NS ns1.thisdomain.com.
>>>> thisdomain.com. 168319 IN NS ns2.thisdomain.com.
>>>>
>>>> ;; Query time: 0 msec
>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>> ;; WHEN: Thu Aug 22 12:29:57 2013
>>>> ;; MSG SIZE rcvd: 88
>>>>
>>>> You can do anything to request the address from bind and it works,
>>>> *except* try to access it through squid. Bypassing squid and going
>>>> directly through the firewall works fine.
>>>>
>>>> Now, immediately after you try to access it through squid:
>>>>
>>>> ; <<>> DiG 9.4.1-P1 <<>> login.thisdomain.com
>>>> ;; global options: printcmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43943
>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;login.thisdomain.com. IN A
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> thisdomain.com. 298 IN SOA ns1.thisdomain.com.
>>>> serv.anotherdomain.com. 2006062510 3600 3600 2592000 300
>>>>
>>>> ;; Query time: 0 msec
>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>> ;; WHEN: Thu Aug 22 12:30:06 2013
>>>> ;; MSG SIZE rcvd: 95
>>>>
>>>> After the 5-minute retry shown above expires, the original record
>>>> reappears.
>>>>
>>>> Ideas? I'm stumped. It seems like squid is somehow able to corrupt
>>>> bind's info, but I can't imagine how.
>>> I have a theory. If this is a name that's hosted on a stupid
>>> load-balancer, and that load-balancer doesn't understand non-A-record
>>> query types, then if Squid is sending a non-A query type (e.g. SRV,
>>> possibly even AAAA, if it's *really* stupid), then the load-balancer may
>>> be erroneously "poisoning" your cache with an NXDOMAIN response.
>>>
>>> We ran into this many years ago with Cisco GSSes (Global Site Selectors)
>>> and work around it by having a "shadow" version of the zone, which the
>>> GSSes proxy to for QTYPEs they don't handle. That "shadow" version of
>>> the zone has a wildcard entry in it which forces responses to be NODATA
>>> instead of NXDOMAIN, and this prevents the cache poisoning.
>>>
>>> - Kevin
>> The load balancer should be able to correct for such misconfigurations
>> by changing the rcode of the response from NXDOMAIN to NOERROR. It
>> knows what names is is answering for so it can know that the NXDOMAIN
>> is a erroneous response.
> If I understand what Kevin was saying, the load balancer IS the DNS
> server. If you ask it for the A record it's responsible for, it sends a
> reasonable reply. If you ask it for some other record type for that
> name, it sends NXDOMAIN instead of NOERROR.
>
> It's a design flaw in these load balancers.
>
Thanks everyone who's been helping with this.
In order to investigate this further, I did a tcpdump of both a
"working" conversation of a browser requesting the site, not going
through the squid proxy, and another of the "broken" conversation
through the proxy.
Result: There is an NXDOMAIN response to a request for an AAAA record
that the proxy makes that is causing this. The browser never asks for
anything but an A record, which succeeds.
I've contacted the site in question with this info, so hopefully it'll
get resolved. I'll keep the list posted on any results or info for
posterity.
-John
--
Please consider the environment before printing this e-mail.
This e-mail is intended only for the named person or entity to which it
is addressed and contains valuable business information that is
privileged, confidential and/or otherwise protected from disclosure.
Dissemination, distribution or copying of this e-mail or the information
herein by anyone other than the intended recipient, or an employee, or
agent responsible for delivering the message to the intended recipient,
is strictly prohibited. All contents are the copyright property of the
sender. If you are not the intended recipient, you are nevertheless
bound to respect the sender's worldwide legal rights. We require that
unintended recipients delete the e-mail and destroy all electronic
copies in their system, retaining no copies in any media. If you have
received this e-mail in error, please immediately notify us by calling
our Help Desk at (603) 433-1143, or e-mail to it at primebuchholz.com.
We appreciate your cooperation.
More information about the bind-users
mailing list