Chris,
Regarding offering dns-mdc for use - and to understand client DNS server settings for hosts on AMPRNet: It seems you are being slightly circular in your reasoning. I've had to trouble you to ask about 44.5/16 and 44.15/16 a few times - and it's concerning. As you stated to me off-reflector - this is Public Information (as you had me seek it), and there's no need to hide. Also, many have volunteered to assist. To be clear, you've written:
Not sure what the need is for recursive nameservers when there are some really fast public ones available like 1.1.1.1, 8.8.8.8, 9.9.9.9 etc - they all use anycast to get you to the closest point.
---
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:That makes sense, the gateway server at UCSD is no longer running a DNS server.We have four authoritative nameservers now:ns.ardc.neta.gw4.ukns1.de.ardc.netns2.us.ardc.netNone of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. --- Also, if you are providing a recursive nameserver, why do you need to do zone transfers from ampr.org and the 44 reverse zones?
Today, your use case ignores normal users - where on April 20th you agreed:
- A user sets up AMPRNet
- A user sets up a client, IP, DNS (ns.ardc.net or gw.ampr.org and secondary DNS servers in the past- As you keep inferring should be done) - Users goes to XXyXXX.ampr.org - works - some PTR records work (...odd - because you are only "authoritative for ampr.org and [some of] the 44 reverse zones) - Wait....other domains and PTRs don't work...this sux =[ - Others have been telling you these issues, you seem to be ignoring them
Today's 24APR suggestion fails to identify this common problem and provides a fix - it also forgets your 20APR remarks acknowledging the issue - and that you volunteered to stand up a server somewhere to also solve that issue in one region (which is why I asked about latency to ns.ardc.net). To that end solution, I ask:
- 5.44.in-addr.arpa. - (Sweeden?) may I access your PTR records? - 15.44.in-addr.arpa. -(W8CMN?) may I access your PTR records? - 25.44.in-addr.arpa. - thank you HamWan for access
Your last comments regarding providing dns-mdc for users forgets your 20APR comments and incorrectly assumes this data traverses the Public Internet - and NOT primarily AMPRNet (hence reducing AMPRGW's need to handle traffic to Internet DNS servers), direct connections, etc. (recall, 44.0.0.1 previously had issues and was not recursive anyway). It's difficult to discuss when you're ignoring the simple day-to-day usage case of "a Client DNS Server IP(s) the user enters into the host for connectivity on AMPRNet". Since AMPRNet has never provided such a server, your understanding and changes on the use case confuses me - and I must ask for clarification.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 11:22:27 AM EDT, Chris chris@ardc.net wrote:
No, they are not recursive, but they are authoritative for ampr.org and the 44 reverse zones. Not sure what the need is for recursive nameservers when there are some really fast public ones available like 1.1.1.1, 8.8.8.8, 9.9.9.9 etc - they all use anycast to get you to the closest point. Also, if you are providing a recursive nameserver, why do you need to do zone transfers from ampr.org and the 44 reverse zones? Your nameservers will automatically lookup (using recursion from the root) any requests it receives and will cache the result for the duration of the record’s TTL. Just curious as you seem to be using DNS in a rather non-standard manner :-) 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 15:44, lleachii@aol.com wrote: Chris,
Those DNS servers aren't (and never have been) recursive - you noted that yourself. Most don't even AXFR according to RFC.
Users for years look for DNS servers, enter them into their clients - then wonder why they don't work, have failures for other domains, etc. Years ago, those on the Wiki agreed to maintain recursive/client DNS servers. I volunteered for EMCOMM, HSMM in the Atlantic/MDC area anyway - and because DNS latency for lookups to California and back were insane. Hence I asked you where ns.ardc.net was located due to the high ping. Also it is available to access for various International/NGO/government ENCOMM situations.
Since the late Brian Rodgers, SK passed away in Connecticut, I believe I'm one of the few on this [immediate] side of the pond. I hope this clarifies the mission of dns-mdc.ampr.org - I've been running the server about 10 years now.
Also, I added HAMWAN.ORG to the server.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 09:55:31 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
FYI, there is already an east coast US authoritative DNS server: ns2.us.ardc.net There is also one in Germany: ns1.de.ardc.net and one in the UK: a.gw4.uk 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 14:09, lleachii--- via 44net 44net@mailman.ampr.org wrote: To Operators/Clubs/Coordinators/Trustees/National Amateur Societies/etc. with delegated AMPRNet /16 Subnets:
Greetings. Time has passed - I've needed to urgently communicate with you. I awaited clarity and verification regarding DNS from the New ARDC regime and Administrator (B.Kantor, SK was the last ARDC Admin I worked with before Chris - that was before 44/8 was subdivided). If you do not do so at this time:
- Please allow AXFR for AMPRNet SRC IPs for your x.44.in-addr.arpa Master DNS from 44.0.0.0/9 and 44.128.0.0/10 - If you cannot do so, in the coming days/weeks, I will directly locate you/your server operator and request access for 44.60.44.3 to AXFR via any means of WHOIS/contact in DNS responses/IP's via RIR/ARIN or AMPRPortal/etc. - I can also coordinate with you to use a.) an IPv6 SRC address, b.) my IPENCAP tunnel using other DST addressing, or c.) a Wireguard tunnel instead Those who already allow AXFR per RFC at this time, my sincere appreciation and thanks. I would like to ensure I have a East Coast US DNS copy of the ALL 44.0/9 and 44.128/10 network PTR Records.
Thanks and 73,
Lynwood - KB3VWGMaintainer of 44.60.44.3 (dns-mdc.ampr.org)
On Tuesday, April 23, 2024 at 05:25:51 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
All,
44.60.44.3 is now up-to-date and as always, available as a recursive (client) DNS server that can be configured in AMPRNet hosts/clients.
user@dns-mdc:~$ ls /var/lib/bind -l-rw-r--r-- 1 bind bind 281 Apr 23 20:34 0.44.rev-rw-r--r-- 1 bind bind 227 Apr 23 19:30 128.44.rev-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 44.rev.old-rw-r--r-- 1 bind bind 14187 Apr 23 19:33 68.44.rev-rw-r--r-- 1 bind bind 2584957 Apr 23 20:50 ampr.org.hosts-rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 ampr.org.hosts.old
73,
LynwoodKB3VWG
On Tuesday, April 23, 2024 at 03:42:38 PM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Chris,
I wanted to thank you for your support and patience.
It ended up being firewall rule (that never affected the old 44.0.0.1 master configuration) - that prevented my server from initiating traffic bound for AMPRNet. I also wanted to publicly apologize. I'll email you off-reflector with more details.
Public Kudos to you!!
- LynwoodKB3VWG
On Tuesday, April 23, 2024 at 09:06:32 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood, Yes, I am the right person, I will email you off list so we can discuss. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 23 Apr 2024, at 13:17, lleachii@aol.com wrote: Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS? I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
- Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided - Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old. If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
--- 73,
- LynwoodKB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
- 0.44.in-addr.arpa - 68.44.in-addr.arpa - 128.44.in-addr.arpa
B.) Testing the command 'dig AXFR ampr.org @44.1.1.44'
- Works from SRC IP 44.60.44.128 - DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd: user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data.From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms D.) I noticed the high ping, is this server at UCSD or elsewhere? E.) I've updated my NTP configuration as well.
--- - Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net as your time source. All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote: I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well. If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1. --- Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed