Назад | Перейти на главную страницу

Обновление файла зоны - Добавление записей CNAME - Как устранить неполадки / где я ошибся?

Заранее прошу прощения за этот вопрос новичка. Я прибегал к вопросу, потому что не могу найти достаточно тесно связанных запросов * в этой сети или где-либо еще, а 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 и получал файлы зоны из другого места, чем я ожидал. Когда я внес изменения в нужный файл зоны, все заработало, как ожидалось.

Спасибо Джейкобу Эвансу и Патрику Мевзеку за то, что помогли мне разобраться!