Hacker News Reader

> For example, Linux DNS resolution is an arcane mess of upstream components bodged together over decades, about the place where sysvinit was before systemd came along.

Systemd has fixed this as well. Using systemd's networking stack DNS becomes completely seamless with the rest of the system. It's not quite 100% baked for average desktop users, but all the components are there and work great. You'll see distros switching to it soon... particularly workstation oriented ones as the wifi stack is soooo much nicer.

Does this do away with Network Manager, or do they somehow play nicely together.

Part of the reason why I've begun to dislike Linux is that things like networking used to be completely defined in config files, operated on by known commands.

Now it just seems like a hodgepodge of a dozen different daemons and applications writing over files, I honestly can't keep track of which is the authoritative config or app for interfaces, DNS, wifi, etc.

It can do away with NetworkManager or it can work with it. The integration with NM wasn't quite there in time for Debian Buster (which I use) but it was close and might be there now. They were working on it.

I have never used NetworkManager so can't comment intelligently on it. But I have it setup without it and it requires just a few config files. How many/how much config depends on how much you want to tweak things and how you want to organize things.

The main thing missing in the current stack is a nice interface for wifi. Using iwd for wifi has made things much better and if you don't mind CLI management it is quite nice.

For a bit more concrete of an example here is a gist I through up a while back describing replacing the old setup with a systemd based one.

https://gist.github.com/eikenb/1e9faeb8210e639e8caa69e9832db...

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).

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.

.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.

> .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.

> 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).

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. ;)

> ...but, so far as I can tell, they’re not doing this. I wonder why not?

Because maybe, just maybe, they're a tad bit less evil?

Beeing evil is expensive. All that empire structure is necessary to get people to be cooperative again.

Nonsense, a publicly traded corporation is inherently an immoral psychopath. They are required to single-mindedly pursue shareholder profit.

The people who make up the corporation are people. They need to be motivated, and they no not mobilize immediately.

Depends on shareholders, doesn't it? Those are the people that 'make up' the corp. The rest are pawns that either fall in line or end up recognizing that the only way to win the game is to not play (and thus quit).

If employees think their employer is doing something unethical, that harms morale.

If morale is harmed, good people are more likely to leave. If an employer has a poor reputation, it becomes harder to hire employees with in-demand skills.

Poor retention and difficulty in recruiting employees can end up harming the business.

Sadly there are far more workers with a broken moral compass than you'd think. Luckily, there are also enough with ethics and key positions to somewhat cancel that out, but I wouldn't say that unethical employers have a much harder time than ethical ones. It's probably simply a different spread on money/package/freedom within one such company. Plenty of people will believe what they are doing is justified and ignore any signs of cognitive dissonance if the pay check is right and internal communication is 'managed' enough by HR.

I don't think that's true. They are required to pursue what the shareholders deem important. That's usually profit, but sometimes there are votes to sway the company in a different direction. As a simple example of this, activist investors have spurred change in some industries that wasn't purely based on profit.[1]

1: https://oilprice.com/Energy/Energy-General/Activist-Investor...

Gates has always operated at the world level. In business, he wanted nothing less than total domination. The older, kinder Gates has a philanthropic ideology that is no less bold - he's thinking big, at the global level.

Being separated from that, Microsoft is doing what they are supposed to do - be Microsoft-centered, and focus on profit. But they can be more objective, with the founder's emotions no longer driving the company's direction.

Google won't sign Android up for this. People passionate enough about FOSS to run Linux desktops won't go for it. And those two pretty much are the Linux client ecosystem.

I thought system's resolvd was an attempt to fix all problems with dns resolution. Can you point me how it is not a solution, or how Microsoft could build something better instead of contributing to it?

So far, nss works more or less for me, except that .local takes a couple of minutes to resolve

# grep hosts /etc/nsswitch.conf hosts: files mymachines mdns [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

> Linux DNS resolution

I'm confused, do you mean the (remote) computers that resolve the DNS or do you mean your local machine?

No one would want to rely on MS ecosystem. Why would anyone trust them?