none
Resolving domain .local. changed behavoir from windows 10 (1803) to windows 10 (1809) RRS feed

  • Question

  • I'm using apples Bonjours service to discover a service bla.local on windows 10 version 1803 (and all the why back to windows 7) everything was great. I could connect to the service using the host name "bla.local." now it stopped working.

    In windows 10 version 1809 you have to use bla.local (without out the last dot)

    In other words ping bla.local. worked before now only ping bla.local works

    Is this intended new behavior?

    If i disable the service Client DNS and reinstall bonjour i get the old behavior back.  

    /kasper

    Monday, February 25, 2019 10:43 AM

All replies

  • Hi,

    Thanks for posting in the forum.

    Based on our knowledge, .local is generally used for multicast in Bonjour (mDNS) lookups.

    mDNS and DNS servers on the same network using .local can be problematic.

    Does the issue persist if you ping a hostname with a different suffix?

    By the way, we recommend you refer to experts in Apple Support Communities to get more professional support.

    https://discussions.apple.com/welcome

    Regards,

    Zoe


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, February 26, 2019 2:15 AM
  • Hi,

    Thanks for answering. Yes it is mDNS. The issue is that it was working before windows version 1809. As i understand windows 10 have started support for mDNS. If i disable windows support for mDNS like this:

    Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
    Then set the value for EnableMulticast to 0

    Then everything is working again. I really do not think it is a bonjour issue but an issue with the windows implementation.

    On linux avahi behave like bonjour on windows: That is ping bla.local. is working.

    Pinging using absolute domains works for everything but local, that is

    ping google.com. is working on all windows versions

    ping bla.local. is not working on windows 10 version 1809. It works if I disable the windows 10 implementation of mDNS. Note the tailing dot after local

    Regards,

    Kasper


    Tuesday, February 26, 2019 6:52 AM
  • Hi,

    Thanks for the reply.

    We've found an article in apple support: https://support.apple.com/en-sg/HT201275

    Host names that contain only one label in addition to local, for example "My-Computer.local", are resolved using Multicast DNS (Bonjour) by default. Host names that contain two or more labels in addition to local, for example "server.domain.local", are resolved using a DNS server by default.

    Additionally, Mac OS X v10.6 automatically detects when the local network operator has set up a name server that will answer name requests for a domain ending in ".local". It does this by checking to see if there is a Start Of Authority (SOA) record for the top level domain "local", which is how a DNS server indicates that it claims to have authority over a part of the DNS namespace. As long as the DNS server is properly configured with the required SOA record, Mac OS X v10.6 will detect this SOA record and automatically use this server to look up all host names in the domain.

    Based on the description, would you please check to make sure that your device is configured with the IP address of an authoritative DNS server in .local. Domain?

    Regards,

    Zoe


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, February 26, 2019 8:26 AM
  • Hi,

    Thanks for reply. I fail to see why you keep referring to apple. We are not using apple products besides bonjour service.

    Recap

    ping mydevice.local is working on all windows 7, all windows 10 versions and linux versions

    ping mydevice.local. is working on windows 7, windows 10 expect version 1809 and linux.

    if i disable windows 10 attempt to implement mDNS then it is working on 1809.I have reproduced this on 5 different windows installations

    Regards,

    Kasper

    Tuesday, February 26, 2019 8:44 AM
  • Hi,

    Thanks for your update and sorry for all the inconvenience.

    We have submitted the issue to the product group.

    You may also visit the Feedback Hub app to send suggestions to help Microsoft improve your Windows experience.

     

    For your reference:

    Send feedback to Microsoft with the Feedback Hub app

    https://support.microsoft.com/en-sg/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app

     

    Your understanding and cooperation is appreciated.

    Regards,

    Zoe


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, February 28, 2019 9:50 AM
  • Hi,

    Thanks for your patience and cooperation.

    This may due to a RS4 bug when introducing mDNS query to dnsaip.dll.

    Starting from RS4,  a feature to dnsapi.dll is added to have the client OS perform mDNS query as the first choice of broadcast name resolution. If mDNS response comes back earlier than LLMNR, dnsapi will return mDNS result to RPC call and discard LLMNR response. when this mDNS result contains IPv6 records, the IPv6 record is missing scope id, this causes the mDNS response can’t be processed. Hence name resolution fails.

     

    In this case, disabling IPv6 will be a workaround.

     

    To verify the issue, would you please take the following instructions :

    1. run command 
      >netsh trace start capture=yes overwrite=yes globallevel=0xff scenario=internetclient_dbg maxsize=512 tracefile=c:\winsock.etl
    2. reproduce the issue
    3. run command 
      >netsh trace stop

    If you see an mDNS query has been returned (udp.port==5353), and the decoded ETL has an pattern like below, then this matches the bug.

    187521 [0]2154.0BA8::07/02/18-06:53:27.8684203 [Microsoft-Windows-DNS Client Events/Operational ] DNS query is completed for the name WORKGROUP-2018-2, type 28, query options 2251800887583744 with status 0 Results fe80::c98d:e8e:994b:2816;192.168.0.27;type:  47 ;   //<-- DNS API replied with Ipv6 and Ipv4 address 

    187536 [0]2154.0BA8::07/02/18-06:53:27.8702055 [Microsoft-Windows-Winsock NameResolution Event/Operational ] GetAddrInfoW is completed for queryName WORKGROUP-2018-2 with status 11004 and result   //<-- 11004 means WSANO_DATA, no results.

     

    Regards,

    Zoe


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Monday, March 4, 2019 9:19 AM
  • Hello again

    Thank you for response. Disabling IPv6 does not resolve the issue.

    Regards,

    Kasper

    Wednesday, March 13, 2019 9:08 AM