Проблема Dnsmasq DNSSEC UDP в Google Compute Engine
У меня свежая установка Ubuntu 18.04 на Google Compute Engine. Я скомпилировал последнюю версию Dnsmasq (2.80) со следующей конфигурацией:
no-resolv
server=8.8.8.8
conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
dnssec
port=5353
Затем я ввожу следующую команду:
dig @127.0.0.1 -p 5353 pir.org
После этого следует долгая пауза, и возвращается результат:
:~$ dig @127.0.0.1 -p 5353 pir.org
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @127.0.0.1 -p 5353 pir.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62921
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pir.org. IN A
;; ANSWER SECTION:
pir.org. 299 IN A 97.107.141.235
;; Query time: 56 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Thu Aug 15 00:55:35 UTC 2019
;; MSG SIZE rcvd: 52
Что означает возврат в режим TCP.
Журнал dnsmasq говорит:
dnsmasq: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Если я сделаю то же самое с Amazon Web Services, dig немедленно вернется, не прибегая к режиму TCP.
Когда 1.1.1.1 используется в качестве восходящего сервера в dnsmasq на GCE нет длинной паузы и ничего не записывается в журнал dnsmasq. Тем не менее, он все еще сообщает усеченный результат / режим TCP:
~$ dig @127.0.0.1 -p 5353 pir.org
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @127.0.0.1 -p 5353 pir.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61800
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;pir.org. IN A
;; ANSWER SECTION:
pir.org. 220 IN A 97.107.141.235
;; Query time: 53 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Thu Aug 15 01:44:23 UTC 2019
;; MSG SIZE rcvd: 52
Захват пакетов (GCE):
03:39:06.405852 IP 10.154.0.29.32748 > 8.8.8.8.53: 53258+ [1au] A? pir.org. (48)
03:39:06.420540 IP 8.8.8.8.53 > 10.154.0.29.32748: 53258$ 2/0/1 A 97.107.141.235, RRSIG (219)
03:39:06.420726 IP 10.154.0.29.14117 > 8.8.8.8.53: 46254+ [1au] DS? org. (32)
03:39:06.421028 IP 8.8.8.8.53 > 10.154.0.29.14117: 46254$ 3/0/1 DS, DS, RRSIG (403)
03:39:06.421154 IP 10.154.0.29.8094 > 8.8.8.8.53: 56315+ [1au] DNSKEY? . (28)
03:39:06.422456 IP 8.8.8.8.53 > 10.154.0.29.8094: 56315$ 3/0/1 DNSKEY, DNSKEY, RRSIG (864)
03:39:06.422995 IP 10.154.0.29.34809 > 8.8.8.8.53: 46400+ [1au] DS? pir.org. (36)
03:39:06.429627 IP 8.8.8.8.53 > 10.154.0.29.34809: 46400$ 3/0/1 DS, DS, RRSIG (283)
03:39:06.429974 IP 10.154.0.29.26859 > 8.8.8.8.53: 55747+ [1au] DNSKEY? org. (32)
03:39:06.430307 IP 8.8.8.8.53 > 10.154.0.29.26859: 55747$ 7/0/1 DNSKEY, DNSKEY, DNSKEY, DNSKEY, RRSIG, RRSIG[|domain]
03:39:11.405991 IP 10.154.0.29.26859 > 8.8.8.8.53: 55747+ [1au] DNSKEY? org. (32)
03:39:11.406544 IP 8.8.8.8.53 > 10.154.0.29.26859: 55747| 0/0/1 (32)
Захват пакетов (AWS):
03:39:26.312403 IP 192.168.0.131.17535 > 8.8.8.8.53: 7225+ [1au] A? pir.org. (48)
03:39:26.327521 IP 8.8.8.8.53 > 192.168.0.131.17535: 7225$ 2/0/1 A 97.107.141.235, RRSIG (219)
03:39:26.327571 IP 192.168.0.131.1520 > 8.8.8.8.53: 37804+ [1au] DS? org. (32)
03:39:26.329798 IP 8.8.8.8.53 > 192.168.0.131.1520: 37804$ 3/0/1 DS, DS, RRSIG (403)
03:39:26.329893 IP 192.168.0.131.62316 > 8.8.8.8.53: 12792+ [1au] DNSKEY? . (28)
03:39:26.332070 IP 8.8.8.8.53 > 192.168.0.131.62316: 12792$ 3/0/1 DNSKEY, DNSKEY, RRSIG (864)
Есть идеи, почему GCE ведет себя иначе, чем AWS?
Ваш заключительный запрос является небольшим, но некоторые промежуточные запросы, необходимые для проверки DNSSEC, вероятно, намного больше. Это - природа DNSSEC.
исходный максимальный размер ответа UDP для DNS составлял 512 байтов, но ответы DNSSEC могут составить несколько килобайтов. EDNS0 позволяет клиенту рекламировать это, он поддерживает большие ответы UDP, но сервер DNS будет иметь свой собственный максимальный размер ответа UDP и не может поддерживать EDNS0 вообще.
существует много способов, которыми это может пойти не так, как надо. Некоторые более старые серверы DNS не поддерживают EDNS0 вообще и если Вы отправляете им запрос с EDNS0, они тихо отбрасывают весь запрос. Некоторая поддержка это и позволяет ответам, достаточно большим заставлять пакет UDP быть фрагментированным, который может заставить ответ исчезать в дыре, когда существует брандмауэр, который отбрасывает фрагментированные ответы DNS или ответы, отправляется с набором битов-фрагмента и затем отбрасывается, когда они должны быть фрагментированы.
, Что, кажется, происходит, то, что начальный ответ от 8.8.8.8 становится отброшенным, вызывая dnsmasq к тайм-ауту и нейтрализации к использованию меньшего (1 280-байтового) максимума, который является затем слишком маленьким для ответа и приводит к усечению и последующей нейтрализации к TCP. Принимая во внимание, что ответы от 1.1.1.1 являются усеченными с начала, возможно, потому что тот сервер поддерживает меньший максимальный размер ответа UDP, который не приводит к фрагментации. Вы могли проверить это с захватом пакетов, если бы Вы были так склонны.
принимая во внимание, что с AWS, эти серверы DNS все передаются одному из узлов, таким образом, ответ того (или сеть между ним и Вами) может быть настроен по-другому и поддержка EDNS0 с достаточно большим размером ответа UDP для всего ответа запроса DNSSEC, и затем что ответ успешно поставляется клиенту.
ответа запроса, теряющегося от 8.8.8.8, не должно происходить, и там вероятно некоторая неверная конфигурация, вызывающая это, но видящая, что нейтрализация к TCP для запросов DNSSEC весьма распространена. Это - ожидаемое поведение, когда ответ больше, чем, что сервер DNS допускает ответы UDP.
Для предотвращения его необходимо было бы или найти другой рекурсивный сервер DNS, который позволяет большие ответы UDP или выполняет тот сами с помощью, например, Несвязанный, так как dnsmasq не поддерживает рекурсивный DNS.