Я установил сервер имен Bind 9.9.4 на Centos7. Он включает одну зону со статическими IP-адресами для моей бизнес-сети. Я настроил его для пересылки на общедоступный DNS Google для всего остального. Казалось, все работает (как локальное, так и интернет-разрешение имен), пока я не понял, что у меня нет доступа к linkedin.com. LinkedIn, похоже, настроен с помощью цепочки cname, и когда я запрашиваю свой локальный сервер, он выполняет только половину шагов, необходимых для разрешения IP.
Если я выполняю поиск в общедоступном DNS-сервере Google, я получаю правильный ответ:
>>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
Однако, если я прохожу через свой DNS-сервер, он, похоже, не разрешает вторую запись cname в цепочке, вместо этого возвращает 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
Я искал это в течение нескольких часов, пробуя различные параметры конфигурации в named.conf, но не мог понять, почему это происходит. Каждый раз, когда я вносил изменения в named.conf, я делал следующее, чтобы убедиться, что не получаю устаревшие результаты:
>>sudo systemctl reload named
>>sudo systemctl restart named
>>sudo rndc flush
>>sudo rndc reload
Если я напрямую попытаюсь разрешить IP-адрес 2-01-2c3e-003c.cdx.cedexis.net я получил 0.0.0.0 независимо от того, нацелен ли я на свой DNS-сервер или на DNS-сервер Google:
>>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
Я считаю, что это проблема моей конфигурации, но я не смог точно определить, что не так. Ниже мой named.conf. Любая помощь будет принята с благодарностью:
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";
Вот дополнительная информация об отладке.
копаться на моем сервере имен (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
копаться в DNS Google:
>>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
Первое, что вы, вероятно, захотите сделать, это добавить оператор разрешения рекурсии, например allow-recursion {trusted;};