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(a)n1uro.ampr.org> wrote: -- Neil Johnson

On Mon, Jan 18, 2016 at 05:34:34PM -0800, Brian Kantor wrote: 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: Yes please! And I'm assuming AAAA RRs are not part of this cleanup either. Antonio Querubin e-mail: tony(a)lavanauts.org xmpp: antonioquerubin(a)gmail.com

On Mon, Jan 18, 2016 at 08:15:16PM -1000, Antonio Querubin wrote: 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: -- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

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(a)erudicon.com> wrote: -- 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:

On Mon, Jan 18, 2016 at 10:37:04PM -0000, John Wiseman wrote: 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'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 &lt;k7ve(a)k7ve.org&gt; 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 &lt;Brian(a)ucsd.edu&gt; 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(a)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: valid 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. request 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(a)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 &lt;44net-bounces+ronenp=hotmail.com(a)hamradio.ucsd.edu&gt; on behalf of Brian Kantor &lt;Brian(a)UCSD.Edu&gt; 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: _________________________________________ 44Net mailing list 44Net(a)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 &lt;44net-bounces+ronenp=hotmail.com(a)hamradio.ucsd.edu&gt; on behalf of Brian Kantor &lt;Brian(a)UCSD.Edu&gt; 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: _________________________________________ 44Net mailing list 44Net(a)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 &lt;Brian(a)UCSD.Edu&gt; says:" -- Bob Brose N0QBJ mailto:bob@qbjnet.com public key at http://www.qbjnet.com/key.html

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