6 ms·
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 bu
by SiempreViernes 9y ago
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.
- mdekkers 9y agoKeep reading. They hammer hardcoded NTP servers constantly, as opposed to abiding by the pool guidelines
- acqq 9y agoIt 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-queries-for-NTP-pool-addresses?s=9c2a36a984a38ff32360f8f3d10efc28&p=101240&viewfull=1#post101240 https://forum.flightradar24.com/threads/11042-Excessive-DNS-...
- SiempreViernes 9y agoWhile 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?
- eropple 9y agoIt'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.
- freehunter 9y agoWords 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.
- eropple 9y agoSend 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...?
- deleted 9y ago[deleted]
- Brian_K_White 9y agoThe 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.