25 Apr
2024
25 Apr
'24
3:22 a.m.
We’re not ridiculing anyone or any point of view.
We’re trying to understand the motivation/reasoning behind it all while saying that there
are other ways to get the info he needs to his userbase.
Some are reluctant in allowing “anyone” to AXFR a zone to a server that they do not
control or have access to and from an OPSEC point of view I completely understand that.
73,
Ruben - ON3RVH
On 24 Apr 2024, at 21:22, Rob PE1CHL via 44net
<44net(a)mailman.ampr.org> wrote:
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
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
On 24 Apr
2024, at 20:47, Dan Cross via 44net <44net(a)mailman.ampr.org> wrote:
On Wed, Apr 24, 2024 at 1:54 PM Rob PE1CHL via 44net
<44net(a)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:
1. 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#forw…
BIND has similar functionality when configured as a recursive
resolver:
https://bind9.readthedocs.io/en/latest/chapter3.html#resolver-caching-name-…
(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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org