Strange behaviour resolving CNAME's via a forwarder.
Hi
I am having a strange problem and I'm not sure if i am hitting a bug or
expected behaviour.
Server A on 10.1.1.1 is running BIND 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 on
RHEL6. It is acting as a recursor for its clients and also has a number of
forward zones configured as follows:
zone testdomain.com in {
type forward;
forwarders { 192.168.1.1; };
forward only;
};
Server B is on 192.168.1.1 and runs Power DNS, it is authoritative for
testdomain.com and will not service recursive queries.
Some sample entries from that zone are:
ftp IN CNAME www
www IN A 192.168.5.5
mail IN CNAME mail.someotherdomain.com.
If a client queries server A for www.testdomain.com (type any), the request
is forwarded on to 192.168.1.1 and resolves as expected.
If a client queries server A for ftp.testdomain.com (type any), the request
is forwarded on to 192.168.1.1 and resolves as expected.
However if a client queries server A for mail.testdomain.com (type any) the
request is not answered. From the logs on server B i can see that server A
is only forwarding on a request of type A. As an A record for
mail.testdomain.com does not exist on server B it does not resolve.
If i then specifically query Server A for mail.testdomain.com of type CNAME,
it resolves as expected. Subsequent requests against server A for
mail.testdomain.com of type any then resolve, presumably because it is
already in the cache.
Hopefully that makes sense! Has anyone had a similar issue and did you come
up with a work around? Is this expected behaviour or a bug?
Thanks for your help on this - its driving me mad!
Adam
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange behaviour resolving CNAME's via a forwarder.
On Apr 20, 2011, at 2:19 AM, Adam Goodall wrote:
However if a client queries server A for mail.testdomain.com (type any) the
request is not answered. From the logs on server B i can see that server A is
only forwarding on a request of type A. As an A record for
mail.testdomain.com does not exist on server B it does not resolve.
If i then specifically query Server A for mail.testdomain.com of type CNAME,
it resolves as expected. Subsequent requests against server A for
mail.testdomain.com of type any then resolve, presumably because it is
already in the cache.
Hopefully that makes sense! Has anyone had a similar issue and did you come
up with a work around? Is this expected behaviour or a bug?
This is an excellent example of why you should not forward to an auth-only
server. Use a stub zone instead. You might need to give it an empty forwarders
list, to override forwarding set in either the options or view statements.
For example:
zone testdomain.com {
type stub;
masters { 192.168.1.1; };
forwarders { };
};
Try it, you'll like it.
Chris Buxton
BlueCat Networks
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange behaviour resolving CNAME's via a forwarder.
On 20 April 2011 10:42, Chris Buxton chris.p.bux...@gmail.com wrote:
On Apr 20, 2011, at 2:19 AM, Adam Goodall wrote:
However if a client queries server A for mail.testdomain.com (type any)
the request is not answered. From the logs on server B i can see that server
A is only forwarding on a request of type A. As an A record for
mail.testdomain.com does not exist on server B it does not resolve.
If i then specifically query Server A for mail.testdomain.com of type
CNAME, it resolves as expected. Subsequent requests against server A for
mail.testdomain.com of type any then resolve, presumably because it is
already in the cache.
Hopefully that makes sense! Has anyone had a similar issue and did you come
up with a work around? Is this expected behaviour or a bug?
This is an excellent example of why you should not forward to an auth-only
server. Use a stub zone instead. You might need to give it an empty
forwarders list, to override forwarding set in either the options or view
statements.
For example:
zone testdomain.com {
type stub;
masters { 192.168.1.1; };
forwarders { };
};
Try it, you'll like it.
Chris
This certainly seems to have solved the problem. I'm not convinced i
understand why it didn't work they way i was trying but this is a perfectly
acceptable alternative - thanks for your help!
Adam
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange behaviour resolving CNAME's via a forwarder.
I believe your original issue is due to the fact that you are sending a
recursive query via the forward to a device you said won't do recursive
queries. The cname you are asking for is not in the domain hosted by the
second server. Since it won't do recursive queries it won't resolve the end
point of the cname chain.
If you specifically ask for cname first, it caches the cname and then
further queries don't go to the second box and your first box just resolves
the end of the chain.
-Ben Croswell
On Apr 20, 2011 7:23 AM, Adam Goodall adam.good...@gmail.com wrote:
On 20 April 2011 10:42, Chris Buxton chris.p.bux...@gmail.com wrote:
On Apr 20, 2011, at 2:19 AM, Adam Goodall wrote:
However if a client queries server A for mail.testdomain.com (type any)
the request is not answered. From the logs on server B i can see that
server
A is only forwarding on a request of type A. As an A record for
mail.testdomain.com does not exist on server B it does not resolve.
If i then specifically query Server A for mail.testdomain.com of type
CNAME, it resolves as expected. Subsequent requests against server A for
mail.testdomain.com of type any then resolve, presumably because it is
already in the cache.
Hopefully that makes sense! Has anyone had a similar issue and did you
come
up with a work around? Is this expected behaviour or a bug?
This is an excellent example of why you should not forward to an
auth-only
server. Use a stub zone instead. You might need to give it an empty
forwarders list, to override forwarding set in either the options or view
statements.
For example:
zone testdomain.com {
type stub;
masters { 192.168.1.1; };
forwarders { };
};
Try it, you'll like it.
Chris
This certainly seems to have solved the problem. I'm not convinced i
understand why it didn't work they way i was trying but this is a
perfectly
acceptable alternative - thanks for your help!
Adam
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange behaviour resolving CNAME's via a forwarder.
Adam Goodall adam.good...@gmail.com wrote: This certainly seems to have solved the problem. I'm not convinced i understand why it didn't work they way i was trying but this is a perfectly acceptable alternative - thanks for your help! A server that you forward queries to is expected to be a recursive server. The servers for a stub zone are expected to be authoritative. This matters if (for example) there are delegated sub-zones for which BIND may have to handle referrals. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
