Problem with forward zone in view
Steven Carr
sjcarr at gmail.com
Sun Sep 8 09:57:15 UTC 2013
Using +trace will give you the exact response you are seeing. +trace
uses the values returned by the parent for the next part of the query
(it will bypass your internal DNS server and go straight to the
Internet root and work down the hierarchy, so any forwarding rules in
BIND are ignored).
You will need to perform a packet capture on the DNS server itself,
from a client they query for records in domain2.com and then analyse
the packet capture to see what happened when the query came in.
Just as a test, also make sure that you can query the domain2.com
domain manually from the DNS server.
Steve
On 8 September 2013 10:24, Carol Overes <carol at overes.net> wrote:
> All,
>
> I have tried to search on the web for a solution for the following
> problem, but I didn succeed.
>
> My goal:
> I run an internal DNS server ('10.10.10.1'), which is authoritive for an
> internal domain ('domain1.com'), and allows recursion for internal
> networks. We have another internal nameserver (192.168.1.1), which is
> authoritive for another internal domain ('domain2.com').
>
> On 10.10.10.1, I would like to forward requests for 'domain2.com' to
> server 192.168.1.1.
>
>
> My setup:
> I am using views on 10.10.10.1. The server runs on version 9.8.1-p1.
> Below is the relevant view, including my forwarding statement, and
> the relevant acl:
>
> acl "trusted" {
> 192.168.0.0/24;
> 127.0.0.1/32;
> localhost;
> };
>
>
> view "internal-in" in {
> match-clients { trusted; };
> additional-from-auth yes;
> additional-from-cache yes;
>
> allow-transfer {
> none;
> };
>
> allow-query {
> trusted;
> };
>
> allow-recursion {
> trusted;
> };
>
> zone "domain2.com" {
> type forward;
> forwarders { 192.168.1.1; };
> };
>
> zone "." in {
> type hint;
> file "/<some_path_to_file>/db.root";
> };
>
> zone "domain1.com" in {
> type master;
> file "/<some_path_to_file>/cdc.foundstone.com.zone";
> };
> };
>
> The problem:
> If I perform a query from a network, part of the trusted acl, I can see
> that the query is send to root servers and then to the .com servers:
>
> $ dig domain2.com NS +trace
>
> ; <<>> DiG 9.8.1-P1 <<>> domain2.com NS +trace
> ;; global options: +cmd
> . 518350 IN NS g.root-servers.net.
> . 518350 IN NS d.root-servers.net.
> . 518350 IN NS f.root-servers.net.
> . 518350 IN NS a.root-servers.net.
> . 518350 IN NS m.root-servers.net.
> . 518350 IN NS b.root-servers.net.
> . 518350 IN NS i.root-servers.net.
> . 518350 IN NS j.root-servers.net.
> . 518350 IN NS h.root-servers.net.
> . 518350 IN NS e.root-servers.net.
> . 518350 IN NS l.root-servers.net.
> . 518350 IN NS k.root-servers.net.
> . 518350 IN NS c.root-servers.net.
> ;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 2435 ms
>
> com. 172800 IN NS a.gtld-servers.net.
> com. 172800 IN NS b.gtld-servers.net.
> com. 172800 IN NS c.gtld-servers.net.
> com. 172800 IN NS d.gtld-servers.net.
> com. 172800 IN NS e.gtld-servers.net.
> com. 172800 IN NS f.gtld-servers.net.
> com. 172800 IN NS g.gtld-servers.net.
> com. 172800 IN NS h.gtld-servers.net.
> com. 172800 IN NS i.gtld-servers.net.
> com. 172800 IN NS j.gtld-servers.net.
> com. 172800 IN NS k.gtld-servers.net.
> com. 172800 IN NS l.gtld-servers.net.
> com. 172800 IN NS m.gtld-servers.net.
>
> I have also sniffed UDP packets on the wire. But I don see any packets
> going towards 192.168.1.1.
>
> Question:
> Any idea what is wrong in my configuration?
>
> Thanks in advance for your help!
>
> Regards,
>
> Carol
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> 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
More information about the bind-users
mailing list