Заранее прошу прощения за этот вопрос новичка. Я прибегал к вопросу, потому что не могу найти достаточно тесно связанных запросов * в этой сети или где-либо еще, а BIND 9.9 ARM не совсем удобен для новичков.
* Я должен сказать, что нашел множество связанных запросов, но их ответы, как правило, включали исправления синтаксиса и тому подобное.
Во всяком случае, мой менеджер пытается настроить программное обеспечение для автоматизации маркетинга для нашего веб-сайта. Он попросил меня добавить записи CNAME, MX и TXT в файл зоны домена. Мы используем BIND 9 в системе Debian 8.
Я примерно понимаю процесс обновления файлов зоны. Я знаю, что мне нужно увеличить серийный номер файла, и я знаю, как перезагрузить зону, перезапустить BIND и т. Д.
Я также понимаю, что могу проверить синтаксис файла зоны с помощью named-checkzone
.
Чтобы проиллюстрировать ситуацию, вот детальный макет нашего файла зоны:
$TTL 300
@ IN SOA ns1.example.com.
jack.example.com. (
2017122708 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
10800 ) ; Minimum
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
ns1.example.com. IN A 199.195.xxx.yyy
ns2.example.com. IN A 199.195.xxx.yyy
ipv4.example.com. IN A 199.195.xxx.yyy
example.com. IN A 199.195.xxx.yyy
remote.example.com. IN A 173.9.zz.ccc
ftp.example.com. IN CNAME example.com.
www.example.com. IN CNAME example.com.
@ IN MX 0 example-com.mail.protection.outlook.com.
autodiscover IN CNAME autodiscover.outlook.com.
sip IN CNAME sipdir.online.lync.com.
lyncdiscover IN CNAME webdir.online.lync.com.
msoid IN CNAME clientconfig.microsoftonline-p.net.
enterpriseregistration IN CNAME enterpriseregistration.windows.net.
enterpriseenrollment IN CNAME enterpriseenrollment.manage.microsoft.com.
_dmarc.example.com. IN TXT "v=DMARC1; p=none"
example.com. IN TXT "v=spf1 +a +mx +a:example.com include:spf.protection.outlook.com -all"
_sip._tls IN SRV 100 1 443 sipdir.online.lync.com.
_sipfederationtls._tcp IN SRV 100 1 5061 sipfed.online.lync.com.
; I've been directed to add the records below:
34783aoauth._domainkey.example.com. IN CNAME dkim.act-on.com.
mailer.example.com. IN TXT "v=spf1 include:_spf.act-on.net -all"
mailer.example.com. IN MX 10 est-mta.b2b-mail.net.
marketing.example.com. IN CNAME example.actonservice.com.
Мне было сказано добавить последние четыре записи. Исходя из моего базового понимания DNS, я полагаю, что пытаюсь назначить, например, 34783aoauth._domainkey.example.com
как псевдоним dkim.act-on.com
. Итак, я подумал, что, если я правильно обновил зону в соответствии с описанными выше методами, я мог бы запустить nslookup
вот так:
jack@example:~$ nslookup 34783aoauth._domainkey.example.com
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find 34783aoauth._domainkey.example.com: NXDOMAIN
Вместо этого я получаю NXDOMAIN
ошибка. Я предположил, что это нехорошо.
Итак, я полагаю, вы могли бы резюмировать мой вопрос как как я могу устранить неполадки в моей конфигурации, чтобы разрешить эту запись CNAME (плюс те другие 3 записи)? Кроме того, как мне проверить правильность разрешения? Был мой nslookup
подход подходящий? Было бы лучше использовать dig
, например?
Я понимаю, что весь файл зоны представляет собой огромный беспорядок. Первоначально я установил его сам, и, имея опыт разработки программного обеспечения, я не часто занимаюсь подобным системным администрированием, но до сих пор он работал достаточно хорошо.
Одна вещь, которая меня беспокоит, - это вывод named-checkzone
:
jack@example:~$ sudo named-checkzone example.com /etc/bind/zones/master/db.example.com
zone example.com/IN: 'example.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record
zone example.com/IN: 'mailer.example.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record
zone example.com/IN: loaded serial 2017122708
OK
Кажется, он жалуется на две текстовые записи SPF, но я не уверен, что это значит, когда он говорит, что мне нужно добавить соответствующую запись SPF. BIND 9.9 ARM, похоже, не упоминает об этом, и я не уверен, каковы последствия наличия «несогласованных» записей. Возможно, это связано с моим вопросом, а может быть, это случайное совпадение.
Джейкоб Эванс спросил, какой результат sudo named-checkconf -z
был. Вот этот вывод (хотя обратите внимание, что я редактировал файл зоны и, следовательно, его серийный номер с момента исходного сообщения):
jack@example:~$ sudo named-checkconf -z
zone example.com/IN: 'example.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record
zone example.com/IN: 'mailer.example.com' found SPF/TXT record but no SPF/SPF record found, add matching type SPF record
zone example.com/IN: loaded serial 2017122715
zone 0.168.192.in-addr.arpa/IN: loaded serial 1
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1
Оказывается, BIND был настроен для работы с Plesk и получал файлы зоны из другого места, чем я ожидал. Когда я внес изменения в нужный файл зоны, все заработало, как ожидалось.
Спасибо Джейкобу Эвансу и Патрику Мевзеку за то, что помогли мне разобраться!