Problem with forward zone in view
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 "//db.root";
};
zone "domain1.com" in {
type master;
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem with forward zone in view
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 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 "//db.root";
> };
>
> zone "domain1.com" in {
> type master;
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/l
Re: Problem with forward zone in view
Hi Steve, Thanks for your reponse. On Sun, Sep 08, 2013 at 10:57:15AM +0100, Steven Carr wrote: > 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 now I performed a packet capture, to check what the response is when a client queries domain2.com. I can see that the response results in a NXDomain from one of the authoritive .com TLD servers. And I don't see any packets going towards 192.168.1.1. > Just as a test, also make sure that you can query the domain2.com > domain manually from the DNS server. I get the same result, if I log on to the internal nameserver 10.10.10.1, and run the same query. However I am able to perform any other recursive queries, or queries for domain1.com. 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem with forward zone in view
On 09/08/2013 11:38 AM, Carol Overes wrote: Hi Steve, Thanks for your reponse. On Sun, Sep 08, 2013 at 10:57:15AM +0100, Steven Carr wrote: 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 now I performed a packet capture, to check what the response is when a client queries domain2.com. I can see that the response results in a NXDomain from one of the authoritive .com TLD servers. And I don't see any packets going towards 192.168.1.1. You're not understanding: +trace is done client-side, and from the top-down. It doesn't honour any forwarders set server-side. It also doesn't replicate what a real recursive client does, so it's not a good test. What happens if you test without +trace? Just do: dig @10.x.x.x www.domain2.com Ignore +trace - it's not useful in this situation. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem with forward zone in view
Hi Phil, Apologies if my approach was not clear, after Steve's mail. But I tested by using dig without the +trace option. I have tested the following from an IP, which is accepted via the trusted ACL: dig @10.10.10.1 www.domain2.com A dig @10.10.10.1 domain2.com NS And directly from the internal DNS server 10.10.10.1: dig @127.0.0.1 www.domain2.com A dig @127.0.0.1 domain2.com NS Regards, Carol On Sun, Sep 08, 2013 at 11:54:34AM +0100, Phil Mayers wrote: > You're not understanding: > > +trace is done client-side, and from the top-down. It doesn't honour > any forwarders set server-side. It also doesn't replicate what a > real recursive client does, so it's not a good test. > > What happens if you test without +trace? Just do: > > dig @10.x.x.x www.domain2.com > > Ignore +trace - it's not useful in this situation. -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem with forward zone in view
On 8 September 2013 12:06, Carol Overes wrote: > Apologies if my approach was not clear, after Steve's mail. But I tested > by using dig without the +trace option. I have tested the following from > an IP, which is accepted via the trusted ACL: > > dig @10.10.10.1 www.domain2.com A > dig @10.10.10.1 domain2.com NS > > And directly from the internal DNS server 10.10.10.1: > > dig @127.0.0.1 www.domain2.com A > dig @127.0.0.1 domain2.com NS In order to help further you're going to have to post real domain names and the full unmodified output of command+response from dig so we can see the fully response. Also, if you can, retake the packet capture and then filter out only DNS packets and upload the capture somewhere so we can take a look at the packets. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem with forward zone in view
On 2013-09-08 07:06, Carol Overes wrote: Hi Phil, Apologies if my approach was not clear, after Steve's mail. But I tested by using dig without the +trace option. I have tested the following from an IP, which is accepted via the trusted ACL: dig @10.10.10.1 www.domain2.com A dig @10.10.10.1 domain2.com NS And directly from the internal DNS server 10.10.10.1: dig @127.0.0.1 www.domain2.com A dig @127.0.0.1 domain2.com NS ... Carol Overes, And the results were ... ??? Joe Yao ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
