From my read of the article, this isn't a problem "in DNS." OP runs an uptime monitoring service that purports to check whether DNS can resolve your domain — but today OP learned that because he's hitting his ISP's recursive resolver, he doesn't notice downtime until the TTL of the previous response expires.
Solution (which everyone else does, and OP has now implemented): don't use your ISP's recursive resolver! Run your own instance of bind9 or whatever, with the cache disabled. Or it seems like `dig +trace` would probably work, too.
"Cached resources remain visible for their whole TTL, even if the original becomes unreachable or changes" seems like one of the very first principles someone should learn when deciding to go into business selling an uptime monitoring service.
It's not a "ghost domain," it's a Time-To-Live field!
Adding to this I would take it a step further. One should use monitoring probes from many locations that check the authoritative servers directly in the event one is using anycast DNS (hundreds or thousands of DNS servers spread around the world) to increase the likelihood that one catches a cluster out of sync SOA mismatch or a cluster is down or experiencing packet loss. There are services that do this or one could just use in-house monitoring from all their data-centers in each continent and region. Even and especially in the biggest DNS providers anycast clusters can get out of sync for a myriad of reasons which is why the probe should always be for the SOA serial of each zone.
If you disable caching on your recursive resolver, I guess that works...
But I think there is a real issue if caching recursive resolvers don't revalidate delegations. If .com tells you the example.com nameserver is ns1.example.com with some TTL, and ns1.example.com tells you its the nameserver for example.com every time you ask for www.example.com, you should still check in with the .com nameservers ever TTL to validate.
I'm not surprised the default behavior doesn't do that, because when I migrated a high profile domain to new nameservers, we still saw requests to the old servers for more than a month... but it's still ugh, recursive DNS should do better!
The point is that that TTL is appropriate for regular lookups but not necessarily for an uptime monitor which has different requirements and tradeoffs to consider.
I get where you're coming from, but I think the part you're missing is that caching is not optional (per the "with the cache disabled" comment). If you're running a service like theirs, you need to do caching to some degree.
My understanding of their implementation is that it does caching on a per-worker basis with lower TTLs, so it balances caching with accuracy, but doesn't "fix" visibility to the problem either. However, it narrows the window such that their method of monitoring will very likely expose a pulled domain sooner.
Caching is always optional. If you want sophisticated control over caching, or just no caching at all, you can do recursive lookups directly. Some existing DNS libraries can do recursive lookups directly, including libunbound. Ideally you would do caching of TLD nameserver addresses so you're not hammering the root servers for each query. But otherwise I don't think it's necessarily a big deal for a monitoring service to query the .de nameservers every time it checks example.de. If you had a monitor check every 5 minutes for example.de, it's only a 12x load factor between querying .de directly every check versus once per hour. Unless you're AWS Route53, that's not much of a difference relative to the traffic TLD servers handle even if you were checking tens of thousands of domains. Clamping your cache at 1 hour is probably already a much greater load factor. The .de nameservers return a TTL of 1 day for the example.de NS RR sets, so that's already a 24x factor right there. At that point you're clearly giving the .de nameservers the middle finger and relying on your own judgement of what it means to play nice.
As a banner or something, maybe. But I'd much rather see a broken-looking site on mobile than see nothing at all on mobile.
In the same category: websites that display nothing but a splash screen "This site requires Internet Explorer X" or whatever. Don't nanny me, just feed my browser the HTML! Whether my browser can render it properly is my problem, not yours.
In the middle of this too-long-and-rambling piece, there's a sketch of an interesting sequence: look for the text "universal winner." Let a(n) be the size of the smallest "coin-matching player" DFA that eventually matches the output of its n-state opponent no matter the identity of that opponent. a(1) is obviously 2 (right?); Wolfram indicates a(2) <= 10; what is a(3)?
This is different from the problem of identifying the opponent, which obviously requires at least as many states as there are opponents.
The reason I'd want "frozen-size vector" is to replace pairs of data members of the form `T* foos; size_t foos_len;` without paying another 8 bytes to store a useless capacity that's never going to change.
But I don't think that makes such a container worth adding to the STL. So far, it hasn't even been worth writing in our own code. But that's the reason I've thought about writing it.
This is how I designed my vector in C. Note it is still not frozen as you can use realloc just fine (even with good performance) and/or external tracking of the capacity in tight loops.
FWIW, I believe that's not a mistake, just a consistent use of (novel?) jargon. From context I infer that the paragraph is distinguishing between the _hard requirements_ of the traits (quote: "the language contract says they cannot become unsafe") and the behavior human programmers would naturally _expect_ of the traits ("the social contract").
And yes, looking at https://docs.rs/misfortunate/latest/misfortunate/index.html and Ctrl+F'ing for "social contract," I see that usage very consistently. The entire point of Misfortunate is that its types correctly implement the language contract, while violating the "social contract" in various surprising ways. For example, causing a hash collision on every operation is a perfectly cromulent implementation of Hash, but violates the "social contract" of Hash. For another example, look at LoadLetter — throwing an error on every operation is a valid implementation of Read, but still violates the "social contract" of what a human programmer would naturally expect from something readable.
It's unfortunate that the C++ version of the code assumes the type T is default-constructible (and that the default constructor is cheap). It also assumes that the type T is copy-constructible; at a glance I can't tell if the algorithm depends on making a copy in every place that it does make a copy. E.g. in the `heap_sort` helper we have
T k; // default-construct
if (i > 0) k = left[--i]; // copy-assign
This fairly obviously could be replaced with "copy-construct." Could it be replaced with "move-construct"? I don't know.
Again, in `partition_small`, we have
T swbuf[SMALLPART];
which default-constructs a bunch of Ts. I think we're just going to overwrite that memory in a moment anyway, so constructing all those Ts is a waste of cycles; but I'm not sure.
All of my "I don't knows" and "I'm not sures" are due to my own lack of digging into the code; I'm sure one could find out if one really looked.
None of that matters if you're just sorting `int` or the benchmarked `struct entry`. But it matters a great deal if you're taking the README literally and trying to sort "types with higher copy costs [...] (such as strings)".
...Ah, `heap_sort` is used only for trivially copyable types. So my complaint about not distinguishing copy from move is essentially unimportant (matters only in pathological cases that we shouldn't worry about).
But it's perfectly possible for a type to be "trivially copyable" without being "default-constructible." An example of such a type from the STL: `std::reference_wrapper<int>`.
Anyway, looks like a quick fix for this would be to just extend the list of traits on which blqsort is gated (currently `is_trivially_copyable` and `sizeof(T) <= 16`) by adding `is_trivially_default_constructible<T>::value` also.
The Wikipedia article on "meteor air burst" has an explanation that basically matches yours, although they do use the word "explosion" to describe it. Which makes sense to me: whatever one chooses to call it, it's a nearly instantaneous spontaneous disassembly that is very bright, very hot, and very loud.
The speed scale for disassembly is nowhere near the forward speed; you never get anywhere close to 45 degree debris divergence angle. It's also, again, not the disassembly that causes it to be bright, hot and loud. Wikipedians can also be wrong.
The meteors made only of iron alloy and/or silicate rocks do not explode, but they may fragment into many smaller bodies.
The meteors that contain great amounts of volatile substances (water, carbon compounds and sulfur compounds) may explode if the interior becomes hot enough to convert the volatiles into gases. When such a meteor rich in volatiles fragments, some of the fragments may explode, while others may reach the surface of the Earth intact.
Is it something about using Chrome? My wife's Gmail was showing the "Press / to help me write" prompt last week and we couldn't figure out (1) how to turn it off nor (2) why _I_ wasn't seeing any such prompt in _my_ Gmail, despite all our Gmail settings being the same as far as I could tell.
We both use Chrome (she on Windows, me on Mac), but I could totally believe that I've turned off some shiny AI feature _in Chrome_ that she hadn't.
Anyone care to confirm or disprove the hypothesis that there's some setting in Chrome itself that will disable this Gmail feature?
I saw the "Press /" using Thorium (a Chromium fork). Tried to use the element picker in uBlock to get rid of it. This failed, of course, because the thing to be blocked disappears as soon as the text input area loses focus, even after I deleted every event listener that I thought could have been relevant.
In a Firefox fork (Floorp) using another Google account but with the seemingly relevant part of Gmail configuration matching, I don't see "Press /" at all. Not sure why exactly, it's a somewhat interesting question but I already went poking through dev console to write a selector for it and I'm starting to get irritated at the idea of spending any more time on it, lol
Solution (which everyone else does, and OP has now implemented): don't use your ISP's recursive resolver! Run your own instance of bind9 or whatever, with the cache disabled. Or it seems like `dig +trace` would probably work, too.
"Cached resources remain visible for their whole TTL, even if the original becomes unreachable or changes" seems like one of the very first principles someone should learn when deciding to go into business selling an uptime monitoring service.
It's not a "ghost domain," it's a Time-To-Live field!
reply