0

How is the dig query id calculated or is it random?

Specifically

$ 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 What's its significance? If it is random then whats the point of it?


The whole reason I'm writing this is because I honestly couldn't find much details about it on Google. So apologies for the quality of the question.

Mark
  • 1,337
  • 23
  • 34
  • It is the DNS transaction ID, however your question isn't a programming question - and oftopic here – nos Mar 05 '17 at 19:49
  • 1
    I use dig for some features of a program I do, but hadn't looked into all the items in the dig output, so speaking just for myself, this was actually directly related to programming, in that this output is the output the software parses. So for me, this was a useful programming question. – Lizardx Mar 06 '17 at 20:23

1 Answers1

2

Your dig seems to have very minimal output compared to debian/gnu linux dig default output, which may be the cause of the confusion, but it's a fine question to ask anyway.

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.

This output makes this a touch more clear. As you can see, the 'id' is in the dns server's 'answer'. And if you scan through the technet article, which is surprisingly complete in terms of all the values returned and used, you'll see that the above is most likely the meaning of 'id', though if not, hopefully someone will correct this.

Zytrax is even more clear, the query id is generated by the thing making the request, and is a 16 bit number. So dig generates it, and the dns server sends it back to dig, to confirm that in fact, the request and answer are matched. 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.

So that's what the ID is, dig, in this case, generated it randomly. I tested this, and in fact, yes, you can see, it's a random number between I assume 0 and 2^16 (65536). In just 5, 10 dig requests, I got values between 500 and 62000, which is what you'd expect to see from randomized number generation.

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

This is default dig configs in Debian.

Just to verify that this explanation is probably correct, I ran the dig request again. As you can see, the ID changed again, which means it most likely is in fact a randomized response id that does exactly what the technet dns syntax article says, helps bind the query to the response, so it knows its getting the right one. Obviously doesn't have to be that big of a number, just big enough to ensure one request match one answer.

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
Lizardx
  • 1,165
  • 10
  • 16
  • I deleted the rest of the output since I was only concerned with the query id. (my output was the as your last one). Thank you for clarifying! – Mark Mar 05 '17 at 21:35
  • Thanks for asking the question. I use this output in a program, but had never actually read up on the syntax completely, so this was a good excuse to do that. – Lizardx Mar 06 '17 at 22:14