August 14, 2012 • 3 min read
CloudShark lets you embed your filters directly in the URL. When we view this packet capture file, we are already brought to the view we want to see: in this case, only DNS and ICMP messages.
http://cloudshark.org/captures/a02f4f4a0df0?filter=dns%20%7C%7C%20icmp
Why is that? The problem we’re looking to illustrate happens to be an ICMP packet that is tied to a particular DNS response. That DNS response happens to be packet #29.
Packet #29 is a DNS response to a query for an IPv6 address. Notice that the ICMP error happens multiple times. Each time, the DNS client is making two requests, for two different records: one A record and one AAAA record (i.e., one IPv4 lookup and one IPv6 lookup).
The DNS server responds with both records, and gives the A record first. It then gives the AAAA record, which is rejected on the basis of “Destination Unreachable (Port Unreachable)”.
Why would the port be unreachable? The DNS client of this particular operating system is opening two sockets to make two DNS requests… but when it receives the first (IPv4) record, it closes the sockets for both requests, providing no way for the second response to reach its destination. Configured in such a way, the client will always end up choosing IPv4 when both IPv4 and IPv6 are possible here.
We can put it more clearly with an answer from one of our participants, definitely the best answer we received:
_So, this is what’s happening in this trace:
The client 192.168.1.124 resolves names using the recursive nameserver 75.75.75.75. Since the client also has IPv6 connectivity (or at least thinks so), it sends the nameserver both “A” and “AAAA” requests for the different types of addresses.
These pairs of requests are sent “in parallel” in the sense that the client sends them quickly in succession without waiting for a response (or timeout) in between. The two requests are sent from different source ports, which means that the client opens two separate sockets for them.
The nameserver responds quickly to the requests in order. The client accepts the first response, and then closes both sockets; this would explain that when the second response arrives, the client generates an ICMP port unreachable (because the socket that would have received that second response has already been closed)._
Thanks to all who participated. We’ll have another challenge soon!
Hello out there, packet geeks! Maybe you already have a CloudShark T-Shirt. If you do, and you’ve been wearing it every day, so it’s probably worn out by now.
Not to worry! We have another packet capture challenge ready for you. This one illustrates how you can you CloudShark URLs to show the same analysis view you have to anyone you send it to. Your annotations get saved with the capture, and your filters get embedded right in the URL. When someone else sees the link you send, they’ll know exactly what you’re talking about!
Take a look at the capture below. It has a number of ICMP unreachable packets related to DNS requests. Why is this happening? Is this normal?
http://cloudshark.org/captures/a02f4f4a0df0?filter=dns%20%7C%7C%20icmp
Send your answer to info@cloudshark.org with your address and T-shirt size and we’ll send you one of our snazzy CloudShark shirts!
Happy packet surfing!
