About query response on a view
Darcy Kevin (FCA)
kevin.darcy at fcagroup.com
Wed Dec 9 23:42:41 UTC 2015
Well, there some things that are not clear from your message:
A) when you do your "dig", what is your source address, what is your destination address, and what is your match-clients ACL for the internal view? These values have a bearing on what view you're going to match. Seems like you're matching the wrong view - the external one, which has no recursion -- and getting a mere "referral" for www.google.com<http://www.google.com> (root nameservers) instead of an answer.
B) you say your internal view has "forwarders". Why? What's the purpose of that? To where are you forwarding? To public resolvers like Google? If you're forwarding to *yourself*, then either you created a forwarding loop, or (if you excluded your own IP in the match-clients ACL of the internal view) the forwarded query is matching the wrong view, without (as you show below) any allow-recursion exception, so, again, as expected you're getting a mere referral instead of an answer. Unless you're forwarding to an external entity that provides some added value (e.g. enhanced performance/availability, DNSSEC validation, blacklisting of known malicious domains, anti-forgery measures, etc.) consider just replacing the forwarder configuration with an appropriate "hints" zone definition in your internal view and letting it resolve names iteratively. You didn't say what platform you were migrating from, but if it was forwarding-centric, understand that forwarding is much less heavily used in the BIND world.
NOTE: if you want to publically post ACLs containing internal address ranges, it's fine to obfuscate those ranges, as long as you preserve their "essence", e.g. large-versus-small, public-versus-private-versus-localhost. It's only when folks obfuscate names and addresses that are publically-visible anyway, that the obfuscation sometimes gets in the way of diagnosing the problem and folks on this list get somewhat ornery. For the ultimate in Internet Engineering etiquette, use addresses based on the RFC 5737 "documentation only" ranges.
- Kevin
From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Okan Bostan
Sent: Wednesday, December 09, 2015 4:11 AM
To: bind-users at lists.isc.org
Subject: About query response on a view
Hello List,
We are planning to migrate to Bind dns, I'm a bit newbie.
In our design we have two views; int and ext.
As internal view, recursion is on and we have our internal zones & forwarders. I have no problem with internal view.
In external view, recursion in no. Also have some zones. In testing external view, I can query the records in zones, thats not a problem also.
But when I try to query, for example www.google.com<http://www.google.com> it returns the root servers records by dig.
;; QUESTION SECTION:
;ww. IN A
;; AUTHORITY SECTION:
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
And status: NOERROR
also in nslookup:
Name: www.google.com<http://www.google.com>
Served by:
- E.ROOT-SERVERS.NET
- F.ROOT-SERVERS.NET
- J.ROOT-SERVERS.NET
- G.ROOT-SERVERS.NET
- D.ROOT-SERVERS.NET
- C.ROOT-SERVERS.NET
- A.ROOT-SERVERS.NET
But in our existing DNS enviroment, I get status: SERVFAIL to same query.
Is this a normal behaviour ? How can I disable this Authority section with root server NS records?
My external view:
view "EXTERNAL" {
match-clients {"any";};
allow-query-on {ext_ip; };
recursion no;
allow-recursion { none;};
#Include SLAVE zones
include "slave.zones";
#Include REVERSE zones
include "reverse.zones";
};// view EXTERNAL
Regards,
Okan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151209/5174305d/attachment-0001.html>
More information about the bind-users
mailing list