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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

 

 

 


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

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John W. Blue

Forgot to add a screenshot:

 

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

 

Thanks!

 

John

 

From: bind-users [mailto:[hidden email]] On Behalf Of John W. Blue
Sent: Thursday, August 10, 2017 6:07 PM
To: [hidden email]
Subject: command line ID vs Wireshark transaction ID (dns.id)

 

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

 

 

 


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

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mark Andrews
In reply to this post by John W. Blue

In message <[hidden email]>, "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: [hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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:[hidden email]]
Sent: Thursday, August 10, 2017 7:26 PM
To: John W. Blue
Cc: [hidden email]
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: [hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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 <[hidden email]>, "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:[hidden email]]
> Sent: Thursday, August 10, 2017 7:26 PM
> To: John W. Blue
> Cc: [hidden email]
> 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: [hidden email]
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mark Andrews
In reply to this post by John W. Blue

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 <[hidden email]>, "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.
 

> 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:[hidden email]]
> > Sent: Thursday, August 10, 2017 7:26 PM
> > To: John W. Blue
> > Cc: [hidden email]
> > 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: [hidden email]
> > _______________________________________________
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> >
> > bind-users mailing list
> > [hidden email]
> > https://lists.isc.org/mailman/listinfo/bind-users
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [hidden email]
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Philippe.Simonet
In reply to this post by Mark Andrews
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:[hidden email]] On Behalf Of Mark Andrews
Sent: vendredi, 11 août 2017 02:26
To: John W. Blue <[hidden email]>
Cc: [hidden email] <[hidden email]>
Subject: Re: command line ID vs Wireshark transaction ID (dns.id)


In message <[hidden email]>, "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: [hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

John W. Blue
In reply to this post by Mark Andrews


> 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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Loading...