У меня свежая установка 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, или ответы отправляются с not-fragment бит устанавливается, а затем отбрасывается, когда их нужно фрагментировать.
Похоже, что происходит то, что первоначальный ответ от 8.8.8.8 отбрасывается, что приводит к тайм-ауту dnsmasq и откату к использованию меньшего (1280 байт) максимума, который тогда слишком мал для ответа и приводит к усечению и последующему откату к TCP. . В то время как ответы от 1.1.1.1 усекаются с самого начала, возможно, потому, что этот сервер поддерживает меньший максимальный размер ответа UDP, который не приводит к фрагментации. Вы можете проверить это с помощью захвата пакетов, если хотите.
В то время как в AWS все эти DNS-серверы являются произвольными, поэтому отвечающий (или сеть между ним и вами) может быть настроен по-другому и поддерживать EDNS0 с достаточно большим размером ответа UDP для всего ответа на запрос DNSSEC, и тогда этот ответ будет успешно доставлен клиенту.
Потеря ответа на запрос от 8.8.8.8 не должна происходить, и, вероятно, это может быть некоторая неверная конфигурация, вызывающая это, но использование TCP для запросов DNSSEC не является редкостью. Это ожидаемое поведение, когда ответ больше, чем разрешено DNS-сервером для ответов UDP.
Чтобы этого избежать, вам придется либо найти другой рекурсивный DNS-сервер, который позволяет получать более крупные ответы UDP, либо запустить его самостоятельно, например, Без привязки, поскольку dnsmasq не поддерживает рекурсивный DNS.