About query response on a view
Mark Elkins
mje at posix.co.za
Thu Dec 10 11:10:39 UTC 2015
On Thu, 2015-12-10 at 08:53 +0000, Okan Bostan wrote:
> Hi,
> Firstly thanks for all the responses, giving more details about our
> config:
>
> Internal view: Internal DNS service for the internal clients. Accepts
> requests from internal IP, Recursion is on, forwarding the out of zone
> queries to our cache-only DNS servers. Also serves some zone
> information.
> External view: Authoritative DNS service for our domain. Accepts
> requests from external IP, No recursion,
>
> Also we will consider to separate the recursive and authoritative
> servers, but separating them with views isn’t a good solution?
>
> @Eray Aslan, additional-from-cache and additional-from-auth settings
> did the trick, now server gives “query refused”
>
> @Barry Finkel, yes I typed dig ww. At that point, every recursive
> query gives the same output. But thanks for the info.
>
> @Mark Elkins,In our setup, we have one machine with 2 IP addresses.
> (option 3) We are planning to use DNNSEC, Could you give more
> information about the possible DNSSEC problem?
Resolver Problem:
DNSSEC requires an appropriately configured recursive resolver that can
chase answers and signatures down from the root. It should not also be
authoritative (ie have Zones). To the best of my knowledge, answers from
Zones that the Software instance is authoritative for will never be
DNSSEC validated (AD bit set). This might not initially seem like a
problem (you trust your own setup) but things like DANE will not work,
ie DANE in an SMTP environment.
Resolver Solution:
Move the Internal Views of Authoritaive Data (Internal Zones) to a Third
IP address.
Run the Recursive Server on the "Resolver Only" IP address, perhaps use
UNBOUND (I like BIND - but multiple instances of BIND is going to become
administratively painful). It MUST be the only Port 53 application on
that 3rd IP address. Basically, copy the root KSK into a file owned by
unbound and tell unbound to use that file.
# cd /etc/unbound (whatever)
# dig . dnskey | grep 257 > root-anchors.txt
# chown unbound: root.anchors.txt
...then add "auto-trust-anchor-file: root.anchors.txt" to unbound.conf
(Confirm the authenticity of the root dnskey/KSK from
https://dnssec.co.za and other sources)
DNSSEC Signing your Zones is easy enough but I've never tried to sign an
Internal and External version of the same Zone. Why complicate life.
You'll have to hand-roll a solution.
> I fix the referral problem with Eray’s solution.
>
> @Kevin Darcy, (a) match-clients is a C class network address space.
> (b) I explained it above. Thanks for the detailed explanation and the
> note.
>
> Regards,
>
> Okan Bostan
>
>
>
> From: bind-users-bounces at lists.isc.org
> [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Darcy Kevin
> (FCA)
> Sent: Thursday, December 10, 2015 1:43 AM
> To: bind-users at lists.isc.org <bind-users at isc.org>
> Subject: RE: About query response on a view
>
>
>
>
> 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”
> forwww.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 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
>
> 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.
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark James ELKINS - Posix Systems - (South) Africa
mje at posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5667 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151210/b5a9756a/attachment.bin>
More information about the bind-users
mailing list