Публичный DNS Google всегда возвращает NXDOMAIN для определенных SLD

Проблема: общедоступный DNS Google возвращает NXDOMAIN для определенных SLD.

Доказательство проблемы:

dig vpn.example.com @8.8.8.8

         ; \<\<\>\> DiG 9.11.5-P4-5.1+deb10u8-Debian \<\<\>\> vpn.example.com @8.8.8.8
    ; global options: +cmd
    ; Got answer:
    ;; -\>\>HEADER\<\<- opcode: QUERY, status: NXDOMAIN, id: 8324
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
    
    ; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;vpn.example.com.        IN    A
    
    ;; AUTHORITY SECTION:
    example.com.    1800    IN    SOA    ns1.example.com. root.example.com. 1675851775 28800 7200 604800 86400
    
    ;; Query time: 134 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Thu Feb 09 09:52:06 EET 2023
    ;; MSG SIZE  rcvd: 93

как вы можете видеть, статус запроса — NXDOMAIN. Однако запрос авторитетного DNS-сервера, указанного в разделе AUTHORITY, указывает на правильный ответ:

dig vpn.example.com @ns1.example.com

      ; \<\<\>\> DiG 9.11.5-P4-5.1+deb10u8-Debian \<\<\>\> vpn.example.com @ns1.example.com**
;; global options: +cmd
;; Got answer:
;; -\>\>HEADER\<\<- opcode: QUERY, status: **NOERROR**, id: 37073
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 600
;; QUESTION SECTION:
;vpn.example.com.        IN    A

;; ANSWER SECTION:
vpn.example.com.    3600    IN    A    XXX.XX.X.XXX

;; Query time: 128 msec
;; SERVER: XXX.XX.XX.XXX#53(XXX.XX.XX.XXX)
;; WHEN: Thu Feb 09 09:58:05 EET 2023
;; MSG SIZE  rcvd: 64

Другие общедоступные DNS-серверы (opendns, cloudflare и т. д.) разрешают SLD.

Авторитетный DNS-сервер (все 4 записи NS) единообразен в ответах:

      for i in $(seq 1 30)
do
query=$(dig +short us1.vpn.example.com @ns1.example.com)
if [[ -z "$query" ]]
then echo "NO ANSWER"
else
echo "ANSWER"
fi
sleep 2
done | sort | uniq -c

30 ОТВЕТ

Я попробовал следующее на двух разных вкладках:

Клиентская часть TAB1 //

while true; do dig +short vpn.example.com @8.8.8.8; sleep 1; done

TAB2 DNS на стороне сервера //

tcpdump -vvvvv -w /tmp/dns.pcap udp and port 53

TAB2 DNS на стороне сервера //

tcpdump -n -t -r /tmp/dns.pcap | grep vpn

и попытался определить любые IP-адреса перечисленных здесь подсетей: https://developers.google.com/speed/public-dns/faq#locations_of_ip_address_ranges_google_public_dns_uses_to_send_queries

и не нашел ничего для этого конкретного хоста. Как я могу это отладить? Спасибо за любые предстоящие предложения!

Источник

3 ответа

Авторитетный DNS-сервер (все 4 записи NS) единообразен в ответах:

Нет это не так. Серверns1.exmaple.comиногда переключается между возвратом записи A и возвратом NXDOMAIN для этого имени. (Похоже, что выполнение запроса через TCP с использованиемdig +vc, — это надежный способ заставить его начать отвечать с помощью NXDOMAIN по обоим протоколам.)

      $ dig vpn.example.com @ns1.example.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24350
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

$ dig +vc vpn.example.com @ns1.example.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63787
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

$ dig vpn.example.com @ns1.example.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10815
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

В этой ситуации вполне нормально иметь некоторую несогласованность кэша (как заметил Томек), поскольку DNS Google не является просто глобально произвольным — каждое местоположение имеет свои собственные несколько преобразователей с независимыми кэшами за балансировщиком нагрузки, поэтому даже если вы видите с тем же NSID, вы все равно каждый раз получаете ответы от другого внутреннего сервера. (Кстати, не забудьте страницу очистки кэша .)

Возможно, чтоns1.example.comаналогичным образом обрабатывается несколькими серверами за балансировщиком нагрузки, некоторые из которых дают правильный результат, а некоторые нет.

Источник

Я могу периодически воспроизводить его на все DNS-адреса Google:

      triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
XXX.XX.X.XXX
triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
XXX.XX.X.XXX
triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
XXX.XX.X.XXX
triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
XXX.XX.X.XXX
triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
XXX.XX.X.XXX
triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
XXX.XX.X.XXX
triss:~> dig vpn.obfuscated.com @2001:4860:4860::8844 +short
XXX.XX.X.XXX

Похоже на несогласованность кэша Google.

Источник

Оказалось, что это проблема PIPEBackend с авторитетным сервером powerdns. Спасибо всем участникам!

Источник
Другие вопросы по тегам