DNS not working outside of my Bind server

//
// 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";
};

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?

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)

[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?

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

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

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

Is this a new DNS setup? Has it been working before? Is firewall running on the bind server?

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

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.

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?

found the solution myself