Hello all.
I am the ip coordinator for the State of Nevada and responsible for 44.125.0.0/16 I decided to take a look at amprhost file and found many entries that I did not issue and not sure if these were added before I volunteered to handle the region or people have taken upon themselves to create these entries. This includes one that I recently assigned to someone who is actively using his assignment I would like to know if these are in use so that the amprhost file can be update by me getting rid of them if possible.
Thanks
Harold K7ILO Nevada IP Coordinator
44.125.10.1 kj6ix.ampr.org kj6ix (Just assigned via portal) 44.125.10.1 kmev.ampr.org kmev 44.125.128.1 ke7kd.ampr.org ke7kd 44.125.128.2 kb7llk.ampr.org kb7llk 44.125.128.5 n7ktl.ampr.org n7ktl 44.125.128.6 n7msd.ampr.org n7msd 44.125.128.8 wa1wsx.ampr.org wa1wsx 44.125.128.9 n7rad.ampr.org n7rad 44.125.128.11 w7kju.ampr.org w7kju 44.125.128.13 nr7a.ampr.org nr7a 44.125.128.14 n6whz.ampr.org n6whz 44.125.128.15 kd4iee.ampr.org kd4iee 44.125.128.17 ki7sy.ampr.org ki7sy 44.125.128.18 nt7e.ampr.org nt7e 44.125.128.20 kj7ca.ampr.org kj7ca 44.125.128.128 prg3.router.ampr.org prg3.router 44.125.128.129 dx9600.router.ampr.org dx9600.router 44.125.128.131 hamgate.n8khn.ampr.org hamgate.n8khn 44.125.129.1 wa6ewv.ampr.org wa6ewv 44.125.129.2 kb7pjb.ampr.org kb7pjb 44.125.129.3 wa4ist.nv.ampr.org wa4ist.nv 44.125.129.4 wi7c.ampr.org wi7c 44.125.129.5 kd6ulm.ampr.org kd6ulm 44.125.129.6 kb7mty.ampr.org kb7mty 44.125.129.7 nx6w.ampr.org nx6w 44.125.129.8 kf7go.ampr.org kf7go 44.125.129.32 kb6imj.ampr.org kb6imj 44.125.129.34 kd6mve.ampr.org kd6mve 44.125.129.64 n7vxb.ampr.org n7vxb 44.125.129.103 n8khn.ampr.org n8khn 44.125.129.105 hamgate2.n8khn.ampr.org hamgate2.n8khn 44.125.130.2 n0zte.ampr.org n0zte 44.125.131.2 kb7qbs.ampr.org kb7qbs 44.125.131.3 n7xbm.ampr.org n7xbm 44.125.132.1 kb7eiu.ampr.org kb7eiu 44.125.132.2 n7vle.ampr.org n7vle 44.125.132.3 ke6icy.ampr.org ke6icy 44.125.132.5 nf7v.ampr.org nf7v 44.125.132.6 kb7pux.ampr.org kb7pux 44.125.132.7 w6old.ampr.org w6old 44.125.132.9 kb7pdf.ampr.org kb7pdf 44.125.132.12 ww7e.ampr.org ww7e 44.125.132.13 wb6w.ampr.org wb6w 44.125.132.34 n7npb.ampr.org n7npb 44.125.132.35 kb7no.ampr.org kb7no 44.125.132.36 kb7pde.ampr.org kb7pde 44.125.132.37 n7zfc.ampr.org n7zfc 44.125.132.38 wt8k.ampr.org wt8k 44.125.132.64 kc6rho.ampr.org kc6rho 44.125.132.67 kc7cex.ampr.org kc7cex 44.125.132.68 kc7cey.ampr.org kc7cey
On Mon, Jan 18, 2016 at 12:57:56PM -0800, Harold (K7ILO) wrote:
I would like to know if these are in use so that the amprhost file can be update by me getting rid of them if possible.
Harold, If you didn't assign them they are probably no longer in use. Data in the AMPR DNS goes back some 30 years so much of it is obsolete.
In particular, there are only two subnets of 44.125.0.0/16 that are registered as having gateways to them: 44.125.2.0/24 44.125.10.0/24
Thus of all those you listed, only DNS entries in those two subnets are likely to be in use.
It's been suggested that AND'ing the DNS A record IP addresses with the valid subnets list would clean up a LOT of the obsolete DNS entries.
This is something that can be done mechanically by a series of scripts. If someone wants to do that and generate a list of entries to be deleted, we'd be quite a bit further along, I think. Does anyone see any flaws in this? - Brian
Gang;
This is something that can be done mechanically by a series of scripts. If someone wants to do that and generate a list of entries to be deleted, we'd be quite a bit further along, I think. Does anyone see any flaws in this?
While there's never going to be a single turn-key solution to this, we should: 1) first backup the current DNS files 2) insure we ignore lines that may have a router alias instead of a callsign as it's hostname 3) try to send out mails to those registered in the portal that we're cleaning up DNS, and if they find they're not working anymore to contact their coordinator. We don't want to just cut off folks without warning that _we_ may make a mistake.
I cleaned all my zones up a while back (as you noticed). It was fairly seemless. I think there was only 1 guy I mistakenly dropped but was immediately right on it readding it.
#3 above though I think would be most important of the 3.
The initial script is done:
" 44.225.65.22 ","GATENOTFOUND" " 44.50.192.22 "," 108.160.233.78 " " 44.225.66.220 ","GATENOTFOUND" " 44.225.65.220 ","GATENOTFOUND" " 44.225.64.220 ","GATENOTFOUND" " 44.225.66.221 ","GATENOTFOUND" " 44.225.64.221 ","GATENOTFOUND" " 44.225.66.222 ","GATENOTFOUND" " 44.225.64.222 ","GATENOTFOUND" " 44.225.66.23 ","GATENOTFOUND" " 44.225.65.23 ","GATENOTFOUND" " 44.50.192.23 "," 108.160.233.78 " " 44.225.66.24 ","GATENOTFOUND"
and so on
Of the 36059 address records 30176 don't have a gateway associated with them. Seems kind of a large amount. I'll do some more sanity checking.
On Mon, Jan 18, 2016 at 3:34 PM, Brian n1uro@n1uro.ampr.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Gang;
This is something that can be done mechanically by a series of scripts. If someone wants to do that and generate a list of entries to be deleted, we'd be quite a bit further along, I think. Does anyone see any flaws in this?
While there's never going to be a single turn-key solution to this, we should:
- first backup the current DNS files
- insure we ignore lines that may have a router alias instead of a
callsign as it's hostname 3) try to send out mails to those registered in the portal that we're cleaning up DNS, and if they find they're not working anymore to contact their coordinator. We don't want to just cut off folks without warning that _we_ may make a mistake.
I cleaned all my zones up a while back (as you noticed). It was fairly seemless. I think there was only 1 guy I mistakenly dropped but was immediately right on it readding it.
#3 above though I think would be most important of the 3.
--
The only thing worse than an extreme left-wing state is an extreme left-wing commonwealth protected by the sovereign doctrine.
73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Mon, Jan 18, 2016 at 07:10:48PM -0600, Neil Johnson wrote:
Of the 36059 address records 30176 don't have a gateway associated with them. Seems kind of a large amount. I'll do some more sanity checking.
It's necessary to include the non-gatewayed subnets as well since they also make use of the DNS. We don't want to delete DNS entries for them.
To do that, you'll need a list of ALL the subnets registered with the portal. The encap file is insufficient. Chris will have to speak to whether the portal API can furnish that list of subnets. If it can, well and good, but if it can't, we'll have to come up with some other way to get that list. - Brian
On Mon, Jan 18, 2016 at 05:34:34PM -0800, Brian Kantor wrote:
It's necessary to include the non-gatewayed subnets as well since they also make use of the DNS. We don't want to delete DNS entries for them.
We ALSO have to preserve non-44 addresses, such as ja3yaq IN A 153.150.19.83
- Brian
Brian,
Both those make sense. Hopefully Chris has some time to take a look.
Thanks. -Neil
On Mon, Jan 18, 2016 at 7:41 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, Jan 18, 2016 at 05:34:34PM -0800, Brian Kantor wrote:
It's necessary to include the non-gatewayed subnets as well since they also make use of the DNS. We don't want to delete DNS entries for them.
We ALSO have to preserve non-44 addresses, such as ja3yaq IN A 153.150.19.83
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Mon, 18 Jan 2016, Brian Kantor wrote:
On Mon, Jan 18, 2016 at 05:34:34PM -0800, Brian Kantor wrote:
It's necessary to include the non-gatewayed subnets as well since they also make use of the DNS. We don't want to delete DNS entries for them.
We ALSO have to preserve non-44 addresses, such as ja3yaq IN A 153.150.19.83
Yes please! And I'm assuming AAAA RRs are not part of this cleanup either.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
Just throwing this out there....
As we now have (I think) a process that deletes portal accounts if the user does not login, could this be adjusted to remove allocated subsets and dns entries after 3 months (or some other timescale) post account delete?
For those that have historical services (someone mentioned entries to honour hams that have passed away) that they want to keep, either run multiple accounts on the portal (maybe a club account or just another personal one with -1 after the callsign) or merge these allocations to your own account. Also in the profile on the portal allow multiple email addresses for notification purposes so that club type accounts can hit more than one person.
Regards
Andy Brittain G0HXT g0hxt@greatbrittain.co.uk
On 19 Jan 2016, at 06:15, Antonio Querubin tony@lavanauts.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, 18 Jan 2016, Brian Kantor wrote:
On Mon, Jan 18, 2016 at 05:34:34PM -0800, Brian Kantor wrote:
It's necessary to include the non-gatewayed subnets as well since they also make use of the DNS. We don't want to delete DNS entries for them.
We ALSO have to preserve non-44 addresses, such as ja3yaq IN A 153.150.19.83
Yes please! And I'm assuming AAAA RRs are not part of this cleanup either.
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I will try to find email address' for my entries and see if I get a response. I agree with John. There may not be a gateway related so I don't want to drop any if they are still being used. I can tell though that these are mostly Northern Nevada assignments and at some point they were hot and heavy in tcpip looking at the ip assignments. But Ill give them a short chance though. Also, if they hadn't responded here in the group, Im assuming they are not being used so Ill give it just a little and then....... Delete, delete, delete. LOL
Thanks gang
Harold K7ILO Nevada IP Coordinator
-----Original Message----- From: 44Net [mailto:44net-bounces+k7ilo1=gmail.com@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: Monday, January 18, 2016 5:35 PM To: AMPRNet working group Subject: Re: [44net] DNS (was: Nevada IP Assignments)
(Please trim inclusions from previous messages) _______________________________________________ On Mon, Jan 18, 2016 at 07:10:48PM -0600, Neil Johnson wrote:
Of the 36059 address records 30176 don't have a gateway associated with them. Seems kind of a large amount. I'll do some more sanity
checking.
It's necessary to include the non-gatewayed subnets as well since they also make use of the DNS. We don't want to delete DNS entries for them.
To do that, you'll need a list of ALL the subnets registered with the portal. The encap file is insufficient. Chris will have to speak to whether the portal API can furnish that list of subnets. If it can, well and good, but if it can't, we'll have to come up with some other way to get that list. - Brian
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hi,
there is a gateway alive for 44.224.0.0/15. Maybe this initial script doesn't take /15 into account...
73, Jann
On 19.01.2016 02:10, Neil Johnson wrote:
(Please trim inclusions from previous messages) _______________________________________________ The initial script is done:
" 44.225.65.22 ","GATENOTFOUND" " 44.50.192.22 "," 108.160.233.78 " " 44.225.66.220 ","GATENOTFOUND" " 44.225.65.220 ","GATENOTFOUND" " 44.225.64.220 ","GATENOTFOUND" " 44.225.66.221 ","GATENOTFOUND" " 44.225.64.221 ","GATENOTFOUND" " 44.225.66.222 ","GATENOTFOUND" " 44.225.64.222 ","GATENOTFOUND" " 44.225.66.23 ","GATENOTFOUND" " 44.225.65.23 ","GATENOTFOUND" " 44.50.192.23 "," 108.160.233.78 " " 44.225.66.24 ","GATENOTFOUND"
and so on
Of the 36059 address records 30176 don't have a gateway associated with them. Seems kind of a large amount. I'll do some more sanity checking.
Yup,
Found a bug in my script.
Working on it.
Thanks for catching the issue.
-Neil
On Tue, Jan 19, 2016 at 3:13 PM, Jann Traschewski jann@gmx.de wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi,
there is a gateway alive for 44.224.0.0/15. Maybe this initial script doesn't take /15 into account...
73, Jann
On 19.01.2016 02:10, Neil Johnson wrote:
(Please trim inclusions from previous messages) _______________________________________________ The initial script is done:
" 44.225.65.22 ","GATENOTFOUND" " 44.50.192.22 "," 108.160.233.78 " " 44.225.66.220 ","GATENOTFOUND" " 44.225.65.220 ","GATENOTFOUND" " 44.225.64.220 ","GATENOTFOUND" " 44.225.66.221 ","GATENOTFOUND" " 44.225.64.221 ","GATENOTFOUND" " 44.225.66.222 ","GATENOTFOUND" " 44.225.64.222 ","GATENOTFOUND" " 44.225.66.23 ","GATENOTFOUND" " 44.225.65.23 ","GATENOTFOUND" " 44.50.192.23 "," 108.160.233.78 " " 44.225.66.24 ","GATENOTFOUND"
and so on
Of the 36059 address records 30176 don't have a gateway associated with them. Seems kind of a large amount. I'll do some more sanity checking.
-- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann@gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
How does 18496 entries without gateways out of 36059 total A records sound? Makes more sense to me.
-Neil
On Tue, Jan 19, 2016 at 4:42 PM, Neil Johnson neil.johnson@erudicon.com wrote:
Yup,
Found a bug in my script.
Working on it.
Thanks for catching the issue.
-Neil
On Tue, Jan 19, 2016 at 3:13 PM, Jann Traschewski jann@gmx.de wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi,
there is a gateway alive for 44.224.0.0/15. Maybe this initial script doesn't take /15 into account...
73, Jann
On 19.01.2016 02:10, Neil Johnson wrote:
(Please trim inclusions from previous messages) _______________________________________________ The initial script is done:
" 44.225.65.22 ","GATENOTFOUND" " 44.50.192.22 "," 108.160.233.78 " " 44.225.66.220 ","GATENOTFOUND" " 44.225.65.220 ","GATENOTFOUND" " 44.225.64.220 ","GATENOTFOUND" " 44.225.66.221 ","GATENOTFOUND" " 44.225.64.221 ","GATENOTFOUND" " 44.225.66.222 ","GATENOTFOUND" " 44.225.64.222 ","GATENOTFOUND" " 44.225.66.23 ","GATENOTFOUND" " 44.225.65.23 ","GATENOTFOUND" " 44.50.192.23 "," 108.160.233.78 " " 44.225.66.24 ","GATENOTFOUND"
and so on
Of the 36059 address records 30176 don't have a gateway associated with them. Seems kind of a large amount. I'll do some more sanity checking.
-- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann@gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-- Neil Johnson
Sample Data:
" 44.224.10.62 "," 141.75.245.225 " " 44.224.10.65 "," 141.75.245.225 " " 44.224.10.66 "," 141.75.245.225 " " 44.224.10.69 "," 141.75.245.225 " " 44.224.10.70 "," 141.75.245.225 " " 44.224.10.73 "," 141.75.245.225 " " 44.224.10.74 "," 141.75.245.225 " " 44.224.10.78 "," 141.75.245.225 " " 44.224.10.89 "," 141.75.245.225 " " 44.224.10.94 "," 141.75.245.225 " " 44.224.10.97 "," 141.75.245.225 " " 44.224.10.101 "," 141.75.245.225 "
On Tue, Jan 19, 2016 at 4:47 PM, Neil Johnson neil.johnson@erudicon.com wrote:
How does 18496 entries without gateways out of 36059 total A records sound? Makes more sense to me.
-Neil
On Tue, Jan 19, 2016 at 4:42 PM, Neil Johnson neil.johnson@erudicon.com wrote:
Yup,
Found a bug in my script.
Working on it.
Thanks for catching the issue.
-Neil
On Tue, Jan 19, 2016 at 3:13 PM, Jann Traschewski jann@gmx.de wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi,
there is a gateway alive for 44.224.0.0/15. Maybe this initial script doesn't take /15 into account...
73, Jann
On 19.01.2016 02:10, Neil Johnson wrote:
(Please trim inclusions from previous messages) _______________________________________________ The initial script is done:
" 44.225.65.22 ","GATENOTFOUND" " 44.50.192.22 "," 108.160.233.78 " " 44.225.66.220 ","GATENOTFOUND" " 44.225.65.220 ","GATENOTFOUND" " 44.225.64.220 ","GATENOTFOUND" " 44.225.66.221 ","GATENOTFOUND" " 44.225.64.221 ","GATENOTFOUND" " 44.225.66.222 ","GATENOTFOUND" " 44.225.64.222 ","GATENOTFOUND" " 44.225.66.23 ","GATENOTFOUND" " 44.225.65.23 ","GATENOTFOUND" " 44.50.192.23 "," 108.160.233.78 " " 44.225.66.24 ","GATENOTFOUND"
and so on
Of the 36059 address records 30176 don't have a gateway associated with them. Seems kind of a large amount. I'll do some more sanity checking.
-- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann@gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-- Neil Johnson
-- Neil Johnson
It's nice to see that about half the DNS entries would drop out using this technique. It's a good start. Once we have a full list of networks we can run it to see how it will do on the full dataset. As a data point, there are some 1,200 subnet allocations listed in the portal, as opposed to some 500 lines in the encap file, so fewer DNS entries would drop out using the full list. - Brian
On Tue, Jan 19, 2016 at 04:47:39PM -0600, Neil Johnson wrote:
How does 18496 entries without gateways out of 36059 total A records sound? Makes more sense to me. -Neil
Brain,
Are we saying that ampr.org names and presumably 44 addresses are only valid if they have a gateway associated with them?
I've had addresses with dns entries allocated since the early 90's which I use from time to time for testing on rf networks which don't have an associated gateway. The chances are that by now the only record of that allocation is the DNS entries. I guess I could just abandon them and request a new allocation, and attach it to a dummy gateway.
73, John G8BPQ
-----Original Message----- From: 44Net [mailto:44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: 18 January 2016 21:18 To: AMPRNet working group Subject: Re: [44net] Nevada IP Assignments
(Please trim inclusions from previous messages) _______________________________________________ On Mon, Jan 18, 2016 at 12:57:56PM -0800, Harold (K7ILO) wrote:
I would like to know if these are in use so that the amprhost file can be update by me getting rid of them if possible.
Harold, If you didn't assign them they are probably no longer in use. Data in the AMPR DNS goes back some 30 years so much of it is obsolete.
In particular, there are only two subnets of 44.125.0.0/16 that are registered as having gateways to them: 44.125.2.0/24 44.125.10.0/24
Thus of all those you listed, only DNS entries in those two subnets are likely to be in use.
It's been suggested that AND'ing the DNS A record IP addresses with the valid subnets list would clean up a LOT of the obsolete DNS entries.
This is something that can be done mechanically by a series of scripts. If someone wants to do that and generate a list of entries to be deleted, we'd be quite a bit further along, I think. Does anyone see any flaws in this? - Brian
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Mon, Jan 18, 2016 at 10:37:04PM -0000, John Wiseman wrote:
Are we saying that ampr.org names and presumably 44 addresses are only valid if they have a gateway associated with them?
It's been suggested that I use the portal's networks list instead of the encap file since there are clearly networks which are not tunneled.
I've had addresses with dns entries allocated since the early 90's which I use from time to time for testing on rf networks which don't have an associated gateway. The chances are that by now the only record of that allocation is the DNS entries. I guess I could just abandon them and request a new allocation, and attach it to a dummy gateway.
I'm suggesting that as a first cut at clearing up the DNS mess. I suspect that your radio-only DNS entries would be sacrificed in such a cleanup and I don't know offhand how to get around that since their subnets are not registered in the portal. If there's not too many of them, you could send me a list and I could add them into the portal as radio-connected.
Does Chris know about them so he won't accidently assign them to someone else?
The portal has a set of 'connection' tickboxes; this is used to indicate how the network is connected to the Internet. It really should be a pulldown menu allowing only one choice but that plea has been rejected. Even if no box is ticked, the network is registered with the portal and could be ANDed with the DNS - in other words, we'd use the portal's list of known networks instead of literally the encap file. That list would include all of the encap file, plus all the otherwise-connected subnets.
In other words, what I'm suggesting is that if the portal doesn't list the enclosing subnet of a DNS entry, that DNS entry would go away. - Brian
Here is my suggestion:
Get portal.ampr.org setup so that whenever an address or block is setup, the account associated with that address or block can make DNS entries (of all types). Have the portal update the DNS records for AMPR.ORG.
Have a clear process to delegate blocks of /24 or larger to have DNS delegated (forward and reverse).
Put out a general announcement that the old hosts file will be deprecated. Have a script to pull a current hosts file out from the live DNS for those who want the database but are not connected to the DNS server on a continual basis.
Kill the old hosts file.
Every active station, that has a portal account goes back in and sets their DNS records. No attempt to migrate the old hosts file at all.
If a station doesn't have a portal account, direct them to create it and then they can manage the DNS records for their block or address.
de K7VE
On Mon, Jan 18, 2016 at 3:00 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, Jan 18, 2016 at 10:37:04PM -0000, John Wiseman wrote:
Are we saying that ampr.org names and presumably 44 addresses are only
valid
if they have a gateway associated with them?
It's been suggested that I use the portal's networks list instead of the encap file since there are clearly networks which are not tunneled.
I've had addresses with dns entries allocated since the early 90's which
I
use from time to time for testing on rf networks which don't have an associated gateway. The chances are that by now the only record of that allocation is the DNS entries. I guess I could just abandon them and
request
a new allocation, and attach it to a dummy gateway.
I'm suggesting that as a first cut at clearing up the DNS mess. I suspect that your radio-only DNS entries would be sacrificed in such a cleanup and I don't know offhand how to get around that since their subnets are not registered in the portal. If there's not too many of them, you could send me a list and I could add them into the portal as radio-connected.
Does Chris know about them so he won't accidently assign them to someone else?
The portal has a set of 'connection' tickboxes; this is used to indicate how the network is connected to the Internet. It really should be a pulldown menu allowing only one choice but that plea has been rejected. Even if no box is ticked, the network is registered with the portal and could be ANDed with the DNS - in other words, we'd use the portal's list of known networks instead of literally the encap file. That list would include all of the encap file, plus all the otherwise-connected subnets.
In other words, what I'm suggesting is that if the portal doesn't list the enclosing subnet of a DNS entry, that DNS entry would go away. - Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Being able to delegate forward and reverse dns shouldn't be limited to a class C and larger. I have multiple commercial connections less than a /24 and can do that now. That should be up to the end user.
Sent from my iPhone
On Jan 18, 2016, at 7:27 PM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ Here is my suggestion:
Get portal.ampr.org setup so that whenever an address or block is setup, the account associated with that address or block can make DNS entries (of all types). Have the portal update the DNS records for AMPR.ORG.
Have a clear process to delegate blocks of /24 or larger to have DNS delegated (forward and reverse).
Put out a general announcement that the old hosts file will be deprecated. Have a script to pull a current hosts file out from the live DNS for those who want the database but are not connected to the DNS server on a continual basis.
Kill the old hosts file.
Every active station, that has a portal account goes back in and sets their DNS records. No attempt to migrate the old hosts file at all.
If a station doesn't have a portal account, direct them to create it and then they can manage the DNS records for their block or address.
de K7VE
On Mon, Jan 18, 2016 at 3:00 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Mon, Jan 18, 2016 at 10:37:04PM -0000, John Wiseman wrote: Are we saying that ampr.org names and presumably 44 addresses are only
valid
if they have a gateway associated with them?
It's been suggested that I use the portal's networks list instead of the encap file since there are clearly networks which are not tunneled.
I've had addresses with dns entries allocated since the early 90's which
I
use from time to time for testing on rf networks which don't have an associated gateway. The chances are that by now the only record of that allocation is the DNS entries. I guess I could just abandon them and
request
a new allocation, and attach it to a dummy gateway.
I'm suggesting that as a first cut at clearing up the DNS mess. I suspect that your radio-only DNS entries would be sacrificed in such a cleanup and I don't know offhand how to get around that since their subnets are not registered in the portal. If there's not too many of them, you could send me a list and I could add them into the portal as radio-connected.
Does Chris know about them so he won't accidently assign them to someone else?
The portal has a set of 'connection' tickboxes; this is used to indicate how the network is connected to the Internet. It really should be a pulldown menu allowing only one choice but that plea has been rejected. Even if no box is ticked, the network is registered with the portal and could be ANDed with the DNS - in other words, we'd use the portal's list of known networks instead of literally the encap file. That list would include all of the encap file, plus all the otherwise-connected subnets.
In other words, what I'm suggesting is that if the portal doesn't list the enclosing subnet of a DNS entry, that DNS entry would go away. - Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
--
John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays
On 1/18/16 7:45 PM, Corey Dean wrote:
Being able to delegate forward and reverse dns shouldn't be limited to a class C and larger. I have multiple commercial connections less than a /24 and can do that now. That should be up to the end user.
Yes, but in the portal reverse delegation of blocks only really makes sense for people doing BGP, which by defacto standard is a /24 or greater.
Thanks, Brian,
I've just checked on the portal, and it seems I'm too late - they have already been allocated to someone else. (44.131.4.18-21). So they won't get removed by the clearout, but I'll need to replace them anyway. But it highlights a problem with your suggested approach - It won't pick up unused names which are in address ranges that have been reallocated. And glancing though the uk dns records I suspect that applies to a lot of entries.
But I can't think of a better solution, and I guess an incomplete clearout is better than none!
73, John
-----Original Message----- From: 44Net [mailto:44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: 18 January 2016 23:00 To: AMPRNet working group Subject: Re: [44net] DNS Clearout
(Please trim inclusions from previous messages) _______________________________________________ On Mon, Jan 18, 2016 at 10:37:04PM -0000, John Wiseman wrote:
Are we saying that ampr.org names and presumably 44 addresses are only
valid
if they have a gateway associated with them?
It's been suggested that I use the portal's networks list instead of the encap file since there are clearly networks which are not tunneled.
I've had addresses with dns entries allocated since the early 90's which I use from time to time for testing on rf networks which don't have an associated gateway. The chances are that by now the only record of that allocation is the DNS entries. I guess I could just abandon them and
request
a new allocation, and attach it to a dummy gateway.
I'm suggesting that as a first cut at clearing up the DNS mess. I suspect that your radio-only DNS entries would be sacrificed in such a cleanup and I don't know offhand how to get around that since their subnets are not registered in the portal. If there's not too many of them, you could send me a list and I could add them into the portal as radio-connected.
Does Chris know about them so he won't accidently assign them to someone else?
The portal has a set of 'connection' tickboxes; this is used to indicate how the network is connected to the Internet. It really should be a pulldown menu allowing only one choice but that plea has been rejected. Even if no box is ticked, the network is registered with the portal and could be ANDed with the DNS - in other words, we'd use the portal's list of known networks instead of literally the encap file. That list would include all of the encap file, plus all the otherwise-connected subnets.
In other words, what I'm suggesting is that if the portal doesn't list the enclosing subnet of a DNS entry, that DNS entry would go away. - Brian
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
John,
Historically I recall 44.131.4.0/24 was allocated to Notts/Derbys/Leics. At some point in the 1990s there was a UK re-structure and Notts was allocated 44.131.56.0/24 - which is the bit I'm the present co-ordinator for. From a quick look at the list it appears 44.131.4.0 is now allocated to experimental mesh networks.
There are plenty of addresses in the present allocation free so if you need more or a bigger slice than a /27 to split up for yourself drop me a line and I'll allocate you some with pleasure.
73 Nick.
On 19/01/2016 10:17, John Wiseman wrote:
(Please trim inclusions from previous messages) _______________________________________________ Thanks, Brian,
I've just checked on the portal, and it seems I'm too late - they have already been allocated to someone else. (44.131.4.18-21). So they won't get removed by the clearout, but I'll need to replace them anyway. But it highlights a problem with your suggested approach - It won't pick up unused names which are in address ranges that have been reallocated. And glancing though the uk dns records I suspect that applies to a lot of entries.
But I can't think of a better solution, and I guess an incomplete clearout is better than none!
73, John
-----Original Message----- From: 44Net [mailto:44net-bounces+john.wiseman=cantab.net@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: 18 January 2016 23:00 To: AMPRNet working group Subject: Re: [44net] DNS Clearout
(Please trim inclusions from previous messages) _______________________________________________ On Mon, Jan 18, 2016 at 10:37:04PM -0000, John Wiseman wrote:
Are we saying that ampr.org names and presumably 44 addresses are only
valid
if they have a gateway associated with them?
It's been suggested that I use the portal's networks list instead of the encap file since there are clearly networks which are not tunneled.
I've had addresses with dns entries allocated since the early 90's which I use from time to time for testing on rf networks which don't have an associated gateway. The chances are that by now the only record of that allocation is the DNS entries. I guess I could just abandon them and
request
a new allocation, and attach it to a dummy gateway.
I'm suggesting that as a first cut at clearing up the DNS mess. I suspect that your radio-only DNS entries would be sacrificed in such a cleanup and I don't know offhand how to get around that since their subnets are not registered in the portal. If there's not too many of them, you could send me a list and I could add them into the portal as radio-connected.
Does Chris know about them so he won't accidently assign them to someone else?
The portal has a set of 'connection' tickboxes; this is used to indicate how the network is connected to the Internet. It really should be a pulldown menu allowing only one choice but that plea has been rejected. Even if no box is ticked, the network is registered with the portal and could be ANDed with the DNS - in other words, we'd use the portal's list of known networks instead of literally the encap file. That list would include all of the encap file, plus all the otherwise-connected subnets.
In other words, what I'm suggesting is that if the portal doesn't list the enclosing subnet of a DNS entry, that DNS entry would go away.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
What about MX records and CNAME that point to NON AMPR Adress ? will they also purged ? I get my @ampr.org mail via MX that goes to NON ampr IP and Have a WEB that have AMPR.ORG name and sit on NON ampr IP but have a CNAME to the NON AMPR address (all this by the way was done because i had no mechanism to update a gateway that sit on non fixed IP so i used Dynamic DNS name (no-ip.org) and made CNAME and MX to the computer that sit there so i wont lose AMPR.ORG Mail ) Ronen - 4Z4ZQ http://www.ronen.org
________________________________________
Is there any one of the SCRIPT fellows here that can catch for me the 44.138 addresses and send me the output So i will preserve it in a safe place ( I assume there are few of 10ts only ) Thankd in Advance Ronen - 4Z4ZQ http://www.ronen.org
________________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Brian Kantor Brian@UCSD.Edu Sent: Wednesday, January 20, 2016 7:09 AM To: AMPRNet working group Subject: Re: [44net] DNS Clearout
(Please trim inclusions from previous messages) _______________________________________________ No. We're only affecting net-44 A records. - Brian
On Wed, Jan 20, 2016 at 02:59:25PM +0000, R P wrote:
What about MX records and CNAME that point to NON AMPR Adress ? will they also purged ?
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I've mailed them to you. There were 103. All obsolete. - Brian
On Wed, Jan 20, 2016 at 03:34:54PM +0000, R P wrote:
Is there any one of the SCRIPT fellows here that can catch for me the 44.138 addresses and send me the output So i will preserve it in a safe place ( I assume there are few of 10ts only )
Hi group Is there any way to debug IPIP problems (for example traceroute ) ? because the IPIP is encapsulated packet the regular traceroute shows the destination tunnel only and if somewhere in the middle the packet get blocked it cant be traced .... If there is a tool in (preferred windows or even on Cisco router as a part of its CLI command set) unix i will be more then happy to know Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org
Not sure what you are looking for Ronen.
Let's say you have a gateway at 1.2.3.4 than is the IPIP endpoint for encapsulating 44.29.0.0/16 you want to run traceroute to 1.2.3.4, not 44.29.0.1 to see there is a problem getting to the gateway.
On Wed, Jan 20, 2016 at 10:06 AM, R P ronenp@hotmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi group Is there any way to debug IPIP problems (for example traceroute ) ? because the IPIP is encapsulated packet the regular traceroute shows the destination tunnel only and if somewhere in the middle the packet get blocked it cant be traced .... If there is a tool in (preferred windows or even on Cisco router as a part of its CLI command set) unix i will be more then happy to know Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I look for tool that will be able to run traceroute on IPIP to see what ISP if any block the IPIP Protocole regular traceroute will show next hope as the AMPR.ORG router but we know that there is no physical line between my gateway and the AMPR.ORG the packet drives between routers until it reach there and since it is IPIP packet the regular traceroute dont show these hops in this example you can see that from hope 20 to hope 22 there are much more hopes that cant be seen this was done to an AMPR.ORG adress but i want to do it from AMPr.ORG adress and of course it will behave the same and i will not know where the packet drop (on which node) if at all .... Hope I was more clear Regards Ronen - 4Z4ZQ http://www.ronen.org
traceroute to 44.8.0.160 (44.8.0.160), 30 hops max, 38 byte packets 1 r-bbone3.lim.thunderworx.net (217.27.32.1) 0.285 ms 0.227 ms 0.244 ms 2 primetel.j1.lim.nsp-transit.net (78.158.134.198) 0.470 ms 0.291 ms 0.293 ms 3 ae0-3072-j1.lon.nsp-transit.net (194.154.142.218) 61.156 ms v3038.j1.fra.prime-tel.net (78.158.141.201) 55.862 ms ae1-3033.j1.fra-nsp-transit.net (78.158.141.189) 49.604 ms 4 ldn-b3-link.telia.net (80.239.193.173) 79.739 ms ffm-b10-link.telia.net (80.239.193.177) 61.764 ms 52.522 ms 5 ffm-bb1-link.telia.net (213.155.134.134) 70.116 ms ldn-bb3-link.telia.net (80.91.249.171) 78.482 ms ldn-bb3-link.telia.net (62.115.140.236) 73.080 ms 6 ffm-b12-link.telia.net (62.115.142.3) 53.485 ms adm-bb3-link.telia.net (62.115.136.148) 69.218 ms ffm-b12-link.telia.net (62.115.141.229) 68.979 ms 7 limelight-ic-141253-ffm-b12.c.telia.net (213.248.95.146) 63.211 ms 68.450 ms 67.905 ms 8 limelight-ic-154704-adm-b7.c.telia.net (80.239.194.114) 78.390 ms tge1-1.fr4.fra1.llnw.net (178.79.240.10) 82.846 ms limelight-ic-154704-adm-b7.c.telia.net (80.239.194.114) 76.772 ms 9 tge1-6.fr3.lga.llnw.net (69.28.189.45) 150.977 ms tge2-6.fr4.lga.llnw.net (69.28.189.49) 145.072 ms tge1-6.fr3.lga.llnw.net (69.28.189.45) 132.259 ms 10 ve5.fr4.lga.llnw.net (69.28.172.206) 157.635 ms tge1-2.fr4.ord.llnw.net (69.28.172.198) 151.237 ms tge2-6.fr4.lga.llnw.net (69.28.189.49) 152.774 ms 11 tge1-2.fr4.ord.llnw.net (69.28.172.198) 163.084 ms 160.161 ms 165.432 ms 12 tge1-3.fr4.sjc.llnw.net (69.28.172.77) 232.704 ms paix-px1--limelight-10ge.cenic.net (198.32.251.193) 216.975 ms tge1-3.fr4.sjc.llnw.net (69.28.172.77) 236.214 ms 13 dc-lax-agg6--svl-agg4-100ge.cenic.net (137.164.11.0) 202.746 ms 201.682 ms 220.298 ms 14 dc-lax-agg6--svl-agg4-100ge.cenic.net (137.164.11.0) 213.985 ms 223.911 ms dc-tus-agg3--lax-agg6-100ge.cenic.net (137.164.11.7) 222.388 ms 15 dc-tus-agg3--lax-agg6-100ge.cenic.net (137.164.11.7) 209.733 ms dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 248.391 ms dc-tus-agg3--lax-agg6-100ge.cenic.net (137.164.11.7) 227.510 ms 16 dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 234.044 ms 227.560 ms 246.560 ms 17 dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 239.009 ms nodem-core-6807-vlan2767-gw.ucsd.edu (132.239.254.61) 243.880 ms 241.124 ms 18 nodem-core-6807-vlan2767-gw.ucsd.edu (132.239.254.61) 240.942 ms 248.819 ms ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 225.231 ms 19 amprgw.sysnet.ucsd.edu (169.228.66.251) 238.769 ms ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 214.500 ms 236.563 ms 20 * amprgw.sysnet.ucsd.edu (169.228.66.251) 225.931 ms * 21 * * * 22 kk7kx.ampr.org (44.8.0.160) 252.722 ms !<10> 265.797 ms !<10> 251.285 ms !<10>
------------------------------------------------------------------
Not sure what you are looking for Ronen.
Hi Ronen,
In URONode there and utility Brian wrote TRAcer work great.
Executing command...ampr.org:/uronode$ tra 44.8.0.160 Please wait while we trace to 44.8.0.160. 44.8.0.160 traceroute to 44.8.0.160 (44.8.0.160), 30 hops max, 60 byte packets 1 gw.ct.ampr.org (44.88.0.1) 52.285 ms 51.782 ms 51.371 ms 2 kk7kx.ampr.org (44.8.0.160) 172.836 ms !X 178.664 ms !X 178.152 ms !X Tracing complete. URONode tracer v1.3 - TraceRoute utility by N1URO. Goodbye. Returning you to the shell...
is that what you are looking for? this work of Linux.
73 de Jean
On Wed, Jan 20, 2016 at 1:06 PM, R P ronenp@hotmail.com wrote:
Hi group Is there any way to debug IPIP problems (for example traceroute ) ? because the IPIP is encapsulated packet the regular traceroute shows the destination tunnel only and if somewhere in the middle the packet get blocked it cant be traced .... If there is a tool in (preferred windows or even on Cisco router as a part of its CLI command set) unix i will be more then happy to know Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org
Dear Brian I havnt got any host files or list May you sent it again Thanks Forward Ronen - 4Z4ZQ
________________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Brian Kantor Brian@UCSD.Edu Sent: Wednesday, January 20, 2016 8:46 AM To: AMPRNet working group Subject: Re: [44net] DNS Clearout
(Please trim inclusions from previous messages) _______________________________________________ I've mailed them to you. There were 103. All obsolete. - Brian
On Wed, Jan 20, 2016 at 03:34:54PM +0000, R P wrote:
Is there any one of the SCRIPT fellows here that can catch for me the 44.138 addresses and send me the output So i will preserve it in a safe place ( I assume there are few of 10ts only )
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
You can pull the whole file yourself
ftp://hamradio.ucsd.edu/pub/amprhosts
On Thu, Jan 21, 2016 at 6:58 AM, R P ronenp@hotmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Dear Brian I havnt got any host files or list May you sent it again Thanks Forward Ronen - 4Z4ZQ
From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Brian Kantor Brian@UCSD.Edu Sent: Wednesday, January 20, 2016 8:46 AM To: AMPRNet working group Subject: Re: [44net] DNS Clearout
(Please trim inclusions from previous messages) _______________________________________________ I've mailed them to you. There were 103. All obsolete. - Brian
On Wed, Jan 20, 2016 at 03:34:54PM +0000, R P wrote:
Is there any one of the SCRIPT fellows here that can catch for me the
44.138 addresses and send me the output So i will preserve it in a safe place ( I assume there are few of 10ts only ) _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Does anyone have a contact with Phil Karn (ka9q) ? The email in QRZ didn't get any answer by him Thanks for any assistance Ronen - 4Z4ZQ
On Thu, Jan 21, 2016 at 09:53:28AM -0800, K7VE - John wrote:
You can pull the whole file yourself
ftp://hamradio.ucsd.edu/pub/amprhosts
It's somewhat disturbing to note that although I've emailed the list twice, he didn't get it --- apparently his email provider is filtering it out. I've mailed it to his other address at a different email provider and he got it there. - Brian
There are issues with mailing lists and SPF.
If the receiver has a reject SPF policy and the sender specifies SPF hosts then the mail coming from the list will be discarded unless the receiver has an exception for the IP address of the mailing list mail server.
Bob
"Brian Kantor Brian@UCSD.Edu says:"
It's somewhat disturbing to note that although I've emailed the list twice, he didn't get it --- apparently his email provider is filtering it out. I've mailed it to his other address at a different email provider and he got it there.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Thu, Jan 21, 2016 at 12:37:59PM -0600, Bob Brose wrote:
There are issues with mailing lists and SPF.
Irrelevant. This was direct email, not mailing list mail. I won't pollute 300+ mailboxes with a list that only one person wants.
BTW, we have such an inclusion in our site's SPF. - Brian
Mailing list which are correctly setup (e.g. Using mailman, majordomo, etc) use a list specific envelope from address so they don't trigger SPF.
Please note there is a difference between the envelope from and the From: Header in th mail sources. The envelope from is supposed to trigger SPF, if in your case the From: Header is triggering SPF you might have a configuration problem.
Mailing lists implemented via simple forwarding to several destination of course don't replace the envelope from and thus may trigger SPF.
Is this case the culprit might be a policy which blocks attachments ending in csv (or txt).
73 de Marc, LX1DUC
On 21 janv. 2016, at 19:42, Brian Kantor Brian@UCSD.Edu wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Thu, Jan 21, 2016 at 12:37:59PM -0600, Bob Brose wrote: There are issues with mailing lists and SPF.
Irrelevant. This was direct email, not mailing list mail. I won't pollute 300+ mailboxes with a list that only one person wants.
BTW, we have such an inclusion in our site's SPF.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net