But it still focuses on one specific viewpoint and tries to ridicule other people's solutions and/or requirements. I think that is not the way we should interact. Especially not on a medium where not everyone has the same first language and thus some are at a disadvantage explaining or understanding the matter. We should approach each others messages in a neutral way, not all the time try to convince others that they are doing the wrong thing, and deny other people's requests and requirements.
E.g. in this matter I can (try to) explain that we also run our own DNS server with the 44-net zones on it. Until recently these were downloaded from the gw.ampr.org FTP server, but when that was removed we now use zone transfers.
Why? Why not "just query 8.8.8.8 and they will send the query to our servers"? Well, at least here (and even more so in other European regions and also elsewhere) the AMPRnet is not just a way to announce a large subnet on internet. We actually do have a radio network. We can reach other hams via radio, not via the internet. And some people like the idea that this network is functioning independently from the internet, e.g. to facilitate emergency communications. But also "because we can".
So, we have to provide our own DNS service, not rely on the internet, at least for the names and addresses that would be part of our network when it gets isolated. That is why we run a set of DNS servers (on an anycast address) that both serve net44 addresses and function as a recursive resolver for others. I have changed my scripts that used the FTP download into using zone transfers, and for our region it is reasonably complete. I don't care that much when we cannot transfer zones from a network in Michigan, because that probably will never be reachable for us when we have no internet. But other networks in Europe are in the server and are reachable without internet connectivity.
And I am no longer going to defend it. It is just the situation. When other people do not see the need, fine for them. We do see the need, so we do it. But I get really tired of those that always ridicule such things and/or are rejecting requests just because they themselves do not see the utility.
Rob
On 2024-04-24 21:01, Ruben ON3RVH via 44net wrote:
That indeed sums it up quite good. Thanks Dan! And indeed the question is if Lynwood's server is also on a slow connection or not.
73, Ruben - ON3RVH
On 24 Apr 2024, at 20:47, Dan Cross via 44net 44net@mailman.ampr.org wrote:
On Wed, Apr 24, 2024 at 1:54 PM Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
Oh boy do I hate these discussions.... All those people that see only their own world, cannot understand why their use case is different from that of others, immediately remark that others should do things differently (in the way they think is reasonable), and never even trying to understand the viewpoint and requirements of others.
It is a pity that what could be a nice project and a nice cooperation between technically interested people is so destroyed by this.
I don't know that it's quite that bad.
What I understand the use case to be is that:
- KB3VWG has a recursive DNS server sitting on a very slow speed link
(perhaps on an RF island). 2. He wants to be able to look up arbitrary AMPRnet host names, but the latency due to the RF island makes doing this in the standard recursive fashion difficult. Hence, 3. The desire to cache the entire `ampr.org` zone and reverse RRs, presumably by transferring them to said DNS server periodically via an AXFR. At least, that's my reading between the lines; it's admittedly not super clear whether the DNS server is on a slow link, or clients are on a slow link. I could see either as being a legitimate use case.
I think what G1FEF and ON3RVH are saying is that nothing precludes one from setting up a recursive DNS server that handles queries to the root for arbitrary AMPRNet DNS RRs oneself, and then configuring clients to connect to that. In that case, a client making a request from a slow RF island is still only making one request: to the recursive DNS server that will handle resolution from there, and eventually return the results to the slow client. But that's predicated on the recursive DNS server not being on a super-slow link.
Or maybe the request is to provision "official" recursive DNS servers in various places inside of AMPRnet to avoid having to traverse the public Internet to handle lookups. On the face of it, it's not an unreasonable request, but someone would have to coordinate it and provision the resources, etc.
Many DNS servers of various kinds support the concept of "forwarding" a query for specific zones to specific server (or set of servers); sort of an alternate root, if you will. For example, Unbound can do this via it's "Forward Zone" options: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#forwa... BIND has similar functionality when configured as a recursive resolver: https://bind9.readthedocs.io/en/latest/chapter3.html#resolver-caching-name-s... (see, section 3.3.3, "Forwarding Resolver Configuration"). With something like that, a recursive caching resolver on a slow island can forward to a nearby authoritative server without having to contact the root, and without any traffic leaving AMPRNet, and without having to use zone transfers to "seed" the local cache (which does seem fraught, as described).
- Dan C. (KZ2X)
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org