21 Dec
2022
21 Dec
'22
5:56 a.m.
On Wed, 21 Dec 2022 11:23:18 +0100, "f5pbg(a)free.fr" <f5pbg(a)free.fr>
wrote:
An co-administrator indicated that he could not delete
the IPs because
it was before the creation of the portal.
It's wrong, that's all.
I never said that. I meant to say they don't exist in the portal
because they pre-date the portal by many years. The portal didn't
exist when I assigned those addresses and the only way to register
them in the ampr domain was to create A-records for them in the DNS.
Many of my entries in the 44.18/16 date to 1995/1996. I have been in
this game for a very long time and I think I know what it's about.
It is not possible to create the Portal data entries because it takes
a request submitted to the portal that gets handled by the coordinator
for that block. A coordinator cannot self-request a block and by fiat,
assign it, because that makes him both the assignee and the
coordinator.
When the portal was created I emailed Brian Kantor about my concerns
regarding migration of the domain entries into the portal but they
went unanswered. Lost in the email debris, I suppose. The DNS should
have been migrated into the portal when the database was created since
it was authoritative as to what IP's were allocated at that time. Now
it's too late.
When you corrupt the DNS as you did here, you create the potential for
severe damage or loss of life. I have assigned several subnets to San
Bernardino RACES and other emergency response groups who potentially
rely on DNS to function and you can take those networks down in one
ignorant action.
Another problem I have with the portal and DNS coordination is that
there is no mechanism in the portal for adding DNS entries. The DNS
system is vulnerable to unauthorized or malicious changes and this is
a perfect example of that.
--
Geoff Joy - ke6qh -
AmprNet IP Address Coordinator for San Bernardino & Riverside Counties.
(44.18/16)