command line ID vs Wireshark transaction ID (dns.id)

[John W. Blue]

I have been trying to correlate the ID value returned via a command line query here:

 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60796

 

to a “transaction ID” found in wireshark when it dissects the packet found here:

 

Transaction ID: 0x1aa6

 

without any success because 0x1aa6 does not hex > dec convert to 60796.

 

 

I am clearly missing something here because wireshark can tie the query and response together into a stream.

 

Thoughts?

 

John

 

 

 

[John W. Blue]

Forgot to add a screenshot:

 

http://www.rfmapping.com/transactionid.png

 

Thanks!

 

John

[Mark Andrews]

In message <af76af2d3ad8445c...@mail.rrcic.com>, "John W. Blue" wr
ites:

> I have been trying to correlate the ID value returned via a command line
> query here:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60796
>
> to a "transaction ID" found in wireshark when it dissects the packet
> found here:
>
> Transaction ID: 0x1aa6
>
> without any success because 0x1aa6 does not hex > dec convert to 60796.
>
>
> I am clearly missing something here because wireshark can tie the query
> and response together into a stream.
>
> Thoughts?

Apply Occam's razor.

The packet in wireshark is not the packet DiG displayed.

> John

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[John W. Blue]

Mark,

If only it was that easy!

Because I have went through heaps and heaps of test configurations, I can say with some confidence, that you have not actually tried to correlate the values yourself in a similar fashion.

(insane is defined as doing the same thing over and expecting a different result, correct?)

Before I composed this email I did one last tcpdump where I tested via the command:

# rndc flush
# tcpdump -n -i bge1 -s0 -w airnav.pcap port domain

The query command in another shell was:

$ dig www.airnav.com.

With a result of:

; <<>> DiG <<>> www.airnav.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64934
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6

;; QUESTION SECTION:
;www.airnav.com. IN A

;; ANSWER SECTION:
www.airnav.com. 300 IN A 206.125.168.131

The screenshot of the resulting pcap is here:

http://www.rfmapping.com/airnav.png

Although I would expect transaction 0xc905 to be the one that produced the above dig results, for grins, none of the hex transaction id's can be converted to match the id "64934".

John

-----Original Message-----
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Thursday, August 10, 2017 7:26 PM
To: John W. Blue
Cc: bind-...@lists.isc.org
Subject: Re: command line ID vs Wireshark transaction ID (dns.id)


Apply Occam's razor.

The packet in wireshark is not the packet DiG displayed.

[Mark Andrews]

What nameserver addresses are listed in /etc/resolv.conf?
What interfaces are used to talk to those addresses?
Is wireshark/tcpdump using all those interfaces?

In message <42febb6a7bd44bd0...@mail.rrcic.com>, "John W. Blue" writes:
> Mark,
>
> If only it was that easy!
>
> Because I have went through heaps and heaps of test configurations, I
> can say with some confidence, that you have not actually tried to
> correlate the values yourself in a similar fashion.

I can say I've been debugging DNS for over 20 years and looked at
hundreds of packet traces and never once had a the tools display
the wrong id. And yes, I have needed to correlate packet with
presentation in the past.

> (insane is defined as doing the same thing over and expecting a different result, correct?)
>
> Before I composed this email I did one last tcpdump where I tested via the command:
>
> # rndc flush
> # tcpdump -n -i bge1 -s0 -w airnav.pcap port domain

Which shows the traffic from named to/from the world with a freshly
started server. The server is forwarding to another server based
on the contents of the responses.

What it isn't showing is the traffic to the nameserver from dig
because that traffic isn't being captured by that dump.

> The query command in another shell was:
>
> $ dig www.airnav.com.
>
> With a result of:
>
> ; <<>> DiG <<>> www.airnav.com.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64934
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6
>
> ;; QUESTION SECTION:
> ;www.airnav.com. IN A
>
> ;; ANSWER SECTION:
> www.airnav.com. 300 IN A 206.125.168.131

Which isn't the complete response. I'm guessing that the complete
response would show that the server that answered was 127.0.0.1 or
::1. Even if it isn't those addresses but is a local address on
the server the requests will be going over the loopback interface.

e.g.
% tcpdump -n -i lo0 not host ::1 and not host 127.0.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
15:09:46.836099 IP 172.30.42.89.50389 > 172.30.42.89.53: 64151+ [1au] NS? . (40)
15:09:46.836144 IP 172.30.42.89 > 172.30.42.89: ICMP 172.30.42.89 udp port 53 unreachable, length 36
15:09:51.840127 IP 172.30.42.89.50389 > 172.30.42.89.53: 64151+ [1au] NS? . (40)
15:09:51.840192 IP 172.30.42.89 > 172.30.42.89: ICMP 172.30.42.89 udp port 53 unreachable, length 36

> The screenshot of the resulting pcap is here:
>
> http://www.rfmapping.com/airnav.png
>
> Although I would expect transaction 0xc905 to be the one that produced the above dig results, for grins, none of the he
> x transaction id's can be converted to match the id "64934".
>
> John
>
> -----Original Message-----
> From: Mark Andrews [mailto:ma...@isc.org]
> Sent: Thursday, August 10, 2017 7:26 PM
> To: John W. Blue
> Cc: bind-...@lists.isc.org
> Subject: Re: command line ID vs Wireshark transaction ID (dns.id)
>
>
> Apply Occam's razor.
>
> The packet in wireshark is not the packet DiG displayed.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

[Mark Andrews]

Mark Andrews writes:
>
> What nameserver addresses are listed in /etc/resolv.conf?
> What interfaces are used to talk to those addresses?
> Is wireshark/tcpdump using all those interfaces?
>
>
> In message <42febb6a7bd44bd0...@mail.rrcic.com>, "John W. Blue" writes:
> > Mark,
> >
> > If only it was that easy!
> >
> > Because I have went through heaps and heaps of test configurations, I
> > can say with some confidence, that you have not actually tried to
> > correlate the values yourself in a similar fashion.
>
> I can say I've been debugging DNS for over 20 years and looked at
> hundreds of packet traces and never once had a the tools display
> the wrong id. And yes, I have needed to correlate packet with
> presentation in the past.
>
> > (insane is defined as doing the same thing over and expecting a different result, correct?)
> >
> > Before I composed this email I did one last tcpdump where I tested via the command:
> >
> > # rndc flush
> > # tcpdump -n -i bge1 -s0 -w airnav.pcap port domain
>
> Which shows the traffic from named to/from the world with a freshly
> started server. The server is forwarding to another server based
> on the contents of the responses.

Ignore the forwarding part. I misread the referral.

[Philippe...@swisscom.com]

strange : by me it looks like ... : 43350 = 0xa956


>/usr/bin/dig www.google.ch
; <<>> DiG 9.10.3-P4-Debian <<>> www.google.ch

;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43350
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

>tshark -V -f 'port 53'
...
Domain Name System (response)
[Request In: 1]
[Time: 0.001247378 seconds]
Transaction ID: 0xa956
Flags: 0x8180 Standard query response, No error
1... .... .... .... = Response: Me
.....

-----Original Message-----
From: bind-users [mailto:bind-user...@lists.isc.org] On Behalf Of Mark Andrews
Sent: vendredi, 11 août 2017 02:26
To: John W. Blue <john...@rrcic.com>
Cc: bind-...@lists.isc.org <bind-...@isc.org>
Subject: Re: command line ID vs Wireshark transaction ID (dns.id)

In message <af76af2d3ad8445c...@mail.rrcic.com>, "John W. Blue" wr
ites:
> I have been trying to correlate the ID value returned via a command
> line query here:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60796
>
> to a "transaction ID" found in wireshark when it dissects the packet
> found here:
>
> Transaction ID: 0x1aa6
>
> without any success because 0x1aa6 does not hex > dec convert to 60796.
>
>
> I am clearly missing something here because wireshark can tie the
> query and response together into a stream.
>
> Thoughts?

Apply Occam's razor.

The packet in wireshark is not the packet DiG displayed.

> John

[John W. Blue]

> What nameserver addresses are listed in /etc/resolv.conf?

So.

resolv.conf has the non-RFC1918 ip addresses commented out *and* loopback is the only one enabled.

Lovely. <grin>

I decided to leave it as is and retested with:

# tcpdump -n -i lo0 -s0 port domain

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on lo0, link-type NULL (BSD loopback), capture size 65535 bytes
08:50:55.837412 IP 127.0.0.1.17709 > 127.0.0.1.53: 59248+ A? www.airnav.com. (32)
08:50:56.019525 IP 127.0.0.1.53 > 127.0.0.1.17709: 59248 1/3/6 A 206.125.168.131 (247)

Wireshark hex transaction id converts to decimal for a successful match.

Thanks for the help Mark!

John