Excessive DNS queries for NTP pool addresses | Hacker News Reader

Excessive DNS queries for NTP pool addresses

forum.flightradar24.com

78 pointsefftee28 comments

The NTP Pool has very simple guidelines for vendors distributing software with hard-coded NTP server names. Very simply, they ask that you set up a vendor DNS alias. Details here: http://www.pool.ntp.org/en/vendors.html#basic-guidelines

The NTP Pool is an incredibly valuable public resource. It's run by volunteers, all they ask is you treat the resource with respect so it works for everyone.

It's really amazing that we've seen so many of the issues in the past. If you use standard tools in the standard way, you're not going to create any floods. It baffles me that vendors are re-inventing the wheel and generating NTP floods.

I can't help feel that we have gotten a generation of programmers and whatsnot that has no respect for existing tools. Rather than try to grok what is already out there they will instead grab whatever is the hyped language of the day and roll their own.

You're just describing inexperienced but somewhat technically competent developers. I was also like that at the beginning of my career. Most of the programmers go through this way. I guess the difference these days is that the ratio of people at the beginning of their careers to the seasoned developers is way higher and they are being assigned more and more critical tasks as demand goes through the roof.

And if you tell them that they are barking up the wrong tree, they run to social media to get you labeled as a "hater"...

Try explaining that to Poettering. [1] [2]

[1] https://lists.freedesktop.org/archives/systemd-devel/2014-Au...

[2] https://github.com/systemd/systemd/issues/437

I think you linked something that has little to do with the subject at hand in order to take a jab at Poettering. Lame behaviour.

The issue, as I remember it, is more complex than you suggest with your quip. Who is the vendor for a distributed copy of systemd, is it systemd or the distributor?

Both threads are exactly about the subject of the discussion. How does it have “little to do with the subject at hand?”

I think the context that a lot of people seem to miss is that this default was never used in practice with a real Linux distro. So in effect it was never really an issue in the real world since the default was always changed.

Then why provide a default at all? Especially one that isn't suppose to be used publically like google's?

So systemd at least compiles without manual settings, and convention over configuration trends. It would be ideal if they just setup their own NTP server for the default though. I think from a practical perspective though the whole thing was blown out of proportion.

It requires a configuration file to even compile? How's that work?

Oh, they already warn for using the default: https://github.com/systemd/systemd/pull/554 (which happen to be timeX.google.com)

Later in the thread:

> I looked at it in some more detail a few hours after I posted this and it looks like this isn't a "normal" feature of the FR24 client but rather a failure to handle DNS problems gracefully. An issue with a local DNS server meant it was returning "domain not found" for some domains, including the *.pool.ntp.org domains.

> It seems the FR24 client has embedded calls to system programs to would find the first working (i.e successful ping) NTP host, sync up time from there and then carry on, but in this case as each host fails it tries the next in the list and when the list is exhausted it starts again from the top. Thus firing off an endless stream of DNS queries at a high rate until it manages to connect to an NTP server. The ICMP traffic wasn't actually generated in this case as the ping command fails because in my specific case the host address couldn't be found, for NTP servers that are in the pool but block ICMP this would generate traffic but still fail a ping.

> The local DNS problem turned out to be a misbehaving Pi-Hole installation on my home network refusing some DNS queries but it would be nice to see some kind of backoff algorithm or delay in the client, or preferably just insist on a working NTP client on the feeder rather than forced NTP syncs via external commands and a liberal use of ping.

Seems like the title is misleading.

It seems not, because, even later:

"fr24feed appears to be doing 12 NTP queries direct to servers around the world every ten minutes, which is about three times as much load as the pool recommends and appears to be a very high load on the parts of the world where there are few volunteers running NTP servers"

https://forum.flightradar24.com/threads/11042-Excessive-DNS-...

While 1.2 vs 0.4 requests per minute is indeed a factor of three, calling it "abuse" instead of something like "misconfigured" or "misuse" seems overblown.

What are you going to call the initial report of thousands of requests per second then?

It's not overblown to characterize something about a system you are told not to do "abuse". If it is misuse, it is abuse. Words mean things.

Words do in fact mean things, and that's why there's so many of them. Abuse and misuse are two similar words with distinct connotations. Abusing something means it's intentional and is causing significant harm. Misusing something means using it in a way that could be accidental or intentional, but is contrary to the way the thing should be used.

I have to agree with the other person, unless this was done intentionally and the programmer knew it would cause damage, calling it abuse sounds overly dramatic. I think the word misuse is far more accurate here.

The second they said "we're not fixing that" it became conscious deliberate inconsiderate abuse. That was a typical and awful response to that bug report.

The original poster essentially pointed out some bad engineering. "it works for most people" is an utter crap response to that.

Send an email to misuse@example.com and explain the problem and I'm sure someone will get right on it.

Wait--you mean to tell me it's abuse@ for a reason...?

I see your point, but I've worked with systems which have quotas like "one read per minute" or "one network request per second". They exist, their quotas are set based on real limits, and we need to be honest about overload on our shared common resources.

Keep reading. They hammer hardcoded NTP servers constantly, as opposed to abiding by the pool guidelines

This sounds like a bug (or maybe two bugs), not the result of any sort of policy decision. So, before taking a combative stance and trying to shame them into fixing it, it's important to make sure the relevant information has actually reached the person who actually could fix it, and they've had some time to work!

The first post in that thread was made 2017-05-03.

Okay, but did it actually get read by the right person? It's very easy for bug reports that came in the form of forum posts to slip by unnoticed. Or noticed by tech support people who don't realize it might be worth escalating to dev.

I used to love FL24, until it stopped supporting its Mac client which I paid for, rendering it useless. All you get is a message asking you to subscribe to the program you've already paid for.

What did the desktop client have that the web interface doesn't? Would love an OS X client personally.

Primarily speed. Secondarily, the ability to display full-screen across a 27-inch display.

Reply on news.ycombinator.com