Wireshark · Wireshark-dev: Re: [Wireshark-dev] Wireshark decoding error- protocol DNS - section Flags for AD and CD bits inform

["Luis EG Ontanon" <luis@xxxxxxxxxxx>]

Hi,
Thanks for the detailed report and traces (traces are always very appreciated).

You better open a bug in http://bugs.wireshark.org that way we do keep
track of this. Or else we risk just loosing track of it.

Thanks,
Luis


On Fri, Apr 11, 2008 at 12:29 PM, März, Frank <Frank.Maerz@xxxxxxxxxxx> wrote:
>
>
>
> 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 with both massage in pcap format and text format.
> Sorry I don't know C so I can not fix the source code myself.
>
>
>
> Please let me know if I you need any more details.
>
>
>
> Best reagrds,
>
>
>
> Frank
>
>
>
>
>
>
>
> 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.
>
>  T-Mobile Deutschland GmbH
> Aufsichtsrat: Hamid Akhavan (Vorsitzender)
> Geschäftsführung: Philipp Humm (Sprecher), Thomas Berlemann, Stefan
> Homeister, Dr. Peter Körner, Günther Ottendorfer, Dr. Raphael Kübler, Dr.
> Steffen Roehn
> Handelsregister: Amtsgericht Bonn, HRB 59 19
> Sitz der Gesellschaft: Bonn
> WEEE-Reg.-Nr.: DE60800328
>
>
>
>
>
> _______________________________________________
>  Wireshark-dev mailing list
>  Wireshark-dev@xxxxxxxxxxxxx
>  http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>



-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan