Re: [44net] hu.ampr.org DNS

Hello, That’s partly true. Yes, the changes in the DNS set are quite fast visible. We have two hosts which are good connected to the internet and are part of the internet. Thus we started the delegation concept as a test, and it works well. That delegation works with forward-resolving (i.e. db0xxx.subregion.de.ampr.org). For backward-resolving, the PTR requests should have also to be delegated. We don’t do that (see below, complete state at ucsd.edu). Since I’ve seen so many projects in the years that startet with good ideas and sooner or later, they lingered around and the person who was responsible was not reachable anymore. Ok, we in germany have built up a team and do our job for long years now. Nevertheless, imagine if you have one DNS server, the server goes down, nobody has a copy - then your complete pr/hamnet resolving is offline until you get fixed it. Here comes our (heavy!) scripting into play. In germany we had, since the old packet-radio time, a concept, where our regions have the absolute control over their subnet (subregion.de.ampr.org). We have a few masters (called Hub West, South, East, ..) which get notifications (-> zone transfer) from the regions nearby; they notified each other, and on one of these systems our script checks for the changes for ucsd.edu. [xxx.]<callsign>.<region>.de.ampr.org is mapped to [xxx.]callsign.ampr.org. This concept was also transferred for our asXXX.de.ampr.org notation for the HAMNET. The script does many consistency checks. DNS entries have to contain callsigns. We disallow things like pmr.ampr.org, pn.ampr.org, yogi-gate.ampr.org, etc..). If a forward-resolving for a [xxx.]call.ampr.org entry exists in the ucsd.edu database AND [xxx.]call.<region>.de.ampr.org has disappeared, and delete it. If a new entry appears, then add it (but only if it is consistent, that means, [xxx.]call does not exist (that means: does not point to another address). => Every call points to _one_ IN A address. And every PTR backpoints to exactly one forward-address (=> no flapping names on traceroute). The PTR points back to [xxx.]callsign.ampr.org. Looking at the hamnetdb project: it made things easier for the SysOPs. They plan and document their network, and the result is a complete dns-set for the region. It’s exported to one of our three DNS hubs (or a regional DNS server) and is almost suddenly visible (=> resolving of [xxx.]<callsign>.<region>.de.ampr.org - from both, hamnet AND the internet). [One limitation: if a region has decided to have a NS delegation to ns.db0xxx.subregion.de.ampr.org, and this host is HAMNET-only, then from the internet that addresses could not be resolved]. On another DNS hub, where our script runs, we regulary (on a daily basis) look for changes and do the mapping to [xxx.]<callsign>.ampr.orgpr.org. Imagine if our team would break (we sit in the same train on accident, earthquake, etc). Then ucsd.edu still knows everything about our network in germany, and changes could still be made manually to the amprdns-bot. About CNAME and MX records: we submit manually to ucsd.edu after request. vy 73, - Thomas dl9sau > Maybe > the use of hamnetdb.net is the reason why Germany and others use own DNS > servers. > > -- > Varga Norbert > http://www.nonoo.hu/ >