3 ms·

NMBD and WINS name resolutions are dead on Windows too; normal DNS is used since the AD was introduced. For service discovery, WSD is supposed to be used now, W

NMBD and WINS name resolutions are dead on Windows too; normal DNS is used since the AD was introduced. For service discovery, WSD is supposed to be used now, Windows 10 and Windows 2016/19 are slowly killing SMB1. Windows itself doesn't really play nice with mDNS/DNS-SD (Bonjour).

WorldMaker 7y ago
Windows works just fine with mDNS/DNS-SD, it's just that they learned a lot from WINS and SMB1 and are a lot tighter on which multicast IPs they respond to and when. (With security things like "HomeGroups" and similar mediating.) It doesn't always support the .local pseudo-DNS, but that's a relatively more recent standard, and also another place where Windows' back compat and learned mistakes cause it to be very cautious with .local addresses, especially given some Enterprises still use .local for LAN addresses not intended to be multicast DNS, despite that now being the IETF recognized standard.
- vetinari 7y ago
  .local is reserved for mDNS by the same RFC that defines mDNS itself (RFC6762), which is from 2013, so not that recent. If Windows plays games with responder, it is them breaking the standard. Last time I looked, (which is some time ago), Bonjour was available only for modern apps, where they could do discovery for their own counterparts on the network, but not as general, system integrated service. For example, I've never seen that windows smb client could discover SMB shares advertised by Bonjour, that macOS and Linux clients do find. It needs either WSD, or SMB1. But it is true, that some enterprises abuse .local for their internal network, even for new installations. The answer I got was "it is best practices", but never got an answer where these "best practices" are from. But hey, it is their problem now.
  - WorldMaker 7y ago
    > .local is reserved for mDNS by the same RFC that defines mDNS itself (RFC6762), which is from 2013, so not that recent Right, but A) the RFC post-dates a lot early implementation of "Bonjour" (and the name "Bonjour"), and B) 2013 is unfortunately still "recent" in Windows terms given that Windows 7 was released in 2009. (And Microsoft was trying to get standardized their own variation on mDNS, PNRP in just the previous Windows release. It was kind of a neat attempt as it was built as a DHT rather than purely multicast, though I digress.) mDNS currently is still limited to UWP APIs, but now more than ever Win32 applications and not just "Modern Apps" can make use of them. Unfortunately, I don't think it will ever be built into SMB share support at the network filesystem level, because again I think Microsoft is trying too hard to distance themselves from many decades of mistakes in SMB1. We'll see what happens. > where these "best practices" are from Ironically, .local was used as an example for several years in Active Directory setup documentation, though even then it was highlighted only as a possible stop-gap until a proper DNS name and proper TLS Certificates could be purchased. But, of course, people read the first half and ignore the caveats (especially because they cost money and time to correct) and think they are following "best practices". More evidence for the pile that so much of "best practices" in IT are a cult mentality that only ever read the first half of some recommendation and then blindly followed it forever after.
    - vetinari 7y ago
      > A) the RFC post-dates a lot early implementation of "Bonjour" (and the name "Bonjour"), It was called "Rendezvous" originally in OSX 10.2. When the RFC came out, the protocol was already ~11 years old. Apple can drag its feet too :) But then, I'm not sure if that makes the whole situation for better, or worse. > B) 2013 is unfortunately still "recent" in Windows terms given that Windows 7 was released in 2009. Windows 7 could at least use the Apple Bonjour implementation, so the support, or lack of it, would be understandable. For Windows 10, soon to be the only supported version, I would expect differently. > And Microsoft was trying to get standardized their own variation on mDNS, PNRP in just the previous Windows release. Microsoft also got us LLMNR with Vista/2008... So they were aware about Bonjour, but they made their own. > I think Microsoft is trying too hard to distance themselves from many decades of mistakes in SMB1. Bonjour discovery doesn't need SMB1. SMB2 and 3 (which have the discovery part of SMB1 removed) work great with Bonjour, so that would allow Microsoft to distance themselves from SMB1. In the SOHO market, Synology devices support this mode with a nice GUI config; not sure about QNAP/Asustor/others. What Microsoft is currently doing, is that they support WSD discovery for SMB, when SMB1 is off. Here, we are also getting slightly off-course. While both name resolution and discovery are hidden under the name Bonjour, only the name resolution and .local domain are part of the mDNS. The service discovery is DNS-SD, separate protocol, which can run on top of mDNS, but also on top of classic, infrastructure DNS. > Ironically, .local was used as an example for several years in Active Directory setup documentation, though even then it was highlighted only as a possible stop-gap until a proper DNS name and proper TLS Certificates could be purchased. Ah, so there it comes from. Obviously, I didn't read the AD setup documentation either :). The funny thing is, that they didn't need to purchase TLS certificates, only to have a single real domain and make a subdomain for AD. For certificates, they could use ADCS! (but I guess that would be additional reading).
      - WorldMaker 7y ago
        Don't get me wrong, I was saddened to notice that I couldn't easily just use .local name resolution for a P2P app and have it easily work out of the box on Windows 10 in every application stack I could wish (more so than file share discovery, it's disappointing to me that Windows Browsers don't support .local well or at all because the default Win32 DNS resolvers don't consider mDNS at all), but on the flipside, the APIs that do speak mDNS work and work well. I'm sympathetic why the new APIs are opt-in WinRT/COM++ APIs instead of just another opt-out magic kludge in the Win32 stack, but yes it's harder to think of it as a platform-wide service when it isn't on-by-default and requires development effort to support. > Microsoft also got us LLMNR with Vista/2008... So they were aware about Bonjour, but they made their own. Vista was the hangover after the ivory tower perfection attempts of Longhorn. In retrospect we should probably be excited they didn't reinvent more wheels than what they did. ;)

WorldMaker 7y ago

Windows works just fine with mDNS/DNS-SD, it's just that they learned a lot from WINS and SMB1 and are a lot tighter on which multicast IPs they respond to and when. (With security things like "HomeGroups" and similar mediating.) It doesn't always support the .local pseudo-DNS, but that's a relatively more recent standard, and also another place where Windows' back compat and learned mistakes cause it to be very cautious with .local addresses, especially given some Enterprises still use .local for LAN addresses not intended to be multicast DNS, despite that now being the IETF recognized standard.

vetinari 7y ago
.local is reserved for mDNS by the same RFC that defines mDNS itself (RFC6762), which is from 2013, so not that recent. If Windows plays games with responder, it is them breaking the standard. Last time I looked, (which is some time ago), Bonjour was available only for modern apps, where they could do discovery for their own counterparts on the network, but not as general, system integrated service. For example, I've never seen that windows smb client could discover SMB shares advertised by Bonjour, that macOS and Linux clients do find. It needs either WSD, or SMB1. But it is true, that some enterprises abuse .local for their internal network, even for new installations. The answer I got was "it is best practices", but never got an answer where these "best practices" are from. But hey, it is their problem now.
- WorldMaker 7y ago
  > .local is reserved for mDNS by the same RFC that defines mDNS itself (RFC6762), which is from 2013, so not that recent Right, but A) the RFC post-dates a lot early implementation of "Bonjour" (and the name "Bonjour"), and B) 2013 is unfortunately still "recent" in Windows terms given that Windows 7 was released in 2009. (And Microsoft was trying to get standardized their own variation on mDNS, PNRP in just the previous Windows release. It was kind of a neat attempt as it was built as a DHT rather than purely multicast, though I digress.) mDNS currently is still limited to UWP APIs, but now more than ever Win32 applications and not just "Modern Apps" can make use of them. Unfortunately, I don't think it will ever be built into SMB share support at the network filesystem level, because again I think Microsoft is trying too hard to distance themselves from many decades of mistakes in SMB1. We'll see what happens. > where these "best practices" are from Ironically, .local was used as an example for several years in Active Directory setup documentation, though even then it was highlighted only as a possible stop-gap until a proper DNS name and proper TLS Certificates could be purchased. But, of course, people read the first half and ignore the caveats (especially because they cost money and time to correct) and think they are following "best practices". More evidence for the pile that so much of "best practices" in IT are a cult mentality that only ever read the first half of some recommendation and then blindly followed it forever after.
  - vetinari 7y ago
    > A) the RFC post-dates a lot early implementation of "Bonjour" (and the name "Bonjour"), It was called "Rendezvous" originally in OSX 10.2. When the RFC came out, the protocol was already ~11 years old. Apple can drag its feet too :) But then, I'm not sure if that makes the whole situation for better, or worse. > B) 2013 is unfortunately still "recent" in Windows terms given that Windows 7 was released in 2009. Windows 7 could at least use the Apple Bonjour implementation, so the support, or lack of it, would be understandable. For Windows 10, soon to be the only supported version, I would expect differently. > And Microsoft was trying to get standardized their own variation on mDNS, PNRP in just the previous Windows release. Microsoft also got us LLMNR with Vista/2008... So they were aware about Bonjour, but they made their own. > I think Microsoft is trying too hard to distance themselves from many decades of mistakes in SMB1. Bonjour discovery doesn't need SMB1. SMB2 and 3 (which have the discovery part of SMB1 removed) work great with Bonjour, so that would allow Microsoft to distance themselves from SMB1. In the SOHO market, Synology devices support this mode with a nice GUI config; not sure about QNAP/Asustor/others. What Microsoft is currently doing, is that they support WSD discovery for SMB, when SMB1 is off. Here, we are also getting slightly off-course. While both name resolution and discovery are hidden under the name Bonjour, only the name resolution and .local domain are part of the mDNS. The service discovery is DNS-SD, separate protocol, which can run on top of mDNS, but also on top of classic, infrastructure DNS. > Ironically, .local was used as an example for several years in Active Directory setup documentation, though even then it was highlighted only as a possible stop-gap until a proper DNS name and proper TLS Certificates could be purchased. Ah, so there it comes from. Obviously, I didn't read the AD setup documentation either :). The funny thing is, that they didn't need to purchase TLS certificates, only to have a single real domain and make a subdomain for AD. For certificates, they could use ADCS! (but I guess that would be additional reading).
    - WorldMaker 7y ago
      Don't get me wrong, I was saddened to notice that I couldn't easily just use .local name resolution for a P2P app and have it easily work out of the box on Windows 10 in every application stack I could wish (more so than file share discovery, it's disappointing to me that Windows Browsers don't support .local well or at all because the default Win32 DNS resolvers don't consider mDNS at all), but on the flipside, the APIs that do speak mDNS work and work well. I'm sympathetic why the new APIs are opt-in WinRT/COM++ APIs instead of just another opt-out magic kludge in the Win32 stack, but yes it's harder to think of it as a platform-wide service when it isn't on-by-default and requires development effort to support. > Microsoft also got us LLMNR with Vista/2008... So they were aware about Bonjour, but they made their own. Vista was the hangover after the ivory tower perfection attempts of Longhorn. In retrospect we should probably be excited they didn't reinvent more wheels than what they did. ;)