With the kind cooperation of Neil Johnson, I've identified nearly 15000 entries in the AMPR.ORG DNS that I feel can go away.
What was done was to create a list of valid subnets of network 44 by combining the encap list, the list of BGP-advertised subnets, and extracting all the connected or end-user subnets listed in the portal. We then made a list of all the DNS entries that no longer fall into any of those subnets. This is nearly half the "A" records in the DNS.
That list is available for review by anonymous FTP from hamradio.ucsd.edu. The file is called "to-be-deleted.txt". I encourage everyone who has a DNS entry to fetch a copy of the file and make sure that we haven't accidently included any entries that need to remain in the DNS. Please let me know of any such entries and I can remove them from the list.
Assuming our scheme worked, around the beginning of next month, March, I will process the list and remove those entries from the DNS. We still have a long ways to go but this will help.
Thank you. - Brian
2e1avx 2e1axi M6flt M6oaf M6sej
Can be removed
Freshly added request for my new call sign m0jfp.
Looking forward to getting back on the ampr net
Thanks
Best 73
James
Sent from my iPhone
On 6 Feb 2016, at 18:31, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ With the kind cooperation of Neil Johnson, I've identified nearly 15000 entries in the AMPR.ORG DNS that I feel can go away.
What was done was to create a list of valid subnets of network 44 by combining the encap list, the list of BGP-advertised subnets, and extracting all the connected or end-user subnets listed in the portal. We then made a list of all the DNS entries that no longer fall into any of those subnets. This is nearly half the "A" records in the DNS.
That list is available for review by anonymous FTP from hamradio.ucsd.edu. The file is called "to-be-deleted.txt". I encourage everyone who has a DNS entry to fetch a copy of the file and make sure that we haven't accidently included any entries that need to remain in the DNS. Please let me know of any such entries and I can remove them from the list.
Assuming our scheme worked, around the beginning of next month, March, I will process the list and remove those entries from the DNS. We still have a long ways to go but this will help.
Thank you.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hello Brian,
I looked over this list and recognized several IPs of local HAMs (including my IPs in the 44.4 class-B). Many of these entries are /32s and though they might not be actively routing their traffic to the Internet-enabled AMPR network today, it doesn't mean they won't be in the future. Is it the expectation with this move that if people request AMPR address space, they *must* have them pointing to a gateway that's operational *and* their IPs are pingable by some date? In my specific case, I have my address space active on RF but the local 44.4.10.1 gateway has been down for some time.
--David KI6ZHD
On 02/06/2016 10:31 AM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ With the kind cooperation of Neil Johnson, I've identified nearly 15000 entries in the AMPR.ORG DNS that I feel can go away.
What was done was to create a list of valid subnets of network 44 by combining the encap list, the list of BGP-advertised subnets, and extracting all the connected or end-user subnets listed in the portal. We then made a list of all the DNS entries that no longer fall into any of those subnets. This is nearly half the "A" records in the DNS.
That list is available for review by anonymous FTP from hamradio.ucsd.edu. The file is called "to-be-deleted.txt". I encourage everyone who has a DNS entry to fetch a copy of the file and make sure that we haven't accidently included any entries that need to remain in the DNS. Please let me know of any such entries and I can remove them from the list.
Assuming our scheme worked, around the beginning of next month, March, I will process the list and remove those entries from the DNS. We still have a long ways to go but this will help.
Thank you.
- Brian
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.
What we did was to extract from the portal all the allocations which were listed as an end-user or which had one of the three connection types checked, or which were in a subnet from the encap list, or which were in one of the BGP-routed subnets.
Do those you spotted fit any of those criteria?
If they do, we have a bug in our process and we'll have to fix it. Please let me know. - Brian
On Sat, Feb 06, 2016 at 11:36:55AM -0800, David Ranch wrote:
I looked over this list and recognized several IPs of local HAMs (including my IPs in the 44.4 class-B). Many of these entries are /32s and though they might not be actively routing their traffic to the Internet-enabled AMPR network today, it doesn't mean they won't be in the future. Is it the expectation with this move that if people request AMPR address space, they *must* have them pointing to a gateway that's operational *and* their IPs are pingable by some date? In my specific case, I have my address space active on RF but the local 44.4.10.1 gateway has been down for some time.
--David KI6ZHD
Hey Brian,
So I logged into the portal and I see:
--------------------------------------------------------------------- Network Type Description Actions 44.4.10.40/32 user KI6ZHD Edit | Release 44.4.128.0/22 user KJ6VU Edit | Release
Pending Requests
You have no pending requests. ---------------------------------------------------------------------
The top entry is seemingly incomplete as I've been previously granted and DNS resolution confirms I have (had?):
$ host 44.4.10.39 39.10.4.44.in-addr.arpa domain name pointer ki6zhd-5.ampr.org. <------- This is what I actively use on RF $ host 44.4.10.40 40.10.4.44.in-addr.arpa domain name pointer ki6zhd.ampr.org. <------- for special projects right now $ host 44.4.10.41 41.10.4.44.in-addr.arpa domain name pointer ki6zhd-dgw.ampr.org. <--------- This is what I use when the IPIP tunnel is up
Are these missing entries something I missed or something my local coordinator missed? Depending on your answer here, I imagine this will be the same reasoning for my other fellow HAMs being on the "to-be-deleted.txt" list.
Btw, the second entry is for the local HAM club that I've been working on their IP segment in their behalf.
--David
On 02/06/2016 12:41 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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.
What we did was to extract from the portal all the allocations which were listed as an end-user or which had one of the three connection types checked, or which were in a subnet from the encap list, or which were in one of the BGP-routed subnets.
Do those you spotted fit any of those criteria?
If they do, we have a bug in our process and we'll have to fix it. Please let me know.
- Brian
David, If you're using the .39 and .41 addresses in addition to the .40 address, your allocation isn't correct. It probably should be for a small subnet instead of for a single address. And for the typical /29 subnet, the .39 address would be in a different subnet than .40 and .41 are.
It looks like there's even more wrong here - 44.4.10.40/29 is allocated to N6ACK. You shouldn't have been allocated 44.4.10.40/32 at all, or N6ACK should have been allocated some other subnet. The portal software is supposed to prevent such overlaps from occuring, so it looks like we've discovered a bug in the portal.
There's a note in your /32 allocation that it was added by the gateways conversion script so that makes it a longstanding error that predates the existence of the portal.
The simplest solution is to get you a proper allocation, like 44.4.10.32/29. I can do that but it would be better if your coordinator worked with us on this. He is K6DLC Daniel Curry and I'm sure he'd be happy to help us straighten this out. Your gateway entry will have to change too, as it's for 44.4.10.40/32. - Brian
On Sat, Feb 06, 2016 at 01:43:24PM -0800, David Ranch wrote:
So I logged into the portal and I see:
Network Type Description Actions 44.4.10.40/32 user KI6ZHD Edit | Release 44.4.128.0/22 user KJ6VU Edit | Release
The top entry is seemingly incomplete as I've been previously granted and DNS resolution confirms I have (had?):
$ host 44.4.10.39 39.10.4.44.in-addr.arpa domain name pointer ki6zhd-5.ampr.org. <------- This is what I actively use on RF $ host 44.4.10.40 40.10.4.44.in-addr.arpa domain name pointer ki6zhd.ampr.org. <------- for special projects right now $ host 44.4.10.41 41.10.4.44.in-addr.arpa domain name pointer ki6zhd-dgw.ampr.org. <--------- This is what I use when the IPIP tunnel is up
Are these missing entries something I missed or something my local coordinator missed? Depending on your answer here, I imagine this will be the same reasoning for my other fellow HAMs being on the "to-be-deleted.txt" list.
Hey Brian,
Interesting to see that my allocation is messed up though I think I was given these addresses at two different times. I'll wait to see what Dan would like to do with my allocation. I'm flexible.
Beyond me, it seems that the various IPs that are listed in your to-be-deleted.txt are IPs that *aren't* in the portal. Correct? If so, it seems to me that the proper next steps would be for the various coordinators to reach out to the various HAMs and see if they want to retain their allocations. If they do want to keep their allocations, it then seems the coordinator will need to enter them into the portal for them.
Do I understand all this correctly?
--David
On 02/06/2016 02:33 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ David, If you're using the .39 and .41 addresses in addition to the .40 address, your allocation isn't correct. It probably should be for a small subnet instead of for a single address. And for the typical /29 subnet, the .39 address would be in a different subnet than .40 and .41 are.
It looks like there's even more wrong here - 44.4.10.40/29 is allocated to N6ACK. You shouldn't have been allocated 44.4.10.40/32 at all, or N6ACK should have been allocated some other subnet. The portal software is supposed to prevent such overlaps from occuring, so it looks like we've discovered a bug in the portal.
There's a note in your /32 allocation that it was added by the gateways conversion script so that makes it a longstanding error that predates the existence of the portal.
The simplest solution is to get you a proper allocation, like 44.4.10.32/29. I can do that but it would be better if your coordinator worked with us on this. He is K6DLC Daniel Curry and I'm sure he'd be happy to help us straighten this out. Your gateway entry will have to change too, as it's for 44.4.10.40/32.
- Brian
On Sat, Feb 06, 2016 at 01:43:24PM -0800, David Ranch wrote:
So I logged into the portal and I see:
Network Type Description Actions 44.4.10.40/32 user KI6ZHD Edit | Release 44.4.128.0/22 user KJ6VU Edit | Release
The top entry is seemingly incomplete as I've been previously granted and DNS resolution confirms I have (had?):
$ host 44.4.10.39 39.10.4.44.in-addr.arpa domain name pointer ki6zhd-5.ampr.org. <------- This is what I actively use on RF $ host 44.4.10.40 40.10.4.44.in-addr.arpa domain name pointer ki6zhd.ampr.org. <------- for special projects right now $ host 44.4.10.41 41.10.4.44.in-addr.arpa domain name pointer ki6zhd-dgw.ampr.org. <--------- This is what I use when the IPIP tunnel is up
Are these missing entries something I missed or something my local coordinator missed? Depending on your answer here, I imagine this will be the same reasoning for my other fellow HAMs being on the "to-be-deleted.txt" list.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
That would be ideal, yes.
The portal has been around for several years now. It's really not practical to contact the hams who aren't registered with it, since we don't have contact information for them. I think we have to assume that if they were still interested in using AMPRNet, by now their usage would be registered with the portal. As a practical matter, I think I have to insist on that. - Brian
On Sat, Feb 06, 2016 at 02:52:05PM -0800, David Ranch wrote:
Beyond me, it seems that the various IPs that are listed in your to-be-deleted.txt are IPs that *aren't* in the portal. Correct? If so, it seems to me that the proper next steps would be for the various coordinators to reach out to the various HAMs and see if they want to retain their allocations. If they do want to keep their allocations, it then seems the coordinator will need to enter them into the portal for them.
Hello Brian.
FYI, today Janusz HF1L (until Jan 31st 2016 his call sign was SP1LOP) and myself, we deleted from DNS database 228 entries altogether. In addition, deleted from the portal.ampr.org 4 non-operational gateways.
Best regards.
With the kind cooperation of Neil Johnson, I've identified nearly 15000 entries in the AMPR.ORG DNS that I feel can go away.
That list is available for review by anonymous FTP from hamradio.ucsd.edu. The file is called "to-be-deleted.txt". I encourage everyone who has a DNS entry to fetch a copy of the file and make sure that we haven't accidently included any entries that need to remain in the DNS.
[nitpick]
The file is available from hamradio.ucsd.edu/pub
[/nitpick]
Brian,
Thanks for your efforts: I'm not a DNS person, but I know that keeping things shipshape is always important,
I am, sorry to say, very puzzled by some of the entries in the file: there are "A" records for such hosts as "ham", "e911", and others that confuse me a lot. Please let me know if these are standard entries which any TLD needs, or if they're special-purpose records for the 44 net. Of course, since they're in the file, they may be errors, and if so, my apologies.
Thanks in advance: I appreciate your help, and I'll share this with the list in case other hams are in the same boat.
73,
Bill, W4EWH
On Sat, Feb 06, 2016 at 04:31:07PM -0500, Bill Horne W4EWH wrote:
I am, sorry to say, very puzzled by some of the entries in the file: there are "A" records for such hosts as "ham", "e911", and others that confuse me a lot. Please let me know if these are standard entries which any TLD needs, or if they're special-purpose records for the 44 net. Of course, since they're in the file, they may be errors, and if so, my apologies.
While I strongly prefer that people use callsigns for their hostnames, I've never made that an absolute prohibition of other names. Those entries that you're seeing are some of those other names that people have added over the years, and I'll be just as happy to see them go away. They're part of the mess that is the current DNS data. - Brian
February 6, 2016
As coordinator for the 44.116 subnet, I cleaned it up a couple of years ago and there is a some additional minor clean-up to do now.
What I observed when scanning through the list is that the majority of the addresses under my coordination are from pre-web portal days and were/are managed using the email robot. Subnet allocations contained inside the 44.116. subnet that were entered into the web-portal do not appear on the "to-be-deleted.txt" list, which is a good thing.
I would ask that the 44.116 subnet be passed over in the DNS cleanup effort. I will perform the necessary clean-up work in it.
David, W7SZS
Brian, I checked the list when when it was originally sent out and anything coming my way or those that have one that are not needed any longer were confirmed. As a result I did not respond to this because they do not need removed from the list. And therefore I didn't think I needed to reply because you were going to delete them at the first of the month. That could be why you are feeling somewhat discouraged because of the lack of responses. Apologies, Don - ve3zda
On Saturday, 6 February 2016, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ With the kind cooperation of Neil Johnson, I've identified nearly 15000 entries in the AMPR.ORG DNS that I feel can go away.
What was done was to create a list of valid subnets of network 44 by combining the encap list, the list of BGP-advertised subnets, and extracting all the connected or end-user subnets listed in the portal. We then made a list of all the DNS entries that no longer fall into any of those subnets. This is nearly half the "A" records in the DNS.
That list is available for review by anonymous FTP from hamradio.ucsd.edu. The file is called "to-be-deleted.txt". I encourage everyone who has a DNS entry to fetch a copy of the file and make sure that we haven't accidently included any entries that need to remain in the DNS. Please let me know of any such entries and I can remove them from the list.
Assuming our scheme worked, around the beginning of next month, March, I will process the list and remove those entries from the DNS. We still have a long ways to go but this will help.
Thank you. - Brian
44Net mailing list 44Net@hamradio.ucsd.edu javascript:; http://hamradio.ucsd.edu/mailman/listinfo/44net
No Don, that's fine. No need to apologize.
It's getting the legacy allocations into the portal that's not making me happy. Admittedly, the process is painful but I didn't think there'd be too many since we've had several years to get things in. Rob's point about needing some kind of bulk update process is well taken, and I'll look into that. - Brian
-
Bill Horne W4EWH -
Brian Kantor -
David Ranch -
David Warner -
Don Moore -
James -
Tom SP2L