DNS SERVFAIL и неправильный флаг только через TCP: сломанные DNS-серверы?
Это плохая конфигурация для возврата корневых серверов имен в дополнительном разделе для поиска CNAME, который указывает на другой домен? В частности, я вижу это с CNAME, размещенным Network Solutions с CNAME, указывающим на другой домен и TLD.
Я спрашиваю, является ли это плохой конфигурацией, потому что все эти дополнительные записи приводят к превышению размера UDP-пакета, заставляя запрос быть повторным с TCP.
dig www.unitedstatesartists.org +trace
Ответ сервера имен:
example.org. 86400 IN NS ns15.worldnic.com.
example.org. 86400 IN NS ns16.worldnic.com.
;; Received 95 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 79 ms
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
www.example.org. 7200 IN CNAME load-01-123.us-west-1.elb.amazonaws.com.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS m.root-servers.net.
;; Received 526 bytes from 205.178.190.8#53(ns15.worldnic.com) in 173 ms
Возвращать дополнительные записи или нет случайно. Иногда, когда они не возвращают дополнительное, все еще остается усеченный ответ и копает повторы в TCP.
example.org. 86400 IN NS ns15.worldnic.com.
example.org. 86400 IN NS ns16.worldnic.com.
;; Received 95 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 82 ms
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
www.example.org. 7200 IN CNAME load-01-123.us-west-1.elb.amazonaws.com.
;; Received 107 bytes from 205.178.190.8#53(ns15.worldnic.com) in 164 ms
Обновление 2010-12-08
При дополнительном тестировании найдено:
- Network Solutions отвечает SERVFAIL (сбой сервера) рекурсивным запросом (по умолчанию dig, если нет +trace), но все равно дает правильный ответ.
- Настройка dig's +norecurse работает нормально, но не всегда. Иногда SERVFAIL возвращается - не хорошо. Подробности, возможно, почему следует ниже
- Включение корневыми серверами Network Solutions корневых и дополнительных разделов вызывает усечение UDP и требует завершения TCP.
Обзор следующего захвата:
- Нерекурсивная запись запроса от ns15
- Ответ ns15 включает корневые серверы в auth и дополнительные и помечает ответ как усеченный
- Нерекурсивный запрос повторяется в TCP из-за усеченного UDP
- Аналогичный ответ от ns15 с использованием TCP за исключением того, что "требуемая рекурсия" установлена неправильно и также установлен код "сбой сервера"
Мы уже создали билет с ними, но посмотрим, пойдет ли он куда-нибудь. Ниже приведены DNS-пакеты из деталей tshark:
Первый вопрос (через UDP):
Domain Name System (query)
Transaction ID: 0x27ef
Flags: 0x0000 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Первый ответ (через UDP):
Domain Name System (response)
[Request In: 1]
[Time: 0.078623000 seconds]
Transaction ID: 0x27ef
Flags: 0x8600 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .1.. .... .... = Authoritative: Server is an authority for domain
.... ..1. .... .... = Truncated: Message is truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 0... .... = Recursion available: Server can't do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Второй вопрос (через TCP):
Domain Name System (query)
Length: 56
Transaction ID: 0xbc37
Flags: 0x0000 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Второй ответ (через TCP, уведомление "желание рекурсии"):
Domain Name System (response)
[Request In: 6]
[Time: 0.147357000 seconds]
Length: 107
Transaction ID: 0xbc37
Flags: 0x8102 (Standard query response, Server failure)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 0... .... = Recursion available: Server can't do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0010 = Reply code: Server failure (2)
1 ответ
Да, это плохая конфигурация и / или реализация - у авторитетного сервера нет причин возвращать корневые ссылки в другом действительном ответе.
Кроме того, я вижу другие ошибки, которые просто не должны происходить на этих двух серверах Worldnic:
иногда дает правильный ответ, но с
SERVFAIL
код ошибки и безAA
бит установлен.Ответы UDP всегда усекаются до 512 байтов, даже с указанным EDNS0 ( RFC 2671). Это означает, что DNSSEC не будет работать с этим сервером имен
Это не только
ADDITIONAL
раздел, который является проблемой, он помещает корневые серверы имен вAUTHORITY
раздел авторитетный (AA
бит установлен) отвечу.