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@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@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 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 (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@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@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@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@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

_______________________________________________
44net mailing list -- 44net@mailman.ampr.org
To unsubscribe send an email to 44net-leave@mailman.ampr.org