Clients sometimes get wrong view

Thu Jun 11 14:46:55 UTC 2009

The logging will prove very instructive I think. You should prioritise that
so that you can see what view the query is matching.

Is there a possibility of having either a firewall or router NAT any of the
queries? Many products will rewrite DNS queries and responses based on
static NAT rules (overloaded addresses tend not to be rewritten).

Default settings for this can vary between devices. Most of my experience is
with Cisco devices and IIRC routers will translate by default and firewalls
the reverse.

However, the behaviour would be consistent, not random. Unless some other
network condition intervened to change the path of the query occasionally,
like a load sharing rule.

On 11/6/09 1:56 AM, "Chris Buxton" <cbuxton at menandmice.com> wrote:

> Is there any chance that stub resolver caching is at work here? For
> example, if someone is in the datacenter, uses a name in some way, and
> then moves to the office, it's conceivable that their stub resolver
> will hang onto the datacenter address for the name. A simple test for
> this would be to clear the cache and try again, the next time the
> symptom presents - if that solves it, then the problem has nothing to
> do with your name server's configuration.
> 
> If that's the problem, then use of short TTL's in the private
> namespaces (datacenter, in this case) would help.
> 
> Chris Buxton
> Professional Services
> Men & Mice
> 
> On Jun 9, 2009, at 1:17 PM, Corey Shaw wrote:
> 
>> Thanks Kevin and Jeff for your answers.
>> 
>> I will try adding logging so that I can see exactly what view is
>> matched.
>> 
>> Also, yes, mydomain.com is listed in the include files that I did
>> not provide.  It is listed in each of the different views.  This is
>> how it had to be set up, because Bind does not provide more than one
>> view per query (ie.  If the domain doesn't exist in "office" view,
>> it will not go to the "datacenter" view to look next).  Each view
>> potentially has a different address for mydomain.com depending on
>> whether that is local to them or not.  In my case, mydomain.com
>> should be a public address for the "office" view, and an internal
>> address for the "datacenter" view
>> 
>> I have experienced this issue myself here at our office which falls
>> in the 166.x.x.88/29 (office) view.  Somehow, I ended up getting a
>> result from the 10.x.x.0/24 (datacenter) view.  The only possible IP
>> address that comes from our office lies in the 166.x.x.88/29 view
>> range.  Yes, I know that it isn't terribly efficient for my DNS
>> servers to not be local to my office, but I haven't gotten around to
>> adding caching servers locally yet.
>> 
>> 
>> 
>> _____________________
>> Corey
>> 
>> 
>> 
>> ----- Original Message -----
>> From: "Kevin Darcy" <kcd at chrysler.com>
>> To: bind-users at lists.isc.org
>> Sent: Tuesday, June 9, 2009 1:49:54 PM GMT -07:00 US/Canada Mountain
>> Subject: Re: Clients sometimes get wrong view
>> 
>> Note that the newer versions of querylog format include not only the
>> source address of the client, but also what view was *actually*
>> matched
>> by the query. It should be useful to turn on the querylog for
>> troubleshooting this particular issue, if the volume of queries
>> isn't so
>> huge that you'd run into capacity issues...
>> 
>> - Kevin
>> 
>> Jeff Lightner wrote:
>>> 
>>> It seems the mydomain.com isn¹t in the view but presumably in one of
>>> the includes.
>>> 
>>> So the most likely issues seem to be:
>>> 
>>> 1) You have defined mydomain.com in more than one of the includes
>>> which we can¹t tell since you didn¹t provide them.
>>> 
>>> OR-
>>> 
>>> 2) The client actually has an unexpected IP (that is you think they
>>> are in the 10.x when they are actually in 192.x or vice-versa or
>> they
>>> don¹t have an IP in either of the ranges you specified.
>>> 
>>>  
>> ------------------------------------------------------------------------
>>> 
>>> *From:* bind-users-bounces at lists.isc.org
>>> [mailto:bind-users-bounces at lists.isc.org] *On Behalf Of *Corey Shaw
>>> *Sent:* Tuesday, June 09, 2009 1:56 PM
>>> *To:* bind-users at lists.isc.org
>>> *Subject:* Clients sometimes get wrong view
>>> 
>>> OS: Gentoo
>>> 
>>> Bind Version: 9.6.0-p1
>>> 
>>> I currently have my Bind server set up with 3 views. It seems that
>>> every now and then I have clients in the "office" view that try to
>> go
>>> to www.mydomain.com (which should be a public address), but instead
>>> they get the internal address that is defined in the "datacenter"
>> view
>>> (10.x.x.x). As a result, they can't get to www.mydomain.com. My
>> views
>>> are configured as shown below (yes, all the include files exist and
>>> load properly). They are ordered in my configuration as shown
>> below as
>>> well. Any ideas on why this may be happening?
>>> 
>>> view "datacenter" {
>>> 
>>> match-clients { 10.x.x.0/24; };
>>> 
>>> recursion yes;
>>> 
>>> include "/etc/bind/includes/datacenterincludes.conf";
>>> 
>>> allow-recursion { 10.x.x.0/24; };
>>> 
>>> zone "." IN {
>>> 
>>> type hint;
>>> 
>>> file "named.ca";
>>> 
>>> };
>>> 
>>> zone "localhost" IN {
>>> 
>>> type master;
>>> 
>>> file "pri/localhost.zone";
>>> 
>>> allow-update { none; };
>>> 
>>> notify no;
>>> 
>>> };
>>> 
>>> zone "127.in-addr.arpa" IN {
>>> 
>>> type master;
>>> 
>>> file "pri/127.zone";
>>> 
>>> allow-update { none; };
>>> 
>>> notify no;
>>> 
>>> };
>>> 
>>> };
>>> 
>>> view "office" {
>>> 
>>> match-clients { 166.x.x.88/29; };
>>> 
>>> recursion yes;
>>> 
>>> include "/etc/bind/includes/officeincludes.conf";
>>> 
>>> allow-recursion { 166.x.x.88/29; };
>>> 
>>> zone "." IN {
>>> 
>>> type hint;
>>> 
>>> file "named.ca";
>>> 
>>> };
>>> 
>>> zone "localhost" IN {
>>> 
>>> type master;
>>> 
>>> file "pri/localhost.zone";
>>> 
>>> allow-update { none; };
>>> 
>>> notify no;
>>> 
>>> };
>>> 
>>> zone "127.in-addr.arpa" IN {
>>> 
>>> type master;
>>> 
>>> file "pri/127.zone";
>>> 
>>> allow-update { none; };
>>> 
>>> notify no;
>>> 
>>> };
>>> 
>>> };
>>> 
>>> view "public" {
>>> 
>>> match-clients { any; };
>>> 
>>> recursion no;
>>> 
>>> include "/etc/bind/includes/publicincludes.conf";
>>> 
>>> allow-recursion { none; };
>>> 
>>> zone "." IN {
>>> 
>>> type hint;
>>> 
>>> file "named.ca";
>>> 
>>> };
>>> 
>>> zone "localhost" IN {
>>> 
>>> type master;
>>> 
>>> file "pri/localhost.zone";
>>> 
>>> allow-update { none; };
>>> 
>>> notify no;
>>> 
>>> };
>>> 
>>> zone "127.in-addr.arpa" IN {
>>> 
>>> type master;
>>> 
>>> file "pri/127.zone";
>>> 
>>> allow-update { none; };
>>> 
>>> notify no;
>>> 
>>> };
>>> 
>>> };
>>> 
>>> _____________________
>>> Corey Shaw
>>> 
>>> /Please consider our environment before printing this e-mail or
>>> attachments./
>>> ----------------------------------
>>> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
>>> confidential information and is for the sole use of the intended
>>> recipient(s). If you are not the intended recipient, any disclosure,
>>> copying, distribution, or use of the contents of this information is
>>> prohibited and may be unlawful. If you have received this electronic
>>> transmission in error, please reply immediately to the sender that
>> you
>>> have received the message in error, and delete it. Thank you.
>>> ----------------------------------
>>>  
>> ------------------------------------------------------------------------
>>> 
>>> _______________________________________________
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>> 
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal 