DNS Forward only/proxy server responds with SERVFAIL

We have an internal DNS server 64.104.128.236 which is accessible only within a particular subnet (10.106.x.x/16). I am building a private network (192.168.x.x/16) from which I would want to resolve the DNS queries with 64.104.128.236

So, now I have setup a Proxy server (CentOS 7.5) with interfaces –

  1. 10.106.179.30 which can access the DNS server
  2. 192.168.180.100 to communicate within private network

I have installed bind-utils on the Proxy server with following config in /etc/named.conf:

options {     listen-on port 53 { 127.0.0.1; any; };     listen-on-v6 port 53 { ::1; };     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";     recursing-file  "/var/named/data/named.recursing";     secroots-file   "/var/named/data/named.secroots";     allow-query     { localhost; any; };     recursion yes;      forwarders { 64.104.128.236; };     forward only;      dnssec-enable yes;     dnssec-validation yes; }; 

From my Client (192.168.180.81), when I try nslookup, I always get SERVFAIL

> facebook.com Server:     192.168.180.100 Address:    192.168.180.100#53  ------------     QUESTIONS:     facebook.com, type = A, class = IN     ANSWERS:     AUTHORITY RECORDS:     ADDITIONAL RECORDS: ------------ ** server can't find facebook.com: SERVFAIL 

I can see the it getting successfully resolved in my Proxy server, but this is not passed on.

[root@warmachine ~]# nslookup facebook.com Server:     64.104.128.236 Address:    64.104.128.236#53  Non-authoritative answer: Name:   facebook.com Address: 157.240.7.35 

The tcpdump on Proxy server looks thus ( Client –> Proxy –> DNS):

[root@warmachine ~]# tcpdump -n -i any host 192.168.180.81 or host 64.104.128.236 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 00:15:51.643536 IP 192.168.180.81.44537 > 192.168.180.100.domain: 49291+ A? facebook.com. (30) 00:15:51.646761 IP 10.106.179.30.rbr-discovery > 64.104.128.236.domain: 33001+% [1au] A? facebook.com. (41) 00:15:51.651612 IP 64.104.128.236.domain > 10.106.179.30.rbr-discovery: 33001- 1/2/4 A 157.240.7.35 (152) 00:15:51.652572 IP 192.168.180.100.domain > 192.168.180.81.44537: 49291 ServFail 0/0/0 (30) 00:15:51.653823 IP 192.168.180.81.43489 > 192.168.180.100.domain: 11362+ A? facebook.com. (30) 00:15:51.654216 IP 10.106.179.30.56534 > 64.104.128.236.domain: 14438+% [1au] A? facebook.com. (41) 00:15:51.659101 IP 64.104.128.236.domain > 10.106.179.30.56534: 14438- 1/2/4 A 157.240.7.35 (152) 00:15:51.659686 IP 192.168.180.100.domain > 192.168.180.81.43489: 11362 ServFail 0/0/0 (30) 

Am I approaching this the wrong way?

BIND9 SERVFAIL using dig on UBUNTU server 18

I am setting up a nextcloud+onlyoffice server on ubuntu server 18 and a LAN DNS for my office to go with it. I’m not a real IT guy but I follow tutorials and read forums. Also, being in China I don’t have google and most my searches find irrelevant answers… I still saw many people had an error similar to mine but no solution worked for me. I’m sure it’s a stupid obvious mistake but since I’m not familiar with the BIND9 syntax, I just don’t see it… Here is my named.conf.local :

    zone "plateforme.local" IN {     type master;     file "/etc/bind/zones/db.plateforme.local";     //allow-transfer{211.66.139.29;};     allow-update { none; };     allow-query { any; }; };  zone "139.66.211.in-addr-arpa" IN {     type master;     file "/etc/bind/zones/db.rev.plateforme.local";     allow-update {none;}; }; 

my db.plateforme.local :

; ; BIND data file for local loopback interface ; $  TTL    604800 @   IN  SOA ns.plateforme.local. root.plateforme.local. (                   33    ; Serial              604800     ; Refresh               86400     ; Retry             2419200     ; Expire              604800 )   ; Negative Cache TTL ;  ; name servers - NS info         NS  ns.plateforme.local.  ; name servers - adress ns  IN  A   211.66.139.29  ; name servers - A records nextcloud   IN  A   211.66.139.29 onlyoffice  IN  A   211.66.139.29 

Here is db.rev.plateforme.local :

; ; BIND reverse data file for local loopback interface ; $  TTL    604800 @   IN  SOA ns.plateforme.local. root.plateforme.local. (                   17    ; Serial              604800     ; Refresh               86400     ; Retry             2419200     ; Expire              604800 )   ; Negative Cache TTL ;  ; name servers - NS info     IN  NS  ns.plateforme.local.     IN  NS  localhost.  ; name servers - adress 29  IN  NS  ns.plateforme.local.  29  IN  PTR nextcloud.plateforme. 29  IN  PTR onlyoffice.plateforme.local. 

Here is the result of dig nextcloud.plateforme.local :

nextcloud@nextcloud-server:/etc/bind/zones$   dig nextcloud.plateforme.local. ; <<>> DiG 9.11.4-3ubuntu5.1-Ubuntu <<>> nextcloud.plateforme.local. ;; global options: +cmd ;; Got answer: ;; WARNING: .local is reserved for Multicast DNS ;; You are currently testing what happens when an mDNS query is leaked to DNS ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42787 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1  ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;nextcloud.plateforme.local.    IN  A  ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: mar. mars 12 10:25:52 HKT 2019 ;; MSG SIZE  rcvd: 55 

and the reverse dig dig -x 211.66.139.29 that surprisingly works :

nextcloud@nextcloud-server:/etc/bind/zones$   dig -x 211.66.139.29  ; <<>> DiG 9.11.4-3ubuntu5.1-Ubuntu <<>> -x 211.66.139.29 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63404 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1  ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;29.139.66.211.in-addr.arpa.    IN  PTR  ;; ANSWER SECTION: 29.139.66.211.in-addr.arpa. 0   IN  PTR nextcloud-server. 29.139.66.211.in-addr.arpa. 0   IN  PTR nextcloud-server.local.  ;; Query time: 120 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: mar. mars 12 10:39:53 HKT 2019 ;; MSG SIZE  rcvd: 121 

I’d be very thankful if someone could help… I’m setting up this server for our team of 16 teachers because I had some computer science training over a decade ago, because we have need for such server and the offer in mainland China is limited and abroad out of reach… but I do it in addition to my duties as a teacher and it is draining my free time. I would greatly appreciate the help and advice of experts. Thank you in advance for your time !

BIND SERVFAIL on common domains, restarting BIND resolves the issue

From time to time by BIND 9 fails with SERVFAIL on pretty much every query. What’s weird is that restarting BIND helps.

I turned on debugging and get this in logs:

24-Dec-2018 15:32:58.790 lame-servers: info: broken trust chain resolving 'github.com/AAAA/IN': 1.2.3.4#53 24-Dec-2018 15:32:58.790 query-errors: debug 1: client 10.0.1.163#45403 (github.com): query failed (SERVFAIL) for github.com/IN/AAAA at ../../../bin/named/query.c:7773 24-Dec-2018 15:32:58.900 resolver: debug 1: fetch: bitbucket.org/A 24-Dec-2018 15:32:58.900 resolver: debug 1: fetch: bitbucket.org/AAAA 24-Dec-2018 15:32:58.906 database: debug 1: decrement_reference: delete from rbt: 0x7fb568a19e80 bitbucket.org 24-Dec-2018 15:32:58.906 resolver: debug 1: fetch: bitbucket.org/DS 24-Dec-2018 15:32:58.907 database: debug 1: decrement_reference: delete from rbt: 0x7fb568a19e80 bitbucket.org 24-Dec-2018 15:32:58.907 resolver: debug 1: fetch: bitbucket.org/DS 24-Dec-2018 15:32:58.919 dnssec: info:   validating org/SOA: got insecure response; parent indicates it should be secure 24-Dec-2018 15:32:58.919 lame-servers: info: no valid RRSIG resolving 'bitbucket.org/DS/IN': 1.2.3.4#53 24-Dec-2018 15:32:58.928 resolver: debug 1: fetch: org/DNSKEY 24-Dec-2018 15:32:58.935 dnssec: info: validating org/DNSKEY: got insecure response; parent indicates it should be secure 24-Dec-2018 15:32:58.935 lame-servers: info: insecurity proof failed resolving 'org/DNSKEY/IN': 1.2.3.4#53 24-Dec-2018 15:32:58.947 resolver: debug 1: fetch: bitbucket.org.dlv.isc.org/DLV 24-Dec-2018 15:32:58.947 resolver: debug 1: fetch: bitbucket.org.dlv.isc.org/DLV 24-Dec-2018 15:32:58.986 dnssec: info:   validating dlv.isc.org/SOA: got insecure response; parent indicates it should be secure 24-Dec-2018 15:32:58.986 dnssec: info: validating bitbucket.org.dlv.isc.org/DLV: bad cache hit (org.dlv.isc.org/DS) 24-Dec-2018 15:32:58.986 lame-servers: info: broken trust chain resolving 'bitbucket.org.dlv.isc.org/DLV/IN': 1.2.3.4#53 24-Dec-2018 15:32:58.986 lame-servers: info: broken trust chain resolving 'bitbucket.org/A/IN': 1.2.3.4#53 24-Dec-2018 15:32:58.986 lame-servers: info: broken trust chain resolving 'bitbucket.org/AAAA/IN': 1.2.3.4#53 24-Dec-2018 15:32:58.986 query-errors: debug 1: client 10.0.1.163#54539 (bitbucket.org): query failed (SERVFAIL) for bitbucket.org/IN/A at ../../../bin/named/query.c:7773 24-Dec-2018 15:32:58.986 query-errors: debug 1: client 10.0.1.163#54539 (bitbucket.org): query failed (SERVFAIL) for bitbucket.org/IN/AAAA at ../../../bin/named/query.c:7773 24-Dec-2018 15:32:58.987 resolver: debug 1: fetch: bitbucket.org/A 24-Dec-2018 15:32:58.987 resolver: debug 1: fetch: bitbucket.org/AAAA 24-Dec-2018 15:32:58.993 dnssec: info: validating bitbucket.org/A: bad cache hit (bitbucket.org.dlv.isc.org/DLV) 24-Dec-2018 15:32:58.993 lame-servers: info: broken trust chain resolving 'bitbucket.org/A/IN': 1.2.3.4#53 24-Dec-2018 15:32:58.993 query-errors: debug 1: client 10.0.1.163#54539 (bitbucket.org): query failed (SERVFAIL) for bitbucket.org/IN/A at ../../../bin/named/query.c:7773 24-Dec-2018 15:32:58.994 dnssec: info: validating bitbucket.org/AAAA: bad cache hit (bitbucket.org.dlv.isc.org/DLV) 24-Dec-2018 15:32:58.994 lame-servers: info: broken trust chain resolving 'bitbucket.org/AAAA/IN': 1.2.3.4#53 24-Dec-2018 15:32:58.994 query-errors: debug 1: client 10.0.1.163#54539 (bitbucket.org): query failed (SERVFAIL) for bitbucket.org/IN/AAAA at ../../../bin/named/query.c:7773 24-Dec-2018 15:33:23.774 resolver: debug 1: fetch: 43.249.96.191.in-addr.arpa/PTR 24-Dec-2018 15:33:23.780 resolver: debug 1: fetch: 249.96.191.in-addr.arpa.dlv.isc.org/DLV -- 24-Dec-2018 15:33:33.502 lame-servers: info: broken trust chain resolving '170.81.36.185.in-addr.arpa/PTR/IN': 1.2.3.4#53 24-Dec-2018 15:33:33.502 query-errors: debug 1: client 10.5.1.181#58654 (170.81.36.185.in-addr.arpa): query failed (SERVFAIL) for 170.81.36.185.in-addr.arpa/IN/PTR at ../../../bin/named/query.c:7773 24-Dec-2018 15:33:35.271 resolver: debug 1: fetch: bitbucket.org/A 24-Dec-2018 15:33:35.286 dnssec: info: validating bitbucket.org/A: bad cache hit (bitbucket.org.dlv.isc.org/DLV) 24-Dec-2018 15:33:35.286 lame-servers: info: broken trust chain resolving 'bitbucket.org/A/IN': 1.2.3.4#53 24-Dec-2018 15:33:35.286 query-errors: debug 1: client 10.0.1.163#59171 (bitbucket.org): query failed (SERVFAIL) for bitbucket.org/IN/A at ../../../bin/named/query.c:7773 24-Dec-2018 15:33:51.394 resolver: debug 1: fetch: 118.120.54.92.in-addr.arpa/PTR 24-Dec-2018 15:33:51.401 database: debug 1: decrement_reference: delete from rbt: 0x7fb50b313268 118.120.54.92.in-addr.arpa -- 24-Dec-2018 15:33:56.771 lame-servers: info: broken trust chain resolving '1.debian.pool.ntp.org/AAAA/IN': 1.2.3.4#53 24-Dec-2018 15:33:56.771 query-errors: debug 1: client 10.0.1.163#59947 (1.debian.pool.ntp.org): query failed (SERVFAIL) for 1.debian.pool.ntp.org/IN/AAAA at ../../../bin/named/query.c:7773 24-Dec-2018 15:34:02.364 resolver: debug 1: fetch: bitbucket.org/A 24-Dec-2018 15:34:02.371 dnssec: info: validating bitbucket.org/A: bad cache hit (bitbucket.org.dlv.isc.org/DLV) 24-Dec-2018 15:34:02.371 lame-servers: info: broken trust chain resolving 'bitbucket.org/A/IN': 1.2.3.4#53 24-Dec-2018 15:34:02.371 query-errors: debug 1: client 10.0.1.90#39850 (bitbucket.org): query failed (SERVFAIL) for bitbucket.org/IN/A at ../../../bin/named/query.c:7773 24-Dec-2018 15:34:02.751 resolver: debug 1: fetch: 159.47.143.90.in-addr.arpa/PTR 24-Dec-2018 15:34:02.896 database: debug 1: decrement_reference: delete from rbt: 0x7fb50b313268 159.47.143.90.in-addr.arpa -- 24-Dec-2018 15:34:03.927 resolver: debug 1: fetch: 159.47.143.90.xbl.spamhaus.org/TXT 24-Dec-2018 15:34:15.106 resolver: debug 1: fetch: 20.81.36.185.in-addr.arpa/PTR 24-Dec-2018 15:34:22.655 resolver: debug 1: fetch: bitbucket.org/A 24-Dec-2018 15:34:22.664 dnssec: info: validating bitbucket.org/A: bad cache hit (bitbucket.org.dlv.isc.org/DLV) 24-Dec-2018 15:34:22.664 lame-servers: info: broken trust chain resolving 'bitbucket.org/A/IN': 5.6.7.8#53 24-Dec-2018 15:34:22.664 query-errors: debug 1: client 127.0.0.1#49536 (bitbucket.org): query failed (SERVFAIL) for bitbucket.org/IN/A at ../../../bin/named/query.c:7773 24-Dec-2018 15:34:26.860 resolver: debug 1: fetch: 2.debian.pool.ntp.org/AAAA 24-Dec-2018 15:34:26.860 resolver: debug 1: fetch: 2.debian.pool.ntp.org/A 

Why is that happening and how can I fix that? And why restarting BIND helps?

OS: Debian 9.6 amd64.

BIND:

ii  bind9                                         1:9.10.3.dfsg.P4-12.3+deb9u4                amd64        Internet Domain Name Server ii  bind9-host                                    1:9.10.3.dfsg.P4-12.3+deb9u4                amd64        Version of 'host' bundled with BIND 9.X ii  bind9utils                                    1:9.10.3.dfsg.P4-12.3+deb9u4                amd64        Utilities for BIND ii  libbind9-140:amd64                            1:9.10.3.dfsg.P4-12.3+deb9u4                amd64        BIND9 Shared Library used by BIND