It's because the RFC is fairly short but DNS as a live system is very very complicated. Plus not everything is BIND anyway and you'll find weird things even from large providers.
I wrote https://github.com/jmhertlein/comfydns from scratch, just using the RFCs, and what I got when I was "done" was something that mostly worked. Like surprisingly well. But then I just kept finding a small trickle of issues for certain sites.
One that got me was console.aws.amazon.com. It has 4 CNAMEs in the resolution path and (iirc) one weird but was somewhere along there, you get an NXDOMAIN response but still get a CNAME record back. Is thus allowed by the rfc? IMO, no. I was discarding anything that came back with NXDOMAIN (really, NAME_ERROR - Nxdomain is bind parlance). But alas, it's AWS, and 8.8.8.8 resolves it fine, so what am I to do?
So I added a heuristic thats similarly not-incorrect per the RFC where if I get a NAME_ERROR back, as long as the message has records that match my SNAME, I still treat it as a successful query, cache the records, and continue my search.
So... yeah. Lots of weird shit like that. Just mixes of being too defensive in what you accept and then in some cases not defensive enough - I've found searches that resolve for 8.8.8.8 but if I comb through it manually in DIG, I get back results that are clearly a misconfiguration and then I have to come up with some heuristic that rejects them while still being universally applicable.
So yeah. Fun times. I love DNS. (not sarcasm! I promise).
I'm not sure what exactly you mean - they're different lines of drives. And different SKUs on Amazon. The probability of me getting sibling drives out of that - and that's assuming the only difference between red pros and golds are binning - is infinitesimally small.
My favorite trick for this lately has been to use a stripe of mirrored pairs, where each pair is a WD Gold and a WD Red Pro (of matching size).
They're very similar drives (AFAICT, WD Gold is just a Red Pro but with a higher lifetime r/w rating) but it makes me feel a bit better that they're not from too similar of batches without having to actually temporally space out my purchases. I can buy 1 of each in the same cart.
And then for truly unrecoverable data, I back it up to S3 Deep Archive which seems to be one of AWS's only reasonably priced offerings. Don't ask me how much it's cost in egress bandwidth to pull it all back though. I'm hoping if I end up needing it I'll be grateful enough for my foresight to justify paying it.
You can't be fired from Linux, and if you contribute to the codebase, you do own it under the terms of the GPLv2. (Idk if Linux does copyright assignment but even if they do, it's still GPL).
Whereas a company can tell you to fuck off for literally no reason, give you nothing, and shove you out onto the street with no healthcare and no salary, and then sue you if you if you try to do anything about it.
It's the picture that says "TRACE google.com A IN" at the top.
ComfyDNS is partly scratching a personal itch - I was tired of hand modifying bind9 zone files. And also I was curious as to how DNS works - I knew surface level stuff but no details. So I implemented the RFC from "scratch" (I used netty but no DNS libs). It was a lot of fun.
(Also if/when the site goes down from hugging, forgive me, it is a rails app running on the oracle cloud free tier lol)
I wrote https://github.com/jmhertlein/comfydns from scratch, just using the RFCs, and what I got when I was "done" was something that mostly worked. Like surprisingly well. But then I just kept finding a small trickle of issues for certain sites.
One that got me was console.aws.amazon.com. It has 4 CNAMEs in the resolution path and (iirc) one weird but was somewhere along there, you get an NXDOMAIN response but still get a CNAME record back. Is thus allowed by the rfc? IMO, no. I was discarding anything that came back with NXDOMAIN (really, NAME_ERROR - Nxdomain is bind parlance). But alas, it's AWS, and 8.8.8.8 resolves it fine, so what am I to do?
So I added a heuristic thats similarly not-incorrect per the RFC where if I get a NAME_ERROR back, as long as the message has records that match my SNAME, I still treat it as a successful query, cache the records, and continue my search.
So... yeah. Lots of weird shit like that. Just mixes of being too defensive in what you accept and then in some cases not defensive enough - I've found searches that resolve for 8.8.8.8 but if I comb through it manually in DIG, I get back results that are clearly a misconfiguration and then I have to come up with some heuristic that rejects them while still being universally applicable.
So yeah. Fun times. I love DNS. (not sarcasm! I promise).