0

I have set up a Bind 9.9.4 nameserver on Centos7. It includes a single zone with static IPs for my business LAN. I have it set up to forward to Google's public DNS for everything else. Everything seemed to be working (both local and internet name resolution) until I realized that I had no access to linkedin.com. LinkedIn appears to be set up with a cname chain, and when I query my local server it only does half of the steps required to resolve the IP.

If I directly do a lookup against public Google DNS I get the correct answer:

>>nslookup www.linkedin.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.linkedin.com    canonical name = 2-01-2c3e-003c.cdx.cedexis.net.
2-01-2c3e-003c.cdx.cedexis.net  canonical name = any-na.www.linkedin.com.
Name:   any-na.www.linkedin.com
Address: 108.174.10.10

However, if I go through my DNS server, it appears not to resolve the second cname entry in the chain, instead returning 0.0.0.0

>>nslookup www.linkedin.com 10.26.2.4
Server:     10.26.2.4
Address:    10.26.2.4#53

Non-authoritative answer:
www.linkedin.com    canonical name = 2-01-2c3e-003c.cdx.cedexis.net.
Name:   2-01-2c3e-003c.cdx.cedexis.net
Address: 0.0.0.0

I Googled this for several hours trying various configuration options in named.conf but haven't been able to figure out why this is happening. Every time I made changes to named.conf I did the following to be sure I wasn't getting stale results:

>>sudo systemctl reload named
>>sudo systemctl restart named
>>sudo rndc flush
>>sudo rndc reload

If I directly attempt to resolve the IP address of 2-01-2c3e-003c.cdx.cedexis.net I get 0.0.0.0 regardless of whether I target my or Google's DNS server:

>>nslookup 2-01-2c3e-003c.cdx.cedexis.net 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53    
Name:   2-01-2c3e-003c.cdx.cedexis.net
Address: 0.0.0.0

>>nslookup 2-01-2c3e-003c.cdx.cedexis.net 10.26.2.4
Server:     10.26.2.4
Address:    10.26.2.4#53
Non-authoritative answer:
Name:   2-01-2c3e-003c.cdx.cedexis.net
Address: 0.0.0.0

I believe this is an issue with my configuration, but I haven't been able to determine exactly what is amiss. Following is my named.conf. Any help would be greatly appreciated:

acl "trusted" { 10.26.2/24; 10.28.2/24; localhost; };

options {
  listen-on port 53 { 127.0.0.1; 10.26.2.4; };
  #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";

  forwarders { 8.8.8.8; 8.8.4.4; };
  forward first;

  recursion yes;

  allow-query { trusted; };

  allow-transfer  { 10.26.2.5; };

  dnssec-enable yes;
  dnssec-validation no;

  #auth-nxdomain no;

  /* Path to ISC DLV key */
  bindkeys-file "/etc/named.iscdlv.key";

  managed-keys-directory "/var/named/dynamic";

  pid-file "/run/named/named.pid";
  session-keyfile "/run/named/session.key";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
  type hint;
  file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/named/named.conf.local";

Here is some additional debugging info.

dig against my nameserver (10.26.2.4):

>>dig @10.26.2.4 www.linkedin.com

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> @10.26.2.4 www.linkedin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26538
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.linkedin.com.      IN  A

;; ANSWER SECTION:
www.linkedin.com.   1   IN  CNAME   2-01-2c3e-003c.cdx.cedexis.net.
2-01-2c3e-003c.cdx.cedexis.net. 0 IN    A   0.0.0.0

;; AUTHORITY SECTION:
.           141169  IN  NS  k.root-servers.net.
.           141169  IN  NS  i.root-servers.net.
.           141169  IN  NS  b.root-servers.net.
.           141169  IN  NS  c.root-servers.net.
.           141169  IN  NS  g.root-servers.net.
.           141169  IN  NS  l.root-servers.net.
.           141169  IN  NS  e.root-servers.net.
.           141169  IN  NS  h.root-servers.net.
.           141169  IN  NS  m.root-servers.net.
.           141169  IN  NS  f.root-servers.net.
.           141169  IN  NS  a.root-servers.net.
.           141169  IN  NS  d.root-servers.net.
.           141169  IN  NS  j.root-servers.net.

;; Query time: 31 msec
;; SERVER: 10.26.2.4#53(10.26.2.4)
;; WHEN: Sat Jan 27 14:03:27 MST 2018
;; MSG SIZE  rcvd: 313

dig against Google's DNS:

>>dig @8.8.8.8 www.linkedin.com

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.2 <<>> @8.8.8.8 www.linkedin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17261
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.linkedin.com.      IN  A

;; ANSWER SECTION:
www.linkedin.com.   1   IN  CNAME   2-01-2c3e-003c.cdx.cedexis.net.
2-01-2c3e-003c.cdx.cedexis.net. 1 IN    CNAME   any-na.www.linkedin.com.
any-na.www.linkedin.com. 1  IN  A   108.174.10.10

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jan 27 14:03:47 MST 2018
;; MSG SIZE  rcvd: 126
  • Various considerations: it is not a good idea to mix recursive and authoritative in the same instance; why forwarding to 8.8.8.8 and not recursing locally? Do you use an RPZ ? The resolution of www.linkedin.com changes based on where you query from. – Patrick Mevzek Jan 28 '18 at 15:47
  • If I remove the forwarders { 8.8.8.8; 8.8.4.4; }; and forward first; lines then I get SERVFAIL on any internet domains (i.e. not on lan.sequent.ltd). That is the motivation for including those lines. /var/named/named.ca is present and unmodified from the bind install. My understanding is that anything matching the default zone "." should be resolved starting with the root nameservers listed in named.ca. Does it make sense that I am getting SERVFAIL when forwarding isn't enabled? – rjshera Feb 1 '18 at 0:18
  • Not related probably but you should remove the DLV thing, this is now deprecated. – Patrick Mevzek Feb 4 '18 at 20:57
0

First thing you probably want to do is add an allow-recursion statement such as allow-recursion {trusted;};

  • Thanks for the comment. I added the allow-recursion { trusted; }; statement and restarted/reloaded, but unfortunately this didn't fix the issue. – rjshera Jan 28 '18 at 1:41

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.