Subject: Re: [44net] Bad MX records in the ampr.org DNS From: Brian Kantor Brian@UCSD.Edu Date: 06/02/2015 04:08 AM
To: AMPRNet working group 44net@hamradio.ucsd.edu
There are seven AMPR.ORG and 44.in-addr DNS servers located around the world. The chance that all of them will be down at once is close to zero. We allow people to AXFR their content so it is perfectly possible to have a redundant DNS server on your local net which can answer queries regarding those zones even if you are partitioned from the Internet somehow.
Indeed... I don't see a reason to have a private nameserver for a subdomain either. The ampr.org nameserver works well, it allows updates, maybe the only thing that could be nice is the ability to set TXT and other records. Having a subdomain just makes things more complex.
The only reason I did a replication of the zone is that a local amateur who is running a newscast was telling the world that one of the advantages of AMPRnet/HAMNET is that it would continue to work when Internet was down. I explained him that it is not that straightforward as we depend on Internet services, most notably DNS.
I thought a bit and decided to load the ampr.org zone in a nameserver on our gateway that already is working as a caching resolver for our 44.137.0.0/16 subnet. I think now it will resolve ampr.org names even without a connection (although I have not fully tested that yet). Of course only those names that are in the ampr.org zone, not those that are below a subdomain served by some other server. But we cannot cache the entire world's DNS, and only the ampr.org zone should be sufficient to connect most wellknown systems.
I did not use AXFR, I download the zone from ftp://hamradio.ucsd.edu/pub/ampr.tar.gz Both methods have their advantages/disadvantages, I think.
Rob
On Tue, Jun 2, 2015 at 12:16 PM, Rob Janssen pe1chl@amsat.org wrote:
Indeed... I don't see a reason to have a private nameserver for a subdomain either. The ampr.org nameserver works well, it allows updates, maybe the only thing that could be nice is the ability to set TXT and other records. Having a subdomain just makes things more complex.
I'm not sure if this is how everyone does it, but we (HamWAN) had to make DNS changes via our regional coordinator. We would construct an email in AMPR DNS robot format and send it to him, then he would forward it to the robot. This added quite a bit of latency (half day plus) to our updates and quite a workload for our regional coordinator (our network is growing fast).
Now we use our own domain for forward records and have reverse delegation to our nameservers . When we deploy new systems, they get documented in our portal and DNS records are created automatically in a SQL-backed zonefile. This is near instant and requires no human intervention beyond the original portal entry. This works a lot better for us and will scale as our network grows.
Tom KD7LXL
Rob (et al);
On Tue, 2015-06-02 at 21:16 +0200, Rob Janssen wrote:
I did not use AXFR, I download the zone from ftp://hamradio.ucsd.edu/pub/ampr.tar.gz Both methods have their advantages/disadvantages, I think.
That's what I do here and for the same reasonings. For EastNet it's working quite efficiently and if for whatever reason UCSD is not reachable or one of the secondary servers fails when queried (some of our nodes are still 1200 baud so speed is of the essence) this insures resolution still works.
-
Brian -
Rob Janssen -
Tom Hayward