locked
Windows 10 spams network with invalid mDNS response packets RRS feed

 > 

  • General discussion

  • Discussion
    Sign in to vote
    5
    Sign in to vote

    Windows 10, in its default configuration, will spam its local networks by responding to all mDNS requests with null response packets.
    This appears to be in violation of RFC 6762 Section 6, which states:
    "A Multicast DNS responder MUST only respond when it has a positive, non-null response to send, or it authoritatively knows that a particular record does not exist."

    It is becomming an increasing problem on our networks, where compliant non-Microsoft equipment will often respond to an invalid mDNS packet by generating an error message, cluttering system logs and wasting ressources.
    As Windows 10 adoption rises, so does the need to filter out these error-generating packets. Just a handful of Windows 10 PCs on a subnet may broadcast hundreds of invalid packets per minute, causing an equal number of error messages to be generated on some devices, particularly those running an Avahi-based zeroconf implementation.

    I have not been able to find a way to report this bug directly to Microsoft, but if it isn't going to be fixed anytime soon, corporations might be forced to start filtering these erroneous mDNS packets from Windows 10.

    Does anybody know how to properly report this?



    • Edited by HelgeWL Thursday, August 20, 2015 1:04 PM
    Thursday, August 20, 2015 12:58 PM

All replies

  • Discussion
    Sign in to vote
    0
    Sign in to vote
    We have also been seeing this issue with windows 10 on our network.  I am not sure how to report this outside of the feedback center in windows 10.
    Friday, September 4, 2015 2:40 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    We just ran in to this the other day as well. Noticed all of my physical switches up 10-20% CPU as well as it hurting my wireless network with the Apple IOS devices hurting the most as they respond to this traffic. (Queue up conspiracy)

    We are a college so we had hundreds of student windows 10 devices. I had to shut off all multicast traffic on the wireless to get it straightened out.

    Monday, September 21, 2015 3:14 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    We are affected by this bug too..
    Wednesday, September 23, 2015 1:51 PM
  • Discussion
    Sign in to vote
    1
    Sign in to vote

    Hi,

    I do have the same problem, avahi-daemon on linux computers or servers reports a lot of invalid response packet, only from Windows 10 computers.

    There's obviously a problem with both systems, but I would appreciate a solution from Microsoft. I don't like to sea spammy multicasts for "nothing".

    Thank you !

    Tuesday, September 29, 2015 9:11 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    Same problem here.

    I make a report in "Windows Feedback".

    Friday, October 2, 2015 1:44 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    This has now been addressed by Avahi. These invalid mDNS entries will not be logged starting with Avahi version 0.6.32 IPv6 have been enabled by default in the same release.

    Microsoft should still fix the actual issue on their end, but at least the log harassment can be stopped.


    • Edited by NotDaniel Thursday, November 19, 2015 10:01 PM updated URL
    Saturday, October 10, 2015 1:54 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    And this issue has now been fixed in Windows 10 Insider.

    Update: Should be deploying over Windows Update to all Windows 10 users now.

    • Edited by NotDaniel Thursday, November 19, 2015 10:03 PM fix has now been released
    Monday, November 9, 2015 12:51 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    I wonder if this is the reason itunes on windows 10 can't reliably find any airplay targets?
    Tuesday, November 10, 2015 5:34 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    I wanted to circle back around on this issue and let you know this issue was fixed in Windows 10 1511 (10586) and higher builds. If you are seeing the issue on newer builds after 10586, please let me know.

    Thanks!

    Adam Rudell | Windows Networking Beta | Microsoft Corporation

    Tuesday, May 3, 2016 8:44 PM
  • Discussion
    Sign in to vote
    1
    Sign in to vote
    Yep, still seeing this affecting CentOS and Ubuntu machines with packets being received from Windows 10 machines on build 10586.
    Thursday, May 12, 2016 4:12 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    I also have stil this problem

    With kind regards, Bas van den Dikkenberg

    Tuesday, July 26, 2016 5:13 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    I also have this issue? Any sign of a Fix on the Windows 10 side?
    Thanks


    • Edited by Don O'Keeffe Thursday, September 8, 2016 3:39 PM
    Thursday, September 8, 2016 3:10 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    I'm still needing a fix for this as well.  Found floods of mDNS "Standard query response 0x0000" packets on our switches.  One Extreme Networks switch was giving me CPU Utilization errors multiple times a day.  Just found, every single device that was sending this data was a Windows 10 machine.

    I'd like to be able to shut down whatever in Windows 10 is doing this with a GPO so that I don't have to block all mDNS/Bonjour traffic.

    Thursday, September 29, 2016 5:05 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote
    Still have this problem on LTSB 1507, the only way to reduce CPU utilization, free up table space and block the mDNS traffic.
    Tuesday, April 4, 2017 6:45 AM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    I'm still seeing this problem does anyone know if there is a practical fix for this.

    Monday, April 1, 2019 5:42 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    I wanted to circle back around on this issue and let you know this issue was fixed in Windows 10 1511 (10586) and higher builds. If you are seeing the issue on newer builds after 10586, please let me know.

    Thanks!

    Adam Rudell | Windows Networking Beta | Microsoft Corporation

    Adam, we can assure you this issue still exists in version 1909, build 18363.693.  We just experienced enough traffic over this issue to take down an entire edge stack of switches.  Not excited about that... or the lack of resolution/response from Microsoft.  It would be great if there was a way to control this new behavior with Group Policy, or for it to simply be resolved by Microsoft.

    wjohnsonky, Extreme GTAC is always awesome and gave us this ACL for us to bandaid this problem from Microsoft:

    entry mdns {
                if {
                    destination-address 224.0.0.251/32;
                } then {
                    count mdns;
                    deny-cpu;
                }
            }
            
            
    entry llmnr {
                if {
                    destination-address 224.0.0.251/32;
                } then {
                    count llmnr;
                    deny-cpu;
                }
            }

    Hope it helps someone.

    Wednesday, March 11, 2020 1:53 PM
  • Discussion
    Sign in to vote
    0
    Sign in to vote

    Hi chrisakasoup,

    I apologize for not responding on this forum sooner. I have switched roles in the company and my alert notifications were buried in an old email rule that I recently removed. I still have some contacts with my old team and I will pass along the information to them.

    If anything else, I would suggest opening a support ticket with Microsoft so that we can collect network traces and other data points from your environment for investigation.

    I will let you know what I hear in the meantime.

    UPDATE: I reached out to some of my old colleagues and we have seen instances of these where mDNS is being sent out. It could be an application that is generating the mDNS traffic that is installed on your Windows workstations. For example, Apple's Bonjour uses mDNS and is known to send a lot of traffic on the wire. I am not saying in your instance it's Apple Bonjour service, but could be a different application installed on your workstations.

    My colleagues recommended to open a support ticket with Microsoft so we can investigate further with you to isolate where the traffic is originating from.

    If you do not want to pursue further investigation, then our recommendation is to apply firewall ACLs on your network equipment to block the traffic. 

    Regards,

    Adam Rudell | Azure Stack Hub | Microsoft Corporation



    Wednesday, March 11, 2020 2:26 PM