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.
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