25 Apr
2024
25 Apr
'24
12:52 a.m.
Please tell me which RFC you are referring to that says you have to have AXFR access to
all servers that host part of a larger network.
I’d like to read up on that one.
73,
Ruben - ON3RVH
On 24 Apr 2024, at 19:46, lleachii(a)aol.com wrote:
Chris,
It seems simple to me and I don't take it as criticism. I'm also in good company
of those past who understood the issue. For me it seems stone-aged for users to wait 3-5
seconds for DNS requests, get no responses, experience failures, have to switch DNS
servers or use AMPRGW to use 1.1.1.1, 8.8.8.8 and 9.9.9.9 (which are 150+ ms on my AMPRNet
connection from MDC, how about the UK, other parts of Europe,etc.?).
It was actually the reason our local EMCOMM sponsor failed to fund us year ago - we had
basic DNS lookup failures/timeouts, had to change DNS servers on computers (as operating
procedure), etc.
I'm sure those anycasted servers [geo]located near UCSD - home of AMPRGW -hence the
roundrtip delays for users using DNS over AMPRNet.
How about the AMPRNet TBD server's location?
Some suggest people use this DNS configuration it like its hyperspeed - it's not for
many people on the Globe. Next - to be honest, there's delays (at least in the past)
for AMPRNet queries making such configurations (I guess we're not that popular and you
don't allow AXFR). That day still occurs for me today when not using or querying your
servers directly - or nefarious caching that data randomly attempting PTR, etc).
* Is there some Wiki that tells users how to setup DNS servers like 1.1.1.1, 8.8.8.8,
and 9.9.9.9 to reach their local anycast destination as you all suggest?
Lastly to note, if your AMPRNet has only IPENCAP connections, some of your suggestions
require users setup their own DNS servers. Perhaps these /16's are not connected via
IPENCAP - if so my apologies. Again PTR would suffice. I likewise regress without
discussion of networks that use low cost metrics to reach a route (e.g. a BGP'ed
network) - it seems unnecessary at this juncture.
Thanks for the considerations and thought of those nonetheless - I never thought about all
the notions of "special consideration", I thought it was clearly understood as
necessary unless the network is unrelated to the ARDC AUP. It's RFC you allow AXFR. It
seems odd the servers are configured to fail - but then I'm accused of seeking
"special consideration" when asking for normal usage.
- KB3VWG
On Wednesday, April 24, 2024 at 01:16:09 PM EDT, Chris via 44net
<44net(a)mailman.ampr.org> wrote:
Hi Lynwood,
As Ruben says - this was the point I was trying to get across in my last email - I am not
criticising you, I am just curious to understand what you are trying to achieve as it does
not make sense to me...
ARDC have setup four authoritative nameservers for ampr.org<http://ampr.org> and all
the (now separate) reverse zones (ok, to be precise not ALL the reverse zones, as I said
before we have a small number of delegated reverse zones - 5 or 6 from memory). Under
normal circumstances NONE of these namservers need to allow AXFR / zone transfers to
anyone, but as a few folks asked nicely I opened up ns.ardc.net<http://ns.ardc.net>
(which is the primary) as a favour, but only to 44.0.0./9 & 44.128.0.0/10 source
IPs.
To reiterate, these authoritative nameservers are:
ns.ardc.net (UK based primary)
a.gw4.uk (UK based secondary)
ns2.us.ardc.net (West coast US secondary)
ns1.de.ardc.net (Germany based secondary)
As these are authoritative nameservers, best practice dictates that they are not also
recursive nameservers.
If you, or anyone else wants to setup a recursive nameserver you are welcome to do so,
no-one is going to stop you, nor do you have to ask anyone’s permission, but also you not
need to get any special access to the zonefiles, as Frederic and others point out, you
don't need to. If someone queries your recursive nameserver it will, by definition,
recurse from the root servers down the tree to find one of the authoritative nameservers
listed above to get the answer, your server will then cache that answer ready for the next
time it is queried.
I hope that makes things clearer, but please, if I am not explaining it sufficiently do
ask. It would also perhaps help me, and others, if you could explain why you want access
to AXFR when it is not needed for a recursive nameserver (this is the non-standard bit I
don’t get).
Thanks & 73,
Chris - G1FEF
—
ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 17:44, Ruben ON3RVH via 44net <44net(a)mailman.ampr.org> wrote:
Lynwood,
A request like normal is just a standard dns request.
If you want to be a open dns server for everyone on the AMPR network just do it. If
someone asks for a ptr which your server does not own or have in it’s cache it’ll just
look it up using the root servers like any normal dns server.
I don’t get why you **need** to have all reverses in your zones. Master or slave.
73,
Ruben - ON3RVH
On 24 Apr 2024, at 18:35, lleachii--- via 44net <44net(a)mailman.ampr.org> wrote:
Frederic,
How does someone "make a request like normal" if their client DNS server is set
to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. -
but others)?
* What is that "normal request" in your paradigm?
* Please explain - maybe I'm missing something?
* What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or
your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used
for AMPRNet according the AUP?
What's being hidden?
73,
- Lynwood
KB3VWG
On Wednesday, April 24, 2024 at 12:26:36 PM EDT, Fredric Moses <fred(a)moses.bz>
wrote:
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different
authoritative name servers in diverse areas and networks. BGP and IPIP included, if
somebody wants a PTR record make a request like normal, but we will not be allowing
transfers of zone files to any server not under our control. You are welcome to make PTR
queries like anybody else but no special zone transfers will be allowed.
--
Fredric Moses - W8FSM - WRPA678
_______________________________________________
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
_______________________________________________
44net mailing list -- 44net@mailman.ampr.org<mailto:44net@mailman.ampr.org>
To unsubscribe send an email to
44net-leave@mailman.ampr.org<mailto:44net-leave@mailman.ampr.org>