> Since we cleaned up 44.130/16 a while ago, we have some hints for your
> first cleanup round. Maybe you should consider taking obsolete CNAME-
> and MX-records into account. Example:
> to-be-deleted.txt:
> g7suh IN A 44.131.254.242
> ampr.org:
> 2e1arm IN CNAME g7suh
Yes, please take good notice of that!
Some time ago I have made a lot of effort to delete all dangling CNAME and MX
records, hundreds of them.
Apparently there have been cleanups where entire subnets worth of A records were
deleted, but many MX and CNAME records still referred to them. It looks like
at some time, for every A record created in certain US subnets, a corresponding
MX record (just "call IN MX 10 call") had been created. A bit pointless, but
worse is that those were not removed when the A records were removed.
This time around, please make sure that whenever some record is removed, all
records that point to it are also removed.
As Jann correctly points out, there are MX records that point to external servers
(although sometimes the trailing period was forgotten, making them inoperative).
During the above cleanup, I found several of those that do not exist in DNS anymore,
and deleted them as well. I did not check if the ones that still resolve would
offer SMTP service and would accept mail to the specific domain name (in .ampr.org!).
Probably lots of them don't.
This weekend I sent out a mailing about renewing registration by tacking @amsat.org
@veron.nl and @vrza.nl to all callsigns (the latter are two amateur societies here)
and of course I got many delivery failures back where the address at the aliasing
service exists, but the address the mail is forwarded to no longer exists.
We are not the only one with this cleanup problem...
Rob
I downloaded the encap.txt file just now and it doesn't match the gateway
list. Is it not being updated or has something gone wrong in the process?
73, Don
> People -- we need the cleanup. I say, be aggressive. If an active DNS
> record gets deleted, just recreate it -- Sheesh.
Maybe you have not understood it, but we are actually *using* the network.
For places where it is just a leftover of the packet radio days, I agree.
Today I deleted a number of old BBS records, and a few hours later I got a
mail back that one that was still in use. We cannot do that for all 3000
active records.
Rob
> No, expectation is that people getting AMPR address space should
> have the subnet they're in registered with the portal. That includes
> non-connected hosts and /32s.
Is it really a good idea to base the cleanup on data in the portal?
I mean, the guy running the portal clearly does not have the resources (or the
motivation?) to do even minor maintenance on it, let alone finish work on features
like the DNS registration that have been in incompleted state for years.
Is it a good idea to make our entire network dependent on that?
I cannot remove a subnet that was erroneously added in the past (and where user
subnets where added inside) without deleting those, and a request to the maintainer
to do that outside the portal UI that I sent months ago is still not processed.
I also cannot add any regional subnets for which parts are already registered to
users. The whole implementation of subnet hierarchy and record ownership is much
too strict, it only works when everything is done "the correct way" on the first try,
which simply is not realistic. Compare it to HamnetDB where you can simply reshuffle
the whole subnetting by inserting, deleting or editing existing records within the
existing hierarchy.
I also don't like the idea to send a request to all users to "register themselves"
and then being bombarded with allocation request mails from the portal that all
need to be manually edited because the requesting user cannot specify an existing
allocation to be registered.
Users that do not understand the whole mechanism cannot be ignored, because either
you don't process the request and it remains on the todo list, or you reject the
request and those users just click the links in the rejection mail which results
in the same request being posted again :-(
In 44.137.0.0/16, really only the users that want to run an IPIP tunnel are registered
in the portal, there are many other users that connect in a different way.
Luckily we are not affected by this cleanup because we are BGP routed, but at the
same time that also shows how this method is failing. After all, what does the
routing method have to do with the DNS contents? Basically nothing. Why should
all our inactive records remain there while those of other countries are deleted
even when they may be active?
When we want to clean the DNS, we should look at the situation on a country by
country base. I am all for deleting entries for callsigns that have expired, and
in fact I regularly do that. Probably other countries also have lists of active
callsigns and a quick scan can be made to delete all expired callsigns and probably
also those records that are not related to callsigns. We could request all coordinators
to send a list of active callsigns, and we could process those lists to generate a
deletion list like I already do for my area.
We could also ask each coordinator what is the state of IP packet or other use of
those addresses in their country, and maybe get whole networks deleted when they
no longer exist.
I will try to dig in the old data I still have saved (for my area) to generate a
list of callsigns and the date of last registration or reconfirmation, and try again
to contact all callsigns with records before a certain date and delete them when
there is no reply.
This should clean out more records than the previous run, where I only deleted those
registrations where the owner replied they no longer required them.
Rob
Hi group,
hello Thomas,
IIRC the initial assignment was in fact given to me by you and Paul, so
I'm happy to hear from you again. :)
On 02/07/16 23:55, Thomas Osterried wrote:
> Hello,
>
> well, a longer tradition than the quite new portal are the country-wide IP-Koordinators.
>
> In DL, we have the coordination team of three people (dd9qp, dg8ngn, dl9sau) and we delegate the responsibility of the local assignments to the regional coordinators. This concept goes back to the last century.
> From the regional coordinator, Wolfgang had got the initial assignment of his IP addresses.
That is correct. And that was kind of "status quo" when I had to quit
Packet Radio activity. But the first thing I found when I searched for
infos on the current state of IP in PR was that my IP's no longer do
exist (which in fact is not really the problem for me, as I really was
not active for a long time. So, no complaints on that from me, that's
perfectly OK if there's some need for IPs.
> Some time ago, we did a clean-up of the old 44.130 packet-radio block in communication with the regional coordinators.
>
> What's with the portal? - I think we need discuss that. It had been no relevance for us (since no one requested it), and I'm not sure, how it fits in a concept of the country coordinator system (unless a country coordinator defines a do-what-you-want-netblock for self-allocation - but how this may be integrated in a working routing concept??).
I think the portal would not work that good with a concept like the
formerly used one with using the IP for granular routing over PR
network. But I seem to remember discussions that the "routing feature"
would not be needed any more and the whole german IP PR network should
be seen as one big block (which I do not really support from my
standpoint as sysadmin).
> Region ofr.de (44.130.62.0/24) was resigned 2013-07-31. Regional Coordinator was DL1NAT.
> The zone file of that region expired with serial 2004041601. Nine years after the last update. forward- and reverse- entries were inconsistent: the reverse file had the serial number 2002062201 (I assume 2 years before).
>
> I do not like to blame anyone, but it may be useful in that discussion. 9 (or 11) years after the last coordination of the subnet and 2.5 years after your regional coordinator stated that all records could be removed, you recognize that dg7nef, dg7nef-2 and dg7nef-gate ( 44.130.62.20, .18, .19) have been passed back.
And that lead to my problem with portal.ampr.org as I still had my own
local acting DNS serving as "Master" for the zone on requests from my
network, so I could at least keep the IP adresses I did contact in a
state that did work for me. Yes, split DNS and multiple masters are an
ugly thing. But it did work locally then.
> This emphasizes both, the difficulties we'll get, even years after a clean-up, and on the other site the need to have a clean-up (the /24 had 57 entries (22%) and we finally got one complain (Wolfgang had 3 addresses -> 5 %). For most cleaned subnets we got 0 responses at all).
Well, in fact no complains from me so far, just a bit confusion on my
side. ;)
> And imho, it also shows the country- / regional-wide coordination concept makes sense. Currently, we've 35866 IN A records in ampr.org. Imagine we'll have 10 requests a day on the list of the pool of every user, we all will have to read the next 10 years about every individual issue.
One kind question,
first of all, after a forced break due to changing my home address and
various other reasons not to be discussed here I had to learn my IP
adresses assigned to me long ago and that I used for a long time ago are
no longer existing. OK, maybe I can understand the reason for that.
Now I'm searching for that "portal" to register myself for getting a new
IP assignment for being able to start playing with Amateur Radio Packet
applications and so on, so I search for the portal. Well, there is a
portal. But that portal is not showing up at all when you try to contact it.
Does that mean you have to have an IP to register for an AmPR IP, but no
wait - I just want to register for it?
Can you please enlighten me what is going on here? I just don't
understand it right now.
Thanks,
Wolfgang
> What would you have me do? It's clear that the majority of the entries in
> the DNS are bogus. We have NOTHING to reference except the portal data.
> Doesn't it make sense to try to get that data in order?
Yes, but as I mentioned many times before, there is no sane way of migrating the
data that *is* still valid towards the portal. There is no clear way for the user
to request their existing allocation to be loaded into the portal. Not automatically
(e.g. by querying the DNS), not manually (by filling in a form with existing addresses).
One can only ask for new allocations and place a comment that says in fact one wants
to move an existing allocation. I cannot ask the users to do that, and I don't
like to edit all those requests manually. I think the portal should facilitate
migration of existing data at least until that process is completed.
There should also be procedures to migrate large blocks of data, as our own network
infrastructure has hundreds of hosts that I do not want to enter in a webform one by
one!
I have recovered all update mail messages sent to the portal after 1994-01-01 and
have added a date stamp to all the lines in my own hosts file with the latest
date of an addition of data for each callsign.
The file is available at http://pe1chl.nl.eu.org/hosts/hosts.137
Today I have done another mailing and a local amateur radio newssite has placed
it on their newspage. This time I requested all the users that want to *keep* their
allocation to reply by mail.
When I get a reply or make a new registration I update the stamp to the current date.
Next month I will just delete all records with a date before 2010.
That should get rid of all the records from "the old days" and only leave those that
were added during our more recent experiments. Last time I did this (two years ago)
I kept the records for those that I could not reach, but this time those will get
deleted. (of course they can always request to get them back when they notice it)
Rob
Brian Kantor wrote:
>That was going to be a subsequent phase of the project. At the moment,
>there is no way to "mark" the data at all - it either exists or it
>doesn't. What we were considering doing is importing the DNS entries
>into the portal, then requiring that each be claimed by someone within
>some period of time - perhaps a year or two. After that, unclaimed entries
>would be deleted.
Sounds logical, that seemed to work well with the gateways portal phase in.
I really can't think of any other approach. So delete as much for sure dead
wood as possible; import what remains to allow it to be claimed. And then
finally purge all unclaimed
>
>The existing DNS entries have an ownership field, based on who entered
>them into the DNS database. That was added a few years ago, so there
>are a lot of entries with null ownership. Unfortunately, there are
>older entries which are still valid but have null ownership because
>they were added to the database before it had an ownership attribute.
I was wondering about this. Thanks for explanation.
>This brings up the question of who is to be the owner of a DNS entry.
>Should it be the individual or group who asked for it to be added to
>the DNS or should it be the coordinator who entered it? The former
>would mean that hundreds of people would have to register with the
>portal and take ownership of each of their entries. The latter would
>mean that it would be up to the coordinators to keep track of who is
>still active (or still alive!) and delete entries for people who are
>no longer around. Neither is a satisfactory solution.
>
In my opinion the end user should be the owner. But it might be logical
to have a group owner ship flag available too. So people like coordinators
can enter and edit for other people who may be less in the know in
terms of what they are doing.
>The goal is to have a tidy DNS database, with only entries that are
>valid as is possible. I am open to suggestions.
>- Brian
> My speicific issue here is that my local AMPR coordinator recently told me that unless all my IP addresses had a DNS entry, I risked loosing my allocations. I think this is a policy that *he* is setting himself (not a global AMPR policy) and
> though I don't agree with his view, I obliged to give him ~1024 hostnames to fill things out. If other AMPR coordinators have similar approaches, then DNS entries mean everything to the IP allocation be it a subnet or a /32.
>
> --David
> KI6ZHD
This is not how I handle allocations... in the area I manage one can allocate individual addresses or subnets, and when
they are subnets the address range of the subnet is reserved but not each address in the subnet needs to have a name attached.
However, all traffic for addresses without associated name in .ampr.org is filtered at our internet gateway. So when you want
to actually *use* an address outside the local radio network, it has to have a name.
(this is the same policy as in the gateway at UCSD)
Rob
> Subject:
> Re: [44net] DNS cleanup
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 02/07/2016 08:52 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Sun, Feb 07, 2016 at 08:37:23PM +0100, Rob Janssen wrote:
>> >I wonder what the database structure is and if you could maybe just delete the
>> >record from the database without affecting the children.
> I can't; I don't really have access to the underlying database.
> - Brian
That is why I initally sent the request via the contact page on the portal. However, it was not
processed. This makes me pessimistic about the maintenance resources at the portal, and
reluctant to spend a lot of time filling it with information that apparently can never be modified.
Rob
