44net

44net@mailman.ampr.org

3194 discussions

A bit OT
by Peter Mallett 09 Feb '16

09 Feb '16

Hi All, Sorry for my off topic question, I shall be brief. Does anyone know where or how to update the listing on http://www.ampr-gates.net/frame_e.htm Is there another site ? Regards ..... Peter ZL2BAU

1 0

Re: [44net] 44Net Digest, Vol 5, Issue 32
by f5pbg＠free.fr 09 Feb '16

09 Feb '16

Hello Brian, French Hamnet works fine on 44.151 subnet like you can see. This is the historic network, no problem on it. REF association ask for a new 44.168 subnet for their project. For 44.168 subnet, contact the coord F1TZV at f1tzv(a)evc.net I read the Hamlist of REF association http://ref-union.net/Hamnet/ and there is nothing since fews months. I just write a message on this list in order to know what happend. If i have a answer, i will put it here. Best regards, Ludovic - F5PBG. Le 09/02/2016 20:00, 44net-request(a)hamradio.ucsd.edu a écrit : > Message: 5 > Date: Tue, 9 Feb 2016 08:21:33 -0800 > From: Brian Kantor<Brian(a)UCSD.Edu> > To:44net@hamradio.ucsd.edu > Subject: [44net] HAMNet France > Message-ID:<20160209162133.GA14859(a)UCSD.Edu> > Content-Type: text/plain; charset=us-ascii > > Can anyone advise me of the status of the French HAMNet project? > > I've not heard anything from those folks in over a year, and the > coordinator for 44.168.0.0/16 hasn't logged into the portal since > May of 2015. > - Brian

2 1

HAMNet France
by Brian Kantor 09 Feb '16

09 Feb '16

Can anyone advise me of the status of the French HAMNet project? I've not heard anything from those folks in over a year, and the coordinator for 44.168.0.0/16 hasn't logged into the portal since May of 2015. - Brian

3 2

Re: [44net] DNS cleanup
by Rob Janssen 09 Feb '16

09 Feb '16

> Why does an hostname of an isolated system need to be resolved in a world > wide DNS? > It has no connection to the internet via the gw or to the tunnelling system, > so that DNS resolution will allways lead to an unreachable host. Because there really is no relation between IP allocation and routing. For example, back in the days when we ran a lowspeed IP packet network here and in surrounding countries (1987-2003 or thereabouts), it was strictly forbidden in the regulations to have a connection between a radio station and a public communication line. We had thousands of stations active but none reachable from internet. hostfiles were used instead of DNS, but the information in the hostsfiles was always replicated to the public DNS, to indicate what addresses are allocated to whom. Also, it would have been possible (had the software on the typical station supported it) to download a zonefile and use it offline. Now that we have linking over- and to internet, we are in fact still doing that. Our gateway downloads the zonefile from hamradio.ucsd.edu daily, and loads it in a local DNS server on 44-net, only reachable from the radio side. So even when we lose our internet connection, we can still resolve .ampr.org addresses as they were valid just before the breakdown. I don't think that "reachable from the internet" or "reachable from net-44 systems that tunnel over internet" should be a criterion for being in the .ampr.org DNS. (this does not even consider that there may be firewalls that make it impossible to detect for outsiders that a system is connected, while the system itself can perfectly make outgoing connections) Rob

9 11

Re: [44net] DNS cleanup
by Rob Janssen 08 Feb '16

08 Feb '16

> If you look in the file that Brian posted you will see that there are no > 44.137.X.X (or 44.130.X.X) records in the list to be deleted. > So your DNS records should be okay. I know that, and that is why I am taking up the job myself. (I think it is a bit strange that the networks that are BGP or IPIP routed would not have to be cleaned) Rob

3 3

Re: [44net] DNS cleanup
by Rob Janssen 08 Feb '16

08 Feb '16

> Since we cleaned up 44.130/16 a while ago, we have some hints for your > first cleanup round. Maybe you should consider taking obsolete CNAME- > and MX-records into account. Example: > to-be-deleted.txt: > g7suh IN A 44.131.254.242 > ampr.org: > 2e1arm IN CNAME g7suh Yes, please take good notice of that! Some time ago I have made a lot of effort to delete all dangling CNAME and MX records, hundreds of them. Apparently there have been cleanups where entire subnets worth of A records were deleted, but many MX and CNAME records still referred to them. It looks like at some time, for every A record created in certain US subnets, a corresponding MX record (just "call IN MX 10 call") had been created. A bit pointless, but worse is that those were not removed when the A records were removed. This time around, please make sure that whenever some record is removed, all records that point to it are also removed. As Jann correctly points out, there are MX records that point to external servers (although sometimes the trailing period was forgotten, making them inoperative). During the above cleanup, I found several of those that do not exist in DNS anymore, and deleted them as well. I did not check if the ones that still resolve would offer SMTP service and would accept mail to the specific domain name (in .ampr.org!). Probably lots of them don't. This weekend I sent out a mailing about renewing registration by tacking @amsat.org @veron.nl and @vrza.nl to all callsigns (the latter are two amateur societies here) and of course I got many delivery failures back where the address at the aliasing service exists, but the address the mail is forwarded to no longer exists. We are not the only one with this cleanup problem... Rob

1 0

encap.txt
by Don Moore 08 Feb '16

08 Feb '16

I downloaded the encap.txt file just now and it doesn't match the gateway list. Is it not being updated or has something gone wrong in the process? 73, Don

2 1

Re: [44net] DNS cleanup
by Rob Janssen 07 Feb '16

07 Feb '16

> People -- we need the cleanup. I say, be aggressive. If an active DNS > record gets deleted, just recreate it -- Sheesh. Maybe you have not understood it, but we are actually *using* the network. For places where it is just a leftover of the packet radio days, I agree. Today I deleted a number of old BBS records, and a few hours later I got a mail back that one that was still in use. We cannot do that for all 3000 active records. Rob

5 4

Re: [44net] DNS cleanup
by Rob Janssen 07 Feb '16

07 Feb '16

> No, expectation is that people getting AMPR address space should > have the subnet they're in registered with the portal. That includes > non-connected hosts and /32s. Is it really a good idea to base the cleanup on data in the portal? I mean, the guy running the portal clearly does not have the resources (or the motivation?) to do even minor maintenance on it, let alone finish work on features like the DNS registration that have been in incompleted state for years. Is it a good idea to make our entire network dependent on that? I cannot remove a subnet that was erroneously added in the past (and where user subnets where added inside) without deleting those, and a request to the maintainer to do that outside the portal UI that I sent months ago is still not processed. I also cannot add any regional subnets for which parts are already registered to users. The whole implementation of subnet hierarchy and record ownership is much too strict, it only works when everything is done "the correct way" on the first try, which simply is not realistic. Compare it to HamnetDB where you can simply reshuffle the whole subnetting by inserting, deleting or editing existing records within the existing hierarchy. I also don't like the idea to send a request to all users to "register themselves" and then being bombarded with allocation request mails from the portal that all need to be manually edited because the requesting user cannot specify an existing allocation to be registered. Users that do not understand the whole mechanism cannot be ignored, because either you don't process the request and it remains on the todo list, or you reject the request and those users just click the links in the rejection mail which results in the same request being posted again :-( In 44.137.0.0/16, really only the users that want to run an IPIP tunnel are registered in the portal, there are many other users that connect in a different way. Luckily we are not affected by this cleanup because we are BGP routed, but at the same time that also shows how this method is failing. After all, what does the routing method have to do with the DNS contents? Basically nothing. Why should all our inactive records remain there while those of other countries are deleted even when they may be active? When we want to clean the DNS, we should look at the situation on a country by country base. I am all for deleting entries for callsigns that have expired, and in fact I regularly do that. Probably other countries also have lists of active callsigns and a quick scan can be made to delete all expired callsigns and probably also those records that are not related to callsigns. We could request all coordinators to send a list of active callsigns, and we could process those lists to generate a deletion list like I already do for my area. We could also ask each coordinator what is the state of IP packet or other use of those addresses in their country, and maybe get whole networks deleted when they no longer exist. I will try to dig in the old data I still have saved (for my area) to generate a list of callsigns and the date of last registration or reconfirmation, and try again to contact all callsigns with records before a certain date and delete them when there is no reply. This should clean out more records than the previous run, where I only deleted those registrations where the owner replied they no longer required them. Rob

16 26

Re: [44net] Dumb question - 44.130 IP address?
by Dg7nef 07 Feb '16

07 Feb '16

Hi group, hello Thomas, IIRC the initial assignment was in fact given to me by you and Paul, so I'm happy to hear from you again. :) On 02/07/16 23:55, Thomas Osterried wrote: > Hello, > > well, a longer tradition than the quite new portal are the country-wide IP-Koordinators. > > In DL, we have the coordination team of three people (dd9qp, dg8ngn, dl9sau) and we delegate the responsibility of the local assignments to the regional coordinators. This concept goes back to the last century. > From the regional coordinator, Wolfgang had got the initial assignment of his IP addresses. That is correct. And that was kind of "status quo" when I had to quit Packet Radio activity. But the first thing I found when I searched for infos on the current state of IP in PR was that my IP's no longer do exist (which in fact is not really the problem for me, as I really was not active for a long time. So, no complaints on that from me, that's perfectly OK if there's some need for IPs. > Some time ago, we did a clean-up of the old 44.130 packet-radio block in communication with the regional coordinators. > > What's with the portal? - I think we need discuss that. It had been no relevance for us (since no one requested it), and I'm not sure, how it fits in a concept of the country coordinator system (unless a country coordinator defines a do-what-you-want-netblock for self-allocation - but how this may be integrated in a working routing concept??). I think the portal would not work that good with a concept like the formerly used one with using the IP for granular routing over PR network. But I seem to remember discussions that the "routing feature" would not be needed any more and the whole german IP PR network should be seen as one big block (which I do not really support from my standpoint as sysadmin). > Region ofr.de (44.130.62.0/24) was resigned 2013-07-31. Regional Coordinator was DL1NAT. > The zone file of that region expired with serial 2004041601. Nine years after the last update. forward- and reverse- entries were inconsistent: the reverse file had the serial number 2002062201 (I assume 2 years before). > > I do not like to blame anyone, but it may be useful in that discussion. 9 (or 11) years after the last coordination of the subnet and 2.5 years after your regional coordinator stated that all records could be removed, you recognize that dg7nef, dg7nef-2 and dg7nef-gate ( 44.130.62.20, .18, .19) have been passed back. And that lead to my problem with portal.ampr.org as I still had my own local acting DNS serving as "Master" for the zone on requests from my network, so I could at least keep the IP adresses I did contact in a state that did work for me. Yes, split DNS and multiple masters are an ugly thing. But it did work locally then. > This emphasizes both, the difficulties we'll get, even years after a clean-up, and on the other site the need to have a clean-up (the /24 had 57 entries (22%) and we finally got one complain (Wolfgang had 3 addresses -> 5 %). For most cleaned subnets we got 0 responses at all). Well, in fact no complains from me so far, just a bit confusion on my side. ;) > And imho, it also shows the country- / regional-wide coordination concept makes sense. Currently, we've 35866 IN A records in ampr.org. Imagine we'll have 10 requests a day on the list of the pool of every user, we all will have to read the next 10 years about every individual issue.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net