Как работает идентификатор запроса на раскопки?

Как рассчитывается идентификатор запроса на раскопки или он случайный?

Конкретно

$ dig google.co.uk

; <<>> DiG 9.11.0-P3 <<>> google.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63375

id: 63375 Каково его значение? Если случайно, то какой в ​​этом смысл?


Вся причина, по которой я пишу это, заключается в том, что я, честно говоря, не смог найти подробностей об этом в Google. Так что извиняюсь за качество вопроса.


person Mark    schedule 05.03.2017    source источник
comment
Это идентификатор транзакции DNS, однако ваш вопрос не является вопросом программирования - и офтоп здесь   -  person nos    schedule 05.03.2017
comment
Я использую dig для некоторых функций программы, которую я делаю, но не просматривал все элементы в выводе dig, поэтому, говоря только для себя, это было на самом деле напрямую связано с программированием, поскольку этот вывод - это вывод, который анализирует программное обеспечение. . Так что для меня это был полезный вопрос по программированию.   -  person Lizardx    schedule 06.03.2017


Ответы (1)


Ваш dig, кажется, имеет очень минимальный вывод по сравнению с выводом dig по умолчанию в debian/gnu linux, что может быть причиной путаницы, но в любом случае это хороший вопрос.

https://technet.microsoft.com/en-us/library/dd197470(v=ws.10).aspx

 Query Identifier (Transaction ID)

Set to a unique number to enable the DNS client resolver to match the response to the query.

Этот вывод делает это прикосновение более ясным. Как видите, «id» находится в «ответе» DNS-сервера. И если вы просмотрите статью technet, которая на удивление полна с точки зрения всех возвращаемых и используемых значений, вы увидите, что приведенное выше, скорее всего, означает значение «id», хотя, если это не так, надеюсь, кто-то это исправит.

Zytrax еще более нагляден: идентификатор запроса генерируется тем, кто делает запрос, и представляет собой 16-битное число. Итак, dig генерирует его, а DNS-сервер отправляет его обратно в dig, чтобы подтвердить, что на самом деле запрос и ответ совпадают. http://www.zytrax.com/books/dns/ch15/

Message ID  16 bit message ID supplied by the requestion (the questioner) and reflected back unchanged by the responder (answerer). Identifies the transaction.

Так вот что такое ID, копать, в данном случае сгенерировал его случайным образом. Я проверил это, и на самом деле, да, вы можете видеть, это случайное число от 0 до 2 ^ 16 (65536). Всего за 5, 10 запросов на раскопки я получил значения от 500 до 62000, что вы и ожидаете увидеть при генерации рандомизированных чисел.

dig google.co.uk
; <<>> DiG 9.10.3-P4-Debian <<>> google.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56947
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.co.uk.          IN  A

;; ANSWER SECTION:
google.co.uk.       300 IN  A   172.217.6.35

;; Query time: 34 msec
;; SERVER: 68.87.76.178#53(68.87.76.178)
;; WHEN: Sun Mar 05 10:59:13 PST 2017
;; MSG SIZE  rcvd: 57

Это настройки копания по умолчанию в Debian.

Просто чтобы убедиться, что это объяснение, вероятно, верно, я снова запустил запрос на раскопки. Как вы можете видеть, идентификатор снова изменился, что означает, что он, скорее всего, является рандомизированным идентификатором ответа, который делает именно то, что говорится в статье о синтаксисе technet dns, помогает связать запрос с ответом, поэтому он знает, что получил правильный. Очевидно, что это не должно быть таким большим числом, достаточно большим, чтобы гарантировать, что один запрос соответствует одному ответу.

dig google.co.uk

; <<>> DiG 9.10.3-P4-Debian <<>> google.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29674
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.co.uk.          IN  A

;; ANSWER SECTION:
google.co.uk.       260 IN  A   172.217.6.35

;; Query time: 12 msec
;; SERVER: 68.87.76.178#53(68.87.76.178)
;; WHEN: Sun Mar 05 11:05:04 PST 2017
;; MSG SIZE  rcvd: 57
person Lizardx    schedule 05.03.2017
comment
Я удалил остальную часть вывода, так как меня интересовал только идентификатор запроса. (мой вывод был последним). Спасибо за разъяснение! - person Mark; 06.03.2017
comment
Спасибо, что задали вопрос. Я использую этот вывод в программе, но никогда полностью не читал синтаксис, так что это был хороший повод для этого. - person Lizardx; 07.03.2017