Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: [Ethereal-dev] RE: Ethereal DNS Traffic Storm - Clarified Post

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Wescott, David H" <david.h.wescott@xxxxxxxxx>
Date: Sun, 28 Mar 2004 15:25:09 -0800
Title: RE: Ethereal DNS Traffic Storm - Clarified Post

Michael,

Thanks for your response.  The "Help/About Ethereal" screen shows that the ADNS library was used.  Do you have any suggestions how we can obtain resources regarding ADNS to resolve the Ethereal DNS traffic storms?  These have also been observed with version 0.10.3.

Regards, David

    Picture (Device Independent Bitmap)

On 27, Mar 2004, at 19:40:29 Uhr, Michael Tuexen wrote:

    David,

    I have no experience with the Windows version of ethereal, but if
    you look at the Help/About Ethereal window, can you tell me if
    it is built with or without ADNS, a library for doing DNS queries?

    Best regards
    Michael

On 26, Mar 2004, at 19:25 Uhr, Wescott, David H wrote:

    Clarified Post:

    Just to clarify, this is not normal DNS traffic.? Consider that the rate is 1000+ frames per second, and that this traffic is going to all configured DNS servers simultaneously.? In addition, these are not the expected DNS queries carried by UDP.? These are TCP SYN frames to port 53.? When the DNS server responds with a SYN ACK, the Ethereal client aborts the connection with a TCP RESET.? This traffic is continuous until Ethereal is aborted, and no DNS information is gained, since all these port 53 connection attempts are unsuccessful.? In one case, an impacted user left their machine running in this state for 3 hours and this high rate of DNS traffic was constant for the entire time.? We have observed that this condition occurs during display and not capture, and that it will push the client CPU to 100%.? We believe that this is some type of bug, and not normal DNS traffic.? This condition only occurs when Ethereal is used, and of course only if DNS lookups are enabled.? However, we would like to get this corrected, so that DNS lookups can be used.

    Response From List:

    Yes. If you have the Network name resolution enabled while you capture or while you open a file it will cause lots of DNS requests.? You can disable the network name resolution and avoid this problem. See the attached JPG files for images of the two places you need to disable the DNS settings. This is captured from the Windows XP 10.2 version of the product.

    Original Post:

    We are seeing occasional DNS traffic storms that have been isolated to Ethereal.? We have confirmed cases with versions 0.9.14 and 0.9.15, as well as with the current version of 0.10.2.? The impacted devices were running Windows operating systems, but we do not know if that is a criteria.? We did several searches of the Ethereal mailing lists, but could not find any current reference to this issue.

    We have seen as high as 1,132 frames-per-second of DNS related traffic from a single Ethereal client.? We were able to capture a sample trace of an Ethereal DNS traffic storm.? There were a total of 547,226 frames of DNS related traffic in ~8 minutes (~36 Meg of network traffic).? In summary, the Ethereal client PC sent a total of 250,461 DNS connection attempts (TCP port 53) to 5 different DNS servers in ~8 minutes.? There were ~50K connection attempts per DNS server in the sample trace.? This traffic continued until the Ethereal application was aborted.? The client PC also went to 100% CPU while the DNS traffic storm was occurring.? The 3 valid DNS servers each answered as expected with a TCP SYN ACK.? The client then responded to these TCP SYN ACK frames with a TCP RST (Reset) aborting the connection attempt.

    Is anyone aware of this issue?? Please advise if you can provide some insight or direction regarding correcting this issue.? We posted this yesterday to the developers list, but so far no one has responded.