This time around, packets from one of my own DNS servers. If you would like to follow along, you can find the full unobfuscated packet trace here.

(quick update... turns out that the router and DNS queries involved are part of www.nlnetlabs.nl, a network research labs that does experiment with DNS servers... so maybe this is all some side effect of an experiment they are running. Thanks to Don for pointing this out to me. After visiting their website, I did see a number of similar ICMP admin prohibited packets with flipped fragmentation bytes, but the embeded packet's source port was 80! ;-) )

You should find 9 packets. To abbreviate, I am using the following notation:
DNS = my DNS Server
Q = DNS Query Source
R = router sending ICMP Admin Prohibited messages.

Here the "big picture":

  Q  -> DNS: Query for NS sans.org
  Q  -> DNS: Query for A sans.org
DNS  -> Q  : Response, Server failure
DNS  -> Q  : Response, Server failure
  Q  -> DNS: Query for MX sans.org
DNS  -> Q  : Response, Server failure
R -> DNS: ICMP Admin prohibited
R -> DNS: ICMP Admin prohibited
R -> DNS: ICMP Admin prohibited

These are all the packets my system exchanged with these three systems at the time. Overall, this happened in about 0.13 second. The server failure was actually a temporary issue. The DNS server is authoritative for 'sans.org' and usually responds to these queries.

Lets look at the big picture first:
We got three DNS queries, three DNS responses and three "admin prohibited" packets. Kind of makes sense. A host is requesting information from our DNS server, but a (misconfigured?) router is rejecting the responses. The timing is a bit off (would have expected 'Query','Response','ICMP' ... 'Query','Response','ICMP'...). But this is not that unusual.

So lets look at the packets in detail. First the Query for 'NS sans.org':

Internet Protocol, Src: 213.154.224.17 (213.154.224.17), Dst: 70.91.145.9 (70.91.145.9)
    Total Length: 65
    Identification: 0x4aa5 (19109)
        .0.. = Don't fragment: Not set
    Time to live: 47
    Protocol: UDP (0x11)
User Datagram Protocol, Src Port: 63417 (63417), Dst Port: domain (53)
    Length: 45
Domain Name System (query)
    Transaction ID: 0x3180
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        sans.org: type NS, class IN
            Name: sans.org
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
    Additional records
        : type OPT
            Name: 
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            

I removed some lines from the tethereal output. The packet looks "normal" withe the one exception of EDNS0 being used. EDNS0 is used to indicate to the receiving DNS server that the querying DNS server is able to receive more then 512 bytes of the response as a UDP packet. In this case, its 4k. A bit large, and frequently large EDNS0 packets are used to increase the amplification f or denial of service attacks.

Couple other things if you compare the packets:

• the IP ID is incrementing. So these appear to be the only packets sent by the 'Q'.
• the source port is constant... odd...
• the DNS query IDs appear random.

Now lets look at the responses:

Internet Protocol, Src: 70.91.145.9 (70.91.145.9), Dst: 213.154.224.17 (213.154.224.17)

    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
User Datagram Protocol, Src Port: domain (53), Dst Port: 63417 (63417)
    Length: 45
    Transaction ID: 0x3180
    Flags: 0x8002 (Standard query response, Server failure)
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        sans.org: type NS, class IN
            Name: sans.org
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
    Additional records
        : type OPT
            Name: 
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            Z: 0x8000
                Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
                Bits 1-15: 0x0 (reserved)
            Data length: 0

The response from my DNS server: well, nothing unusual here. I would like to point out that no fragmentation is used (well, there is no need to). The 'DF flag is set. The IPID is set to 0, which is typically for recent Linux kernels if the DF flag is set.

Now lets look at the ICMP packets. These are the packets that caused me to look at this issue in the first place. So far, we don't actually have much out of the ordinary. I am using the last ICMP packet here:

Internet Protocol, Src: 213.136.31.102 (213.136.31.102), Dst: 70.91.145.9 (70.91.145.9)
    Total Length: 56
    Identification: 0x0000 (0)
    Time to live: 50
Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 13 (Communication administratively filtered)

[decoded embedded packet from ICMP message]
 Internet Protocol, Src: 70.91.145.9 (70.91.145.9), Dst: 213.154.224.17 (213.154.224.17)
        Total Length: 16640 (0x4100)
        Identification: 0x0000 (0)
        Flags: 0x00
        Fragment offset: 512
        Time to live: 50
        Protocol: UDP (0x11)
        Header checksum: 0xbb7b [incorrect, should be 0xba7c]
            Good: False
            Bad : True
        Source: 70.91.145.9 (70.91.145.9)
        Destination: 213.154.224.17 (213.154.224.17)
    Data (8 bytes)

0000  00 35 f7 b9 00 2d 3b 8b                           .5...-;.

Now this is where the "blast from the past" shows up:

Fragment offset 512Bytes. If you look at the Flag/Fragment offset bytes: 00 40.. flip them and you end up with '40 00' or: no fragment offset and 'do not fragment' flag set. hm... interesting...

Now if we just forget for a moment that this packet claims to be fragmented, we see that the "payload" is actually a normal UDP header: Source port 53 and Destination port 63417. This is the same port we had as a source port earlier. So if you ignore the fragmentation issue, this kind of looks like the result to the DNS response we sent earlier. Even the TTLs work out right! But then again... the size of the packet is HUGE. Looks like another byte-order issue: a size of 0x41 (65 bytes) is much closer to the size of the packet we sent.

We had a case a couple years ago with a similar byte order issue. But this is odd in the sense that the spoofed packet appears to be a direct result of the real packet. The spoofed packet is very close to the real packet. Maybe its not actually spoofed but just "mangled" by some kind of in-line device?