Google DNS SERVFAIL для поиска PTR, провайдер не помогает
Мне очень нужна помощь! Некоторые из наших размещенных пользователей Exchange в последнее время получают отчеты о недоставке при отправке в некоторые домены. Я считаю, что ошибка 554 НЕ НАЙДЕН IP PTR. Я поклялся, что наш интернет-провайдер поставил PTR, и он действительно был там. Однако другой мой коллега заметил, что DNS Google не возвращает результаты, а вместо этого выдает ошибку SERVFAIL. Оказывается, Google DNS по умолчанию выполняет проверки DNSSEC для всех запросов, и если зона не подписана, никакого вреда не будет. Однако, если в зоне включен DNSSEC, но она настроена неправильно, вы получите SERVFAIL.
Мы поговорили с нашим интернет-провайдером, и они отказываются признать, что проблема на их стороне, поскольку они продолжают говорить, что DNSSEC никогда не включается. любая из их зон .in-addr.arpa. Но когда мы проводим онлайн-проверки, это доказывает обратное.
Рассматриваемый IP-адрес - xxxx, хостинг - Centurylink.
https://dnssec-debugger.verisignlabs.com/.in-addr.arpa http://dnsviz.net/d/.in-addr.arpa/dnssec/
Моя теория состоит в том, что получающий почтовый сервер просто выполняет проверку на спам PTR И они также настроены на использование DNS-серверов Google версии 8.8.8.8 в качестве преобразователей. Поскольку он получает сообщение SERVFAIL, наши клиенты получают отчет о недоставке, поскольку он не может проверить наш передающий сервер ретрансляции.
Мне действительно нужна помощь, чтобы доказать интернет-провайдеру, что это каким-то образом связано с DNSSEC, поскольку они продолжают возражать, утверждая, что он НУЛЕВОЙ процент, связанный с DNSSEC. Я пытаюсь использовать DIG, чтобы каким-то образом доказать, что DNSSEC имеет отношение, поэтому, пожалуйста, помогите мне! Я показал им эти две ссылки, но они не сдвигаются с места. Я схожу с ума или они правы?
TIA!
РЕДАКТИРОВАТЬ: Я удалил наш общедоступный IP-адрес из списка, так как наша проблема, похоже, на данный момент решена.
Я бы сказал, что ваша ссылка http://dnsviz.net очень ясно дает понять, почему это проблема DNSSEC.
Тем не менее, если вы хотите проиллюстрируйте, используя dig . Я бы выбрал + cdflag . он устанавливает бит «CD (проверка отключена) в запросе» , явно сообщая преобразователю пропустить проверку DNSSEC.
В приведенном ниже примере я буду использовать dnssec-failed. org , который предназначен для отказа DNSSEC.
$ dig @8.8.8.8 dnssec-failed.org SOA
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @8.8.8.8 dnssec-failed.org SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8707
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dnssec-failed.org. IN SOA
;; Query time: 492 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar 09 10:24:17 CET 2018
;; MSG SIZE rcvd: 46
$
vs.
$ dig +cdflag @8.8.8.8 dnssec-failed.org SOA
; <<>> DiG 9.10.3-P4-Ubuntu <<>> +cdflag @8.8.8.8 dnssec-failed.org SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30849
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dnssec-failed.org. IN SOA
;; ANSWER SECTION:
dnssec-failed.org. 21599 IN SOA dns101.comcast.org. dnsadmin.comcast.net. 2010101883 900 180 604800 7200
;; Query time: 189 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar 09 10:25:28 CET 2018
;; MSG SIZE rcvd: 117
$