That wont work, as the DNS function of the portal is not live yet.
At 12:13 PM 1/18/2016, you wrote:
>I could then attempt to send an e-mail message asking the call sign owner
>to update their DNS entries via the portal.
----------
Wm Lewis (KG6BAJ)
AMPR Net IP Address Coordinator - Northern and Central California Regions
(A 100% Volunteer Group)
(530) 263-1595 (Home/Office)
______________________________________________
----------
This message is for the designated recipient only and MAY CONTAIN
PRIVILEGED OR CONFIDENTIAL INFORMATION.
If you have received it in error, please notify the sender immediately and
delete the original. Any other use of this E-mail is prohibited.
All,
I've hacked together a script that goes through the ampr.org DNS zone file
and pulls out callsigns and related A, CNAME, and MX records.
Example:
CALL: N0SFH
dhcp-20.n0sfh IN A 44.50.192.20
dhcp-21.n0sfh IN A 44.50.192.21
dhcp-22.n0sfh IN A 44.50.192.22
dhcp-23.n0sfh IN A 44.50.192.23
dhcp-24.n0sfh IN A 44.50.192.24
dhcp-25.n0sfh IN A 44.50.192.25
dhcp-26.n0sfh IN A 44.50.192.26
dhcp-27.n0sfh IN A 44.50.192.27
dhcp-28.n0sfh IN A 44.50.192.28
dhcp-29.n0sfh IN A 44.50.192.29
dhcp-30.n0sfh IN A 44.50.192.30
gw.n0sfh IN A 44.50.192.1
n0sfh-1 IN A 44.50.192.5
Line count= 13
I could take the call signs and run them against QRZ.com (I have a XML
subscription) and/or the Radio Amateur Call Book Data (The "Flying Horse"
CD - I'm willing to buy the data).
I could use that data to 1) determine if the call sign was still active 2)
try to find an e-mail address associated with the call sign.
I could then attempt to send an e-mail message asking the call sign owner
to update their DNS entries via the portal. In the e-mail we could give
the call sign owner 60-90 days to update their DNS entries or they would be
deleted.
I came up with 17899 potential call signs in the zone file.
I would need:
1. Permission from the ARDC to send e-mails on its behalf.
2. A way to whittle down the file further, if possible.
3. Volunteers to translate the notification e-mail into multiple languages.
4. Someone who has an ISP or mail host willing to allow the sending of
10's of thousands of e-mails without it getting flagged as SPAM (I would
want to try and contact each call sign owner with a valid e-mail at least
three times before the deadline).
5. Access to the portal's DNS database to determine if someone registered
their entries.
Thoughts?
-Neil
--
Neil Johnson
Guys I am not a moderator, owner or anything else... just a quickly becoming
disinterested Coordinator in this group. 1 Reason the thread topics are out
of whack.
Take this one.. below titled (Verifying the Identities of IP
Coordinators,)yet contains only discussions about DNS. It is no longer about
identities, of IP Coordinator yet it goes on and on and on about DNS under a
misleading Subject line. Then there is the THREAD more correctly titled
Dynamic Addresses. How is anyone following both of these and making sense
out of them. ? I really do not care what we talk about.. But I personally
like being able to pick and choose what I read about.. without having to
fish every message. When we are talking about orangutans, under a title of
Planets from Space.. Sure is miss leading..
Just todays gripe.. Carry on I am sure nothing will change.
Also remember to... >
(Please trim inclusions from previous messages)
73 Jerry N9LYA
My guess would be that it's not a DNS server load issue but more of an
administrative / architecture issue. If stale/abandoned entries are not
purged, it makes the task of design and coordination a tad more difficult
since new hosts/networks have to work around the already assigned ones.
Assi kk7kx
-----Original Message-----
From: 44Net [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On
Behalf Of R P
Sent: Sunday, January 17, 2016 10:18 PM
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Verifying the identities of IP coordinators
(Please trim inclusions from previous messages)
_______________________________________________
I ask again
What is so important to clean the DNS from all the amount of unused
hosts ? is it a matter of load on the DNS that result in a slow response
?
or any other effect im not aware of ?
The only thing i can think of is making zone transfer of big file twice a
day but in this days transferring even 10 MegaByte file each day
consider nothing
Maybe Brian can answer this ?
However to answer your question
Authorized users can change the DNS data there is a format needed to be
sent in the email that the robot know to inter-prate something
such as : <host name > <add or delete> <what kind of record should it
be (MX A etc)> <Ip adress>
you send each host as a single line and you can more then one line
Since the robot have a format checking mechanism you dont have to be a DNS
expert in order to add or delete hosts
specially if you want only to add host name and not complex things such as
MX records or CNAME
Regards
Ronen - 4z4zq
http://www.ronen.org
----------------------------------------------------------------------------
------------------------------------------
1. What information must a coordinator send to the ampr.org DNS to
create/modify a listing?
2. Is there a standard entry format for the information a coordinator
sends in, or is it parsed by hand?
4. Is it possible for me to reformat the existing files, knowing
little about DNS?
hth.
73,
Bill KW4OC
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
> Subject:
> Re: [44net] Verifying the identities of IP coordinators
> From:
> K7VE - John <k7ve(a)k7ve.org>
> Date:
> 01/15/2016 10:05 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
> I beg to differ. I agree with the NAT position, but there are definitely
> cases for the use of dynamically allocated addresses.
>
> Here is one: D-STAR data protocol encapsulates Ethernet frames inside of
> D-STAR frames, in turn those can contain IP frames. If I am in a mobile,
> driving down a highway and using a series of access points, then receiving
> a new 44.x.x.x address via DHCP from those access points keeps me connected
> for services I am using.
I would implement that using a dynamic routing of a fixed address rather than assignment
of a dynamic address (and having to cope with a changing address).
Rob
Yes the RIP broadcasts come over protocol 4 from amprgw.sysnet.ucsd.edu
Here is a network dump of some directed to my gateway:
Network dump of Incoming RIP
#############################
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
04:00:00.218059 IP amprgw.sysnet.ucsd.edu.route >
cpe-174-103-224-97.new.res.rr.com.57644: RIPv2, Response, length: 504
04:00:00.218108 IP cpe-174-103-224-97.new.res.rr.com >
amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp
port 57644 unreachable, length 540
04:00:00.218121 IP amprgw.sysnet.ucsd.edu >
cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route >
rip2-routers.mcast.net.route: RIPv2, Response, length: 504
(ipip-proto-4)
04:00:00.218130 IP amprgw.sysnet.ucsd.edu.route >
cpe-174-103-224-97.new.res.rr.com.57644: RIPv2, Response, length: 504
04:00:00.218141 IP cpe-174-103-224-97.new.res.rr.com >
amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp
port 57644 unreachable, length 540
04:00:00.218262 IP amprgw.sysnet.ucsd.edu >
cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route >
rip2-routers.mcast.net.route: RIPv2, Response, length: 504
(ipip-proto-4)
04:00:00.218550 IP amprgw.sysnet.ucsd.edu.route >
cpe-174-103-224-97.new.res.rr.com.57644: RIPv2, Response, length: 504
04:00:00.218573 IP cpe-174-103-224-97.new.res.rr.com >
amprgw.sysnet.ucsd.edu: ICMP cpe-174-103-224-97.new.res.rr.com udp
port 57644 unreachable, length 540
04:00:00.218582 IP amprgw.sysnet.ucsd.edu >
cpe-174-103-224-97.new.res.rr.com: IP gw.ampr.org.route >
rip2-routers.mcast.net.route: RIPv2, Response, length:
>Hi there
>Did I understand correct that the RIP system we use is RIP over the Tunneling ?
>Or in other words we need at first to have Tunnel to AMPR Router
>
>and only then the RIP data can pass through ?
>
>Any Info Welcome
>Thanks Forward
>Ronen - 4Z4ZQ
>http://www.ronen.org
> Subject:
> Re: [44net] Verifying the identities of IP coordinators
> From:
> Bill Vodall <wa7nwp(a)gmail.com>
> Date:
> 01/14/2016 10:19 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
>> >When someone applies for an address...
> Transient users don't need static or even real IP addresses. We could
> re-invent DHCP...
I am firmly against that.
Contrary to the Internet as it is now, we are not a collection of transient users that only use a couple
of centralized services, but we are all peers that should be able to both use and offer services and make
connections in all directions.
That is what makes us different from ordinary internet users, and using dynamic or even translated
addresses kills all that and makes the whole AMPRnet superfluous.
Rob
Can we start a new thread title for all the items that are coming up... I
marked this thread on my system as DOA and I see I am confused going by the
thread titles...
No Offense.. Just asking for some semblance of order..
Many Thanks 73 Jerry N9LYA
-----Original Message-----
From: 44Net [mailto:44net-bounces+n9lya=nwcable.net@hamradio.ucsd.edu] On
Behalf Of Marius Petrescu
Sent: Friday, January 15, 2016 5:41 PM
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Verifying the identities of IP coordinators
(Please trim inclusions from previous messages)
_______________________________________________
Now really...
You actually want a dynamic DNS?
We can not manage the regular DNS entries in the portal yet.
But what is stopping you to send a DNS robot update mail on IP change?
Marius, YO2LOJ
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
While using LOTW certificates is quite ingenious, I think the whole
process to extract the keys will be a big hangup for the less
technical folks.
It really needs to be as easy as possible, like how you can use you
facebook login (oauth token) to log into other sites.
Basically it your ARRL login should work like that, so you can login
to the ampr portal, qrz, etc.
> Subject:
> Re: [44net] Verifying the identities of IP coordinators
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 01/14/2016 08:10 AM
>
> To:
> "AMPRNet working group" <44net(a)hamradio.ucsd.edu>
>
>
> The reason is simple why not to allow automatic requests:
> The coordinators may have a certain IP allocation scheme in there minds. Maybe regional, maybe some other criteria.
> That means that not every request out of the blue fits that scheme.
> So an IP range may be unallocated, but it does not fit the allocation scheme.
> An coordinator would change the requested one allocate the right one, which would not happen in an automated system.
>
> e.g. in YO, I allocate IP ranges based on regions, so that the first number in the block fits the requestors region number (the same as in the callsign).
> I had requests like "please allocate 44.182.35.xx to me", the user being in region 8.
> It resulted in allocating the first unused 44.182.8x.xx /24 subnet to him, and not the original requested one.
> This would not have been possible in an automated system.
>
> Marius, YO2LOJ
It is the same here, Marius.
When someone applies for an address I need to know where they are located, if applicable to which
access point they want to link, if they want a single address or a subnet, what size of subnet they need,
a motivation when that is larger than the default /28, etc.
Once I have that information I look at the already assigned addresses, and assign them one that fits.
(there is a different area in each subnet where single addresses and subnets are allocated)
Sure it could all be catered for in input forms, but the amprnet portal currently doesn't, and upgrades
to its functionality appear to occur only very infrequently. I don't think it is worthwile to spec out everything
and have someone spend time on implementing it, only to find ourselves locked into that system which may
not be optimal once some decision is made to handle things differently.
Furthermore, many applicants really need some guidance and make requests that are incomplete or not
justified (e.g. request allocation of a /22 network for a single station).
The semi-automatic mechanism appears to work well and makes it easy to ask for more information.
Rob
