Wireshark-bugs: [Wireshark-bugs] [Bug 2472] New: Decoding error in protocol DNS - section Flags
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Wed, 16 Apr 2008 23:50:52 -0700 (PDT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2472

           Summary: Decoding error in protocol DNS - section Flags for AD
                    and CD bits information
           Product: Wireshark
           Version: 1.0.0
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: Major
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: frank.maerz@xxxxxxxxxxx


Created an attachment (id=1704)
 --> (http://bugs.wireshark.org/bugzilla/attachment.cgi?id=1704)
Example Trace PCAP

Build Information:
Any version, up to 1.0.0 an linux, Windows and Mac
--
Hello Wireshark Expert,

I think I have found a problem within Wireshark while decoding two bits within
the DNS protocol. The problem can be seen in all Wireshark version I tried up
to 1.0.0 on several OS. Wireshark fails to decode the Flags section for the bit
AD and CD. 

Details are in:

RFC2535 - 6.1 The AD and CD Header Bits

                               1  1  1  1  1  1
             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                      ID                       |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    QDCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    ANCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    NSCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    ARCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


This is the trace in text format:



No.     Time        Source                Destination           Protocol Info
     50 41.833438   193.254.142.169       213.162.74.3          DNS     
Standard query A web.mnc007.mcc232.gprs

Frame 50 (93 bytes on wire, 93 bytes captured)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 69:31:65:74:68:34
(69:31:65:74:68:34)
Internet Protocol, Src: 193.254.142.169 (193.254.142.169), Dst: 213.162.74.3
(213.162.74.3)
User Datagram Protocol, Src Port: 35211 (35211), Dst Port: domain (53)
Domain Name System (query)
    [Response In: 59]
    Transaction ID: 0xcf13
    Flags: 0x0110 (Standard query)
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..X. .... = AD: missing
        .... .... ...1 .... = CD: Non-authenticated data OK: Non-authenticated
data is acceptable 
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
    Additional records

0000  69 31 65 74 68 34 00 00 00 00 00 00 08 00 45 00   i1eth4........E.
0010  00 4f e4 a8 40 00 fd 11 28 a7 c1 fe 8e a9 d5 a2   .O..@...(.......
0020  4a 03 89 8b 00 35 00 3b db 2f cf 13 01 10 00 01   J....5.;./......
0030  00 00 00 00 00 01 03 77 65 62 06 6d 6e 63 30 30   .......web.mnc00
0040  37 06 6d 63 63 32 33 32 04 67 70 72 73 00 00 01   7.mcc232.gprs...
0050  00 01 00 00 29 10 00 00 00 80 00 00 00            ....)........

No.     Time        Source                Destination           Protocol Info
     57 41.854500   213.162.74.3          193.254.142.169       DNS     
Standard query response A 213.162.74.125 A 213.162.74.126

Frame 57 (167 bytes on wire, 167 bytes captured)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 69:31:65:74:68:31
(69:31:65:74:68:31)
Internet Protocol, Src: 213.162.74.3 (213.162.74.3), Dst: 193.254.142.169
(193.254.142.169)
User Datagram Protocol, Src Port: domain (53), Dst Port: 35211 (35211)
Domain Name System (response)
    [Request In: 53]
    [Time: 0.021033000 seconds]
    Transaction ID: 0xcf13
    Flags: 0x8590 (Standard query response, No error)
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... 1... .... = Recursion available: Server can do recursive
queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = AD: missing
        .... .... ...1 .... = CD: Answer authenticated: Answer/authority
portion was not authenticated by the server

        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 2
    Authority RRs: 1
    Additional RRs: 2
    Queries
    Answers
    Authoritative nameservers
    Additional records

0000  69 31 65 74 68 31 00 00 00 00 00 00 08 00 45 00   i1eth1........E.
0010  00 99 d5 6c 40 00 f9 11 3b 99 d5 a2 4a 03 c1 fe   ...l@...;...J...
0020  8e a9 00 35 89 8b 00 85 e5 d0 cf 13 85 90 00 01   ...5............
0030  00 02 00 01 00 02 03 77 65 62 06 6d 6e 63 30 30   .......web.mnc00
0040  37 06 6d 63 63 32 33 32 04 67 70 72 73 00 00 01   7.mcc232.gprs...
0050  00 01 c0 0c 00 01 00 01 00 00 02 58 00 04 d5 a2   ...........X....
0060  4a 7d c0 0c 00 01 00 01 00 00 02 58 00 04 d5 a2   J}.........X....
0070  4a 7e c0 10 00 02 00 01 00 00 02 58 00 0e 0b 44   J~.........X...D
0080  4e 53 2d 31 2d 4e 65 74 2d 41 c0 10 c0 54 00 01   NS-1-Net-A...T..
0090  00 01 00 00 02 58 00 04 d5 a2 4a 03 00 00 29 10   .....X....J...).
00a0  00 00 00 00 00 00 00  

                            .......




In the DNS request the AD bit information is missing at all. In the DNS
response the AD bit is present, the CD bit is missing and the text for CD is
linked to the AD bit.


I will attach a trace in pcap format. Sorry I don't know C so I can not fix the
source code myself.



RFC2535 - 6.1 The AD and CD Header Bits


   Two previously unused bits are allocated out of the DNS
   query/response format header. The AD (authentic data) bit indicates
   in a response that all the data included in the answer and authority
   portion of the response has been authenticated by the server
   according to the policies of that server. The CD (checking disabled)
   bit indicates in a query that Pending (non-authenticated) data is
   acceptable to the resolver sending the query.

   These bits are allocated from the previously must-be-zero Z field as
   follows:

                                           1  1  1  1  1  1
             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                      ID                       |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    QDCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    ANCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    NSCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    ARCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   These bits are zero in old servers and resolvers.  Thus the responses
   of old servers are not flagged as authenticated to security aware
   resolvers and queries from non-security aware resolvers do not assert
   the checking disabled bit and thus will be answered by security aware
   servers only with Authenticated or Insecure data. Security aware
   resolvers MUST NOT trust the AD bit unless they trust the server they
   are talking to and either have a secure path to it or use DNS
   transaction security.

   Any security aware resolver willing to do cryptography SHOULD assert
   the CD bit on all queries to permit it to impose its own policies and
   to reduce DNS latency time by allowing security aware servers to
   answer with Pending data.

   Security aware servers MUST NOT return Bad data.  For non-security
   aware resolvers or security aware resolvers requesting service by
   having the CD bit clear, security aware servers MUST return only
   Authenticated or Insecure data in the answer and authority sections
   with the AD bit set in the response. Security aware servers SHOULD
   return Pending data, with the AD bit clear in the response, to
   security aware resolvers requesting this service by asserting the CD
   bit in their request.  The AD bit MUST NOT be set on a response
   unless all of the RRs in the answer and authority sections of the
   response are either Authenticated or Insecure.  The AD bit does not
   cover the additional information section.


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.