In which The Steve earns my ire yet again

[unixronin]

Specifically, for yet another "clever" Apple technology with unintended consequences.

You see, ever since getting my new machine up, I've been noticing a really excessive amount of clock drift relative to my internal stratum-3 network timeserver.  Like, six seconds per day of clock drift.  This is really bad considering I'm running ntp.  The old babylon5 had some clock drift, but never this bad.

Today, I finally found the problem.  And the problem is that mDNS is shooting me in the foot.

mDNS is Apple's multicast DNS technology, and certain Linux packages — CUPS, for one, also created at Apple — are really rather difficult to persuade not to use it.  But when you install it on linux, it never gets properly configured.  The file /etc/nss-mdns.conf — which should contain a list of domains for which mdns SHOULD resolve IP addresses — is not created, and the package doesn't tell you that you should.  What's more, there's no documentation installed on doing so.

Now, this shouldn't be a problem.  You see, here's what should, if mdns were reasonably designed, happen when, say, ntpdate tries to synchronize to a timeserver:

1. ntpdate requests an IP address for the designated timeserver.
2. nsswitch checks the /etc/hosts file.  It doesn't find the IP there, so it passes the request to mDNS.
3. mDNS checks /etc/nss-mdns.conf and finds it empty or nonexistent.  mDNS says "Oh, no domains for me to resolve, nothing for me to do here", and passes the request to DNS.
4. DNS looks up the address, passes it back to ntpdate, and ntpdate makes the connection to the correct server.

But, Apple being Apple, this is what REALLY happens:

1. ntpdate requests an IP address for the designated timeserver.
2. nsswitch checks the /etc/hosts file.  It doesn't find the IP there, so it passes the request to mDNS.
3. mDNS checks /etc/nss-mdns.conf and finds it empty or nonexistent.  mDNS says "Oh, there's no list of domains for me to resolve, but you didn't explicitly tell me NOT to resolve anything, so here, LET ME GIVE YOU SOME RANDOM IP ADDRESS THAT I PULLED OUT OF SOMEONE ELSE'S ASS BASED ON MY OWN HIDDEN COMPILED-IN DEFAULTS.  It's not even REMOTELY in your network, but what the heck, what you don't know won't hurt you, right?"
4. "Gee, ntpd is running, but my clock's still wrong.  How can that happen...?"

Apple has from time to time come up with some very good ideas.  The aforementioned CUPS, for example, works very well.  My opinion of Apple would, however, be rather less jaundiced did it not so frequently appear that when designing or implementing a technology, Apple looks at what the rest of the world is doing, then deliberately does something incompatible.¹

I disabled mdns in /etc/nsswitch.conf, restarted ntp, and SHAZAM!  Magically, just like that, my machines' clocks are perfectly synchronized.

[1]  Possibly the classic example of all time² is Apple's proprietary Appletalk network protocol, in which network address assignment is basically accomplished by jabbering.  In every OTHER network protocol that I'm aware of on the face of the planet, jabbering is considered to be a severe networking failure.  This is why, whenever an Appletalk network exceeded a certain rather small number of nodes, nodes would start just randomly dropping in and out of view on the network.  There was nothing you could do about it.  You couldn't fix it.  Apple eventually sort of fixed it, by creating Appletalk Phase II, which divided networks up into zones, and an Appletalk device could only talk to other devices in the same zone that it was in.  This didn't fix the problem, but it sort of alleviated it.  Somewhat.

[2]  Though a close runner-up is the Apple one-global-system-menubar metaphor, which was bad enough on single-monitor Macs, but really broke hard when Macs started being able to handle multiple monitors.  A list of everything that's wrong with the single-system-menubar metaphor would be a post of its own.  Yet twenty years on, MacOS users are STILL stuck with it.³  Apple insisted that This Was The Best Way To Do It, because they had called in Efficiency Experts.  What I've always wanted to know is, did the "efficiency experts" know anything whatsoever about using computers in the real world?

[3]  The saddest part is, they don't care, because The Steve Has Decreed That It Is Good.