They're both good. The localroot service offered at B-Root does authenticated transfers (TSIG protected) and gives you update notifications to ensure you're notified as soon as the root changes. Otherwise you may be an hour behind or so (at worst).
Both methods are fine. It would be best if unbound does ZONEMD checking to ensure the file you receive is properly protected from modification from any network in the middle, and I don't remember without looking what version (and if) Unbound does this. If they don't yet, it's coming soon. With the LocalRoot service at ISI, the TSIG protection gives you this (and is older than the ZONEMD record that is now available in the root zone).
This. I've been making a game in Godot with zero AI help. Because I enjoy it. I enjoy solving with weird coding problems you run into. I enjoy leaning as I fixed things. I do it out of love for the process, knowing competition right now from things like this means a flooded market. But I'm ok with that and must be because the other option is to quit.
I think this could go on for pages and pages more, and we can't get the entire industry to agree on the importance of any particular bullet point yet. I'd love to sit down face-to-face sometime and debate this endlessly, but I've done that with a lot of people on all sides already and there is no easy answer that any conversation has come to. It is never as easy as one side of the argument ever wants it to be.
> If I need some namespace for my open source project, I can go and register a top level domain
One common question here is: if you have an open source project, why do you need a TLD? Why is that special? the TLDs are designed into the DNS space and exceptions aren't cheap. Registering a domain under .org, or .horses is cheap compared to the $185k. And using something under .alt is free. Justifying the need for a TLD is difficult when there are other options.
>> The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD?
> Because they want to be supported by existing software.
That's exactly the point I was making: the goal is to get the cheap way out trying to register part of an existing landscape rather than inventing a new universe. If the new universe is that much better, then everyone will want to deploy it anyway. As the web browser market will tell you, their applications (the only ones that most people care about these days [not me, mind you]) update ever 3 months. Getting them on board with a new universe should be trivial! In fact some browsers already support alternate spaces. Green-slate designs are often much cleaner and better when people aren't trying to do a mix of revolutionary and evolutionary approaches.
> This doesn't help much to prevent collisions though, does it?
It helps alternate name spaces not collide with the DNS. Without a registration system, it doesn't help alternate names spaces from colliding with each other (see .wallet for an example of this happening at the TLD space). There was a very large, um, "discussion" about whether or not there should be a registration system for alternate spaces when many of the alternate spaces were being specifically designed because they hated registration systems in the first place. EG, putting a centralized registration on top of decentralized architectures seems, um, weird at best. Supposedly the GNU naming system is creating a registration system that is optional to use. I don't know details about it and whether it's up and running yet.
The real value (entirely IMHO) with .alt as a separation is that it allows people to figure out when they're communicate about why person A can't access the resources that person B has referred them to, is that when it ends in .alt it points toward "oh, I need to look somewhere else than the DNS" vs when it's under a TLD you'd have to know which are alternate spaces and which are not (for each person too -- see the gnu DNS also).
>> DNS stub and recursive resolvers do not need to look them up in the DNS context.
> Now some DNS stub resolver implementers or administrators will read this and reject any queries under .alt
So.... let's say they don't reject them and you send a alternate name space query to a resolver that doesn't understand that alternate name space? You're still going to end up with a failed lookup, and thus just leaking alternate space queries to the DNS that can never resolve. This will look just like a rejection, but with a longer delay.
Alternate name spaces need alternate resolution mechanisms (by design), so software that wants to support both will need to figure out where that split point is so they can switch from one resolution system to another when needed.
The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD? If you want to truly revolutionize naming, then do something revolutionary and discard the current letters/numbers/etc separated by dots and create something entirely new and stop trying to look like the existing system. But that's an even harder problem because it also requires rewriting a lot of UI code. So most intentionally want to conflict with the DNS because it "helps them", theoretically, get more market space by hopefully believing that applications will suddenly be able to use an alternate naming space -- all without the user knowing they're in one?
Minor note: authoritative servers don't have caches. I think you meant recursive resolver (or better "caching resolver" which covers other types of resolvers that may also be caching, such as some stub-resolvers).
You may wish to read [RFC9476], which provides a solution for anchoring alternate name spaces in a way that provides both a signalling point for establishing that you've left the DNS and a way to prevent collisions with the DNS itself.
You may wish to additionally read the history of the Root Server System, which was written by the Root Server Operators and provides significant more context and facts about it's development:
> I don't know the author's background, but I really hate that otherwise normal people have been reduced to such measures.
So, sorry if you read that as a complaint. But it was a feeling for how I think the world is reacting now. Not that it's necessarily bad -- as I think that after returning to normal levels of travel and in-person conversations, it's very clear to me that there was no good virtual alternative hallway conversations. That being said, it also feels like many meetings could be held virtually when there wasn't much need of true in-person interactions. However, to put one case in point: I had a fantastic trip to IETF-115 and much of that was likely because I was on-site. I'm glad I went.
It's actually a "CASEMATIX Portable Credit Card Reader Case Compatible with Square Contactless and Chip Reader, Case Only", which was the best possibility I could find. It would be nice if someone would make a dedicated case for the aranet4 as it is fairly sensitive. I'm fairly happy with this cheap case, but I'd like something that was better fit and designed for air intake, eg.
note that probably after hackernews caught the page (before all the data was in) I added a link by Boeing about this and what their belief is about CO2 levels at takeoff and in flight.
Both methods are fine. It would be best if unbound does ZONEMD checking to ensure the file you receive is properly protected from modification from any network in the middle, and I don't remember without looking what version (and if) Unbound does this. If they don't yet, it's coming soon. With the LocalRoot service at ISI, the TSIG protection gives you this (and is older than the ZONEMD record that is now available in the root zone).