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