1

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?

  • Did you look at the logfiles? A SERVFAIL is a pretty serious error that comes either from a misconfiguration of some sort (in which case it should be visible from looking at the logfiles) or a DNSSEC related problem. – Patrick Mevzek Jun 17 at 2:40
0

So it turned out to be a DNSSEC problem. Updated the following configs in /etc/named.conf and it is all working good now

dnssec-enable no;
dnssec-validation no;
  • uff, I am sorry but I have to... Yes, this will help but why not to set it up properly? DNSSEC has some purpose and in case the signature is available it should be used. But anyway as hot fix ... good investigation and nice solution ;-). – Kamil J Jun 18 at 13:41
  • I'm still on it Kamil. Its one of my first hands on with DNS setups. I shall definitely post why dnssec was troubling in this case as soon as I find it out – engima.bphc Jun 20 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.