Bug ID: 14456
Summary: Wrong interpretation related to the most specific
dissector regarding DNS traffic encrypted by DNScrypt.
Component: Dissection engine (libwireshark)
Target Milestone: ---
Created attachment 16159
Compiled (64-bit) with Qt 5.9.2, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.54.2, with zlib 1.2.11, with SMI 0.4.8, with c-ares
1.13.0, with Lua 5.1.5, with GnuTLS 3.5.16, with Gcrypt 1.8.1, with MIT
Kerberos, with GeoIP, without nghttp2, without LZ4, without Snappy, without
libxml2, with QtMultimedia, without AirPcap, without SBC, without SpanDSP.
Running on Linux 4.15.3-300.fc27.x86_64, with Intel(R) Core(TM)2 Duo CPU
P9600 @ 2.53GHz, with 3896 MB of physical memory, with locale fi_FI.UTF-8,
libpcap version 1.8.1, with GnuTLS 3.5.18, with Gcrypt 1.8.2, with zlib 1.2.11.
Built using gcc 7.2.1 20180116 (Red Hat 7.2.1-7)
Wrong interpretation related to the most specific dissector regarding DNS
traffic encrypted by DNScrypt. In both cases output related to info-column with
respective filters 'quic' and 'dns' state systematically "Malformed packet".
Wireshark fails globally to recognized any No algorithm related to encryption.
On host computer DNXcrypt (https://github.com/jedisct1/dnscrypt-proxy – DNS
proxy, with support for modern encrypted DNS protocols such as DNSCrypt v2 and
DNS-over-HTTP/2 – DNSSEC compatible) is used (either as CLI, using component
dnscrypt-proxy or as Qt/KF5 GUI, a wrapper over dnscrypt-proxy).
Traffic capture on own computer with promiscuous mode non-activated on
Captures related to Case 1 and Case 2 are configured (Edit -> Preferences ->
Protocols DNS, UDP port) regarding DNS protocol respectively with default port,
53, and 443.
Assumed "Each dissector decodes its part of the protocol, and then hands off
decoding to subsequent dissectors for an encapsulated protocol."
By the way expression 'hands off decoding to subsequent dissectors for an
encapsulated protocol.' is written at least in a somewhat unclear way.
Wireshark misinterprets traffic analysed in such a way that it recognized that
the QUIC dissector is the most specific dissector for the captured data. Indeed
QUIC does run over UDP, therefore QUIC packets are classic UDP
packets.Nevertheless traffic is DNS.
Wireshark interprets traffic analysed in such a way that it recognized that the
DNS dissector is now the most specific dissector for the captured data, which
is the right interpretation. Nevertheless user has to interfere in order to get
the right dissector selected for that traffic, which is definitively not the
way such tool is designed for.
You are receiving this mail because:
You are watching all bug changes.
Sent via: Wireshark-bugs mailing list <email@example.com>