DNS not working outside of my Bind server

[root@dns01 etc]# nslookup
> vc03.example.com
Server:         192.168.40.33
Address:        192.168.40.33#53

Name:   vc03.example.com
Address: 192.168.20.5
>

when i tried to resolve this from my windows server, i am getting the following.

I am able to ping and did telnet test. not sure why this fails


C:\Windows\system32>nslookup
Default Server:  UnKnown
Address:  192.168.40.33

>
>
> vc03.example.com
Server:  UnKnown
Address:  192.168.40.33

*** UnKnown can't find vc03.example.com: No response from server
linuxpersonAsked:
Who is Participating?
 
linuxpersonAuthor Commented:
i fixed the issue. it was related to the ip address already defined in the main configuration file.
0
 
linuxpersonAuthor Commented:
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
        #listen-on port 53 { 127.0.0.1; };
        #listen-on-v6 port 53 { 127.0.0.11; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { localhost; 192.168.1.0/24; 192.168.20.0/24; 192.168.40.0/24; };
        allow-transfer     { localhost; 192.168.1.0/24; 192.168.20.0/24; 192.168.40.0/24; };
        recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";
        managed-keys-directory "/var/named/dynamic";
};

logging {
        channel default_debug {
                file "/var/log/querylog";
                #file "data/named.run";
                severity dynamic;
        };
};

# change all from here

view "internal" {
        match-clients {
                localhost;
                192.168.1.0/24;
        };
        zone "." IN {
                type hint;
                file "named.ca";
        };
        zone "example.com" IN {
                type master;
                file "example.com.lan";
                allow-update { none; };
        };
        zone "1.168.192.in-addr.arpa" IN {
                type master;
                file "1.168.192.db";
                allow-update { none; };
        };
        zone "20.168.192.in-addr.arpa" IN {
                type master;
                file "20.168.192.db";
                allow-update { none; };
        };
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
};
0
 
andreasSystem AdminCommented:
does the (host) firewall, where the bind server is running, does allow access to ports 53 UDP and TCP for the subnets you want to access the nameserver?
0
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

 
DrAtomicCommented:
Your basic misconception is with your initial use of telnet for testing the open port. Telnet is TCP based. DNS uses port 53 (by default) on UDP. So basicly you confirmed that you had port 53 open in TCP but you never tested UDP. A good way of testing an open UDP port is doing so with an UDP ping tool such as psping (https://technet.microsoft.com/en-us/sysinternals/jj729731.aspx). In this case the syntax would be psping -4 -u -n 1 192.168.40.33:53

If that fails check your firewall to make sure you are not blocking 53 udp.

Another testing tip is to use dig instead of nslookup as the syntax for dig is far more logical and quicker to use as a result.

How to install DIG on Windows 8.1 64bits: http://www.blog.paranoidpenguin.net/2014/09/how-to-install-dig-on-a-windows-8-1-64-bit-system/

Using DIG: http://www.danesparza.net/2011/05/using-the-dig-dns-tool-on-windows-7/

Some basic commands:

dig @192.168.40.33 vc03.example.com A (outputs the A record)
dig @192.168.40.33 example.com SOA (outputs soa record)
dig @192.168.40.33 example.com NS (outputs nameservers)
0
 
linuxpersonAuthor Commented:
[root@dns01 etc]# service named stop
Stopping named: .                                          [  OK  ]

C:\Windows\system32>telnet 192.168.40.33 53
Connecting To 192.168.40.33...Could not open connection to the host, on port 53: Connect failed

[root@dns01 etc]# service named start
Starting named:                                            [  OK  ]

I did telnet with port 53. see attached screen shot.

Please explain me how this is possible?
0
 
linuxpersonAuthor Commented:
C:\PSTools>psping.exe -4 -u -n 1 192.168.40.33:53

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 192.168.40.33:53:
2 iterations (warmup 1) connecting test:
Connecting to 192.168.40.33:53 (warmup): 207.13ms
Connecting to 192.168.40.33:53: 5.80ms

TCP connect statistics for 192.168.40.33:53:
  Sent = 1, Received = 1, Lost = 0 (0% loss),
  Minimum = 5.80ms, Maximum = 5.80ms, Average = 5.80ms
0
 
linuxpersonAuthor Commented:
C:\>dig @192.168.40.33 vc03.example.com A

; <<>> DiG 9.10.2 <<>> @192.168.40.33 vc03.example.com A
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
0
 
linuxpersonAuthor Commented:
I even tried this dig command is not able to resolve.

C:\>dig @8.8.8.8 yahoo.com A

; <<>> DiG 9.10.2 <<>> @8.8.8.8 yahoo.com A
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
0
 
MazdajaiCommented:
Is this a new DNS setup? Has it been working before? Is firewall running on the bind server?
0
 
linuxpersonAuthor Commented:
no ip tables running

[root@dns01 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
0
 
gheistCommented:
By commenting out listen-on you made it use default configuration, exactly same as you commented out.
you must leave at least listen-on port 53; to make it work.
0
 
DrAtomicCommented:
Your telnet to port 53 tcp gets a response because BIND also listens on port 53 tcp for the purpose of zone transfers, queries or lookups however are 53 udp.

The psping response indicates that the BIND server is indeed listening on 53 udp, for clarity sake (if you ever review your named.conf on a later date) I would uncomment the #listen-on port 53 { 127.0.0.1; }; entry and expand it with the ip addresses the server is supposed to listen on.

Both dig commands indicate that they send out the request just fine but do not receive a response.

Now the dig @8.8.8.8 yahoo.com A response or lack thereof is where it is getting interesting, this test basically bypasses your bind server and does a direct query from the workstation you used to the google dns server. This should have worked fine. Since it didnt it indicates that there is a firewall restriction in your network preventing the outbound 53 udp query or it's response. Somewhere the udp packets are getting dropped. This will need to be resolved before fixing the BIND issue as the issue may very well be the same.

Do you have another forward lookup dns server in your network? What are the firewall rules for that one? Are the udp packets being dropped on a router? Are the responses being forwarded to a single server inside your network?
0
 
linuxpersonAuthor Commented:
found the solution myself
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.