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:

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 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 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

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

On Mon, Jan 18, 2016 at 08:15:16PM -1000, Antonio Querubin wrote:

Yes please! And I'm assuming AAAA RRs are not part of this cleanup either.

No, both of them (yours) are safe. - Brian

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.

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

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

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

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

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

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

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

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.

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

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

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

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