#python #dns #network-protocols
Вопрос:
Я пытаюсь реализовать простую версию dig в качестве проекта на python. Я хочу реализовать поиск DNS с помощью итерации. Я прочитал документ RFC и подумал, что мне следует проверить, указан ли бит AA(Авторитетный ответ) в ответе, и если он не установлен в 1, я должен отправить тот же запрос на IP-адрес, указанный в данном ответе, пока этот бит не будет установлен. Когда я попытался google.com и проверил ответ с помощью wireshark, он предоставил правильный IP-адрес, но бит AA по-прежнему был равен 0, и когда я продолжал отправлять запросы, казалось, что это ни к чему не приведет. Является ли это правильным способом итеративного поиска? Если да, то как отличить авторитетные и неавторитетные ответы? Вот результат при запросе сервера 1.1.1.1 для google.com:
Flags: 0x8080 Standard query response, No error
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
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0000 = Reply code: No error (0)
Комментарии:
1. «Я пытаюсь реализовать простую версию dig как проект с python». Просто чтобы узнать что-то (о DNS и/или Python) или по другим причинам? Поскольку в противном
dnspythonслучае модуль Python-это все, что вам нужно для всех потребностей DNS в Python, в предоставлении интерфейсов как высокого, так и низкого уровня для выполнения всего (от простого разрешения записи до создания/анализа DNS-пакетов вплоть до проводного уровня)2. «Я подумал, что мне следует проверить, указан ли бит AA(Авторитетный ответ) в ответе, и если он не установлен в 1, я должен отправить тот же запрос на IP-адрес, указанный в данном ответе, пока этот бит не будет установлен». Похоже, у вас есть некоторые неверные представления о том, как работает DNS. Сначала вам нужно убедиться, как работают рекурсивные и авторитетные серверы имен и что именно происходит, когда вы запрашиваете тот или иной. RFC могут быть краткими/сложными в качестве введения, эта статья на en.wikipedia.org/wiki/Domain_Name_System мог бы быть более мягкий подход.
3. В качестве альтернативы, и чтобы смешать два моих предыдущих комментария, прежде чем пробовать новый код, просто используйте dnspython и посмотрите на следы в сети, чтобы понять, что происходит. Затем, если вы хотите лучше понять DNS/Python, вы можете попробовать воспроизвести те же результаты (путем сравнения сетевых трассировок, но, конечно, некоторые вещи могут измениться, например, идентификаторы DNS или набор имен) самостоятельно, посмотрев на новые сетевые трассировки.
4. 1 для @PatrickMevzek три комментария. Кроме того, поймите, как добраться от корневого домена до gTLD до серверов доменных имен. Для этого есть очень простые шаги. Поймите, что на самом деле означает бит AA и кто устанавливает этот бит.
5. @PatrickMevzek Мне не разрешено использовать для этого какие-либо модули, однако я использовал dig trace, чтобы узнать, что происходит, и он сначала отправил запросы на запись NS на корневые серверы и серверы gtld, затем отправил запрос на запись на авторитетный сервер и показал ответ, но поскольку 1.1.1.1 не является авторитетным сервером, бит AA не установлен, когда 1.1.1.1 отвечает мне. Я правильно все понял?
Ответ №1:
Вот результат при запросе сервера 1.1.1.1 для google.com:
DNS-запросы не всегда заканчиваются авторитетным ответом. На самом деле, 1.1.1.1 это итеративный распознаватель, поэтому его задача-запросить соответствующие серверы ( root — > > .com — > > google.com ) и вернуть окончательный ответ, который не будет авторитетным, так 1.1.1.1 как он возвращает его. Затем он будет кэшировать ответ и возвращать его всякий раз, когда кто-то задает ему тот же вопрос.
Если вы хотите создать инструмент , подобный копанию, и искать www.stackoverflow.com , вам нужно сделать то, что 1.1.1.1 нужно-начать с корня (например a.root-servers.net. ) и спросить его об .com этом . Затем спросите .com сервер (например a.gtld-servers.net ) об stackoverflow.com этом . Наконец, попросите сервер, ответственный за stackoverflow.com (например ns-1033.awsdns-01.org ) A , предоставить / AAAA запись для www.stackoverflow.com . Ответ, который вы получите от него, должен быть авторитетным:
> dig www.stackoverflow.com @ns-1033.awsdns-01.org ──(Thu,Apr08)─┘
; <<>> DiG 9.16.1-Ubuntu <<>> www.stackoverflow.com @ns-1033.awsdns-01.org
;; global options: cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62794
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.stackoverflow.com. IN A
;; ANSWER SECTION:
www.stackoverflow.com. 3600 IN CNAME stackoverflow.com.
stackoverflow.com. 3600 IN A 151.101.65.69
stackoverflow.com. 3600 IN A 151.101.1.69
stackoverflow.com. 3600 IN A 151.101.193.69
stackoverflow.com. 3600 IN A 151.101.129.69
;; AUTHORITY SECTION:
stackoverflow.com. 172800 IN NS ns-1033.awsdns-01.org.
stackoverflow.com. 172800 IN NS ns-358.awsdns-44.com.
stackoverflow.com. 172800 IN NS ns-cloud-e1.googledomains.com.
stackoverflow.com. 172800 IN NS ns-cloud-e2.googledomains.com.
Обратите внимание на aa флаг: flags: qr aa rd