6 Feb
2016
6 Feb
'16
1:31 p.m.
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
6 Feb
6 Feb
1:40 p.m.
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
2:36 p.m.
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
3:41 p.m.
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
4:43 p.m.
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
5:33 p.m.
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.
5:52 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
6:06 p.m.
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.
7 Feb
7 Feb
4:30 a.m.
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.
--
Tom - SP2L
------------------------------------
It is nice to be important.
But it is more important to be nice!
6 Feb
6 Feb
4:31 p.m.
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
4:44 p.m.
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
7:45 p.m.
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
19 Mar
19 Mar
2:09 p.m.
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(a)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(a)hamradio.ucsd.edu <javascript:;>
http://hamradio.ucsd.edu/mailman/listinfo/44net
4:29 p.m.
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
3169
days inactive
3211
days old
13 comments
7 participants
participants (7)
-
Bill Horne W4EWH -
Brian Kantor -
David Ranch -
David Warner -
Don Moore -
James -
Tom SP2L