44net

44net@mailman.ampr.org

3196 discussions

Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

I notice that more and more 44net traffic originates from addresses that are not registered in DNS. To identify an amateur radio transmission, it is required in most countries that the callsign is included in transmissions. Up to now I have considered traffic from a net44 address to be identified by the reverse name that can be looked up in DNS, and that has the basic structure of "hostname.callsign.ampr.org" (with of course some variations, but always the callsign of the responsible station is part of the name). I think everyone should be encouraged (or even required) to register all used addresses in DNS. There may have been some hurdles to do that in the past (e.g. the never completed DNS part of the portal, the unavoidable restrictions of the ampraddr robot to accept only updates from coordinators). Everyone who has e.g. a number of hosts in the 44.190 or other not nationally registered parts of the network can send a list of their IP addresses and corresponding hostnames (with names like the above, i.e. a callsign embedded in them) to me, then I can submit them to the robot and they get registered in the ampr.org main DNS service. Otherwise please register your hosts through your local coordinator, even when you have been allocated an entire subnet. Furthermore, I see that more and more subnets have arranged to delegate DNS to their own servers. I think it would have been better to keep everything in a single list and then run a secondary zone within the own network (we do that here), instead of this split. Maybe a more convenient API for updating the main DNS should be (or would have had to be) added to avoid this? Or are there other reasons for operating this way? Given that we now have this situation, I think there should be a general policy of allowing AXFR and preferably also IXFR zone-transfers of these zones between net44 addresses. We should not have "dark and secret" zones that are inaccessible to others, I think, especially for the reverse (PTR) zones. Rob

11 10

why and Wiki
by Dave Wade 17 Jun '20

17 Jun '20

Folks, Being marooned in that back water that is the UK I wonder what TCPIP packet activity there is in the UK and on what frequencies and how this would be supplemented by using 44net over the internet? I though I would read the Wiki but that seems to be un-availble.. Dave Wade G4UGM & EA7KAE

2 2

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>I'm replying to the main thread, as Rob still insists with posting using his >broken MUA which breaks threading, making it impossible to follow his >ramblings. Thanks Rob. It is not convenient for me either! But I don't want to forward this list as separate mails as sometimes there are frantic discussions about topics that do not interest me at all (like RPKI) and I don't want my mail bell to ring all day (and load amsat.org with forwarding all those messages). So I am subscribed to the digest only, I sometimes watch the archives for quicker responses, and I cannot reply with the proper threading. I think I have mentioned it before: this list should be a newsgroup on an NNTP server. If only to honor Brian Kantor. Accessing it via a usenet news reader would be so much more convenient, you can just read it when you like and kill uninteresting threads. Or otherwise just use a forum. >Having reverse DNS with a callsign in it doesn't meet identification >requirements in the ITU or FCC rules, assuming the packet is traversing an RF >link on amateur frequencies. Under FCC rules (and I'm aware you may be under >a different legal authority), the control operator is the required ID, not the >originator of the packet. It is not only about regulatory ID requirements but also about identifying who is behind some traffic. Many places have "relaxed firewall rules" for traffic originating from within AMPRnet. This already requires revision due to the sale of the upper block (I think that lots of firewall rules still mention 44.0.0.0/8) but also with more and more blocks being routed directly and having no transparency about the actual use of that space, I would like to know if some address is really an amateur or if someone has lend it out to shodan.io or stretchoid.com. And if so, at least know who is responsible for that. When that is not feasible, we will have to become more and more closed and more like the general internet (default drop everything). Rob

2 1

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>I am not sure what you mean by feared, but no, my allocations are not supporting the AMPRnet per se. If by AMPRnet you mean the legacy BBS style network of gateways and tunnels. I don't. With AMPRnet I mean what is described on the ARDC pages, not a set of applications and an old way to implement tunnels. So, the net44 address space and its use for amateur radio communications. Use for IRLP would be part of that. But in that case it should be possible to have reverse entries pointing to the callsigns involved. Rob

1 0

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 17 Jun '20

17 Jun '20

>The reason I did this was because I needed PTR records in something other than ampr.org. I already feared that it was to conceal non-AMPRnet usage... This makes it all the more important to have zone transfer capability so the data can be used to validate against local policies. Rob

3 2

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 16 Jun '20

16 Jun '20

>I manage my systems, and all the HamBSD systems, with Ansible. Some API >would need to be provided to allow me to check the current reverse DNS >record (in the database explicitly, not just by performing a DNS lookup >that may be influenced by caching etc.) and to update the record. I have that fully working using a collection of scripts, but indeed it would be convenient when there was an easier and more modern API for it. As it is now, you can download the zonefiles from an FTP server (or of course you can do lookups at the master server ampr.org at 44.0.0.1) and compile a list of updates (using diff between the downloaded- and the desired info) and then you can create an e-mail message to the ampraddr robot that will do the updates. For this to work you have to have your mail sender address whitelisted. (it used to be an open service until it was abused) Rob

1 0

Re: [44net] Reverse DNS and access to DNS info
by Rob Janssen 16 Jun '20

16 Jun '20

>On 16/06/2020 18:23, Rob Janssen via 44Net wrote: >>/Furthermore, I see that more and more subnets have arranged to delegate />>/DNS to their own servers. / >I had no idea this was an option. Who do I speak to to do this? It'd be >great to have actually up-to-date reverse DNS for my subnet. Why can't you submit updates to the main DNS server? What would be required for you to do so? Rob

4 3

VK AMPR Co-ordinator
by Gary B 14 Jun '20

14 Jun '20

Hi All, For info for those who knew Sam Scafe, VK4AA, who was the Australian AMPRnet Co-ordinator. SILENT KEY: - Samantha Scafe VK4AA Samantha went Silent Key on Saturday March 22nd at home in Cairns following complications from cellulitis interacting with a compromised respiratory system. Samantha had recently been in hospital a number of times but appeared to be improving before her health took a final dive. Samantha was one of the pioneers of Packet Radio networking in Queensland being one of the first to introduce the concept of data wormholes with the Aussie Wide Packet Radio Network. A move from the Gold Coast to Cairns found Samantha’s business become a ISP and Web Host/Design concern, including providing the backup site for the WIA News and QNEWS data files. Samantha and partner Colleen were also well known in autosports circles as CAMS Stewards, with many RadioAmateurs interacting with them at rallies and hillclimbs. Samantha also ran the Cairns APRS gateway for years and provided technical support for repeater builders around the country. The Australian Amateur Radio Service has suffered a great loss with Samantha’s passing and we pass on heartfelt condolences to partner Colleen and family. Vale Samantha Scafe VK4AA, Silent Key. >From Backscatter (Newsletter of the Townsville Amateur Radio Club) As a result, VK needs someone with AMPRnet and TCP/IP kwowledge and experience to volunteer to take on this role. If you think you are able to do this, or know someone who possibly could, please contact Chris, G1FEF asap. Currently VK does not have anyone to do the day to day co-ordination or issuance of 44. addresses. Regards, Gary VK4ZGB

7 6

ampr.org tls cert expired
by Scott Nicholas 13 Jun '20

13 Jun '20

Look's like the Let's Encrypt cert on ampr.org isn't running on a crontab :) -Scott

3 2

Re: [44net] NSP bugging me to use RPKI for my /24 grant
by Erik Seidel 12 Jun '20

12 Jun '20

Tom, It sounds like you're referring to delegated RPKI: https://www.arin.net/resources/manage/rpki/delegated/ I assume this could be done, but it would still have to be set up through ARIN first - just as in the case of hosted RPKI. Regards, Erik KE5SAI On Wed, Jun 10, 2020 at 11:26 AM Erik Seidel <erik(a)znsl.us> wrote: > > Tom, > > It sounds like you're referring to delegated RPKI: > > https://www.arin.net/resources/manage/rpki/delegated/ > > I assume this could be done, but it would still have to be set up > through ARIN first - just as in the case of hosted RPKI. > > Regards, > > Erik > KE5SAI > > On Wed, Jun 10, 2020 at 11:21 AM Tom Cardinal via 44Net > <44net(a)mailman.ampr.org> wrote: > > > > Cynthia, > > > > I only listed them as an example, my point was a having our own CA > > signed by a signing org that is trusted by RIRs. If that be ARIN then > > so be it. More importantly though, as you know, we have a legacy > > allocation. In my opinion we are equal to an RIR but with the ability > > to make global allocations from the 44.0/9 and 44.128/10 space. > > > > --ton/n2xu 44.98.63.0/29. > > > > > > On 6/10/20 7:38 AM, Cynthia Revström via 44Net wrote: > > > Tom, > > > > > > As Q already mentioned, Thawte or Comodo (now called Sectigo) are for Web > > > PKI, not RPKI, they have nothing to do with this. > > > And not to mention the huge requirements something like that would have, > > > and enormous fees. > > > > > > Not entirely sure what you mean by "act as an IR"? > > > > > >> They would have to accept it much like ARIN and RIPE trust each other > > > In the context of RPKI, ARIN and RIPE NCC do not trust each other, they > > > have their own Root CAs (TALs), which are independent of each other. > > > An RPKI validator has to use both of them. > > > > > > - Cynthia > > > > > > > > > On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net <44net(a)mailman.ampr.org> > > > wrote: > > > > > >> CA's like Thawte or Comodo won't work for this, they're for web PKI not > > >> resource PKI. > > >> The 44.0.0.0/9 cert would have to be signed by one of the RIR's trust > > >> anchors (probably ARIN since they have 44.0.0.0/8 assigned to them) > > >> > > >> Thanks, > > >> Q > > >> > > >> > > >> On Wed, 10 Jun 2020 at 13:28, Tom Cardinal via 44Net < > > >> 44net(a)mailman.ampr.org> > > >> wrote: > > >> > > >>> I've been monitoring this discussion. Since our space was allocated by > > >>> Jon Postel, initially around 1981 (ish), why can't we create our own > > >>> trust model (CA signed by a CA signing agency like Thawte or Comodo as > > >>> examples) and act as an IR for the 44.0/9 and 22.128/10 space ourselves > > >>> and publish that trust model to the RIRs? They would have to accept it > > >>> much like ARIN and RIPE trust each other. Then RPKI would work for > > >>> AMPRNet and AMPRNet would control it's own destiny. > > >>> > > >>> --tom/n2xu 44.98.62.0/29 > > >>> > > >>> > > >>> On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote: > > >>>> I can sympathize with the sentiment that RPKI and widespread RPKI > > >>>> adoption in its current form will really lock out and disenfranchise > > >>>> smaller network operators. > > >>>> > > >>>> Now, *more than ever*, we need to enable an Internet that any > > >>>> organization (a natural person, a registered entity, a hackerspace, > > >>>> etc.) can connect to, uniquely address itself, and begin exchanging > > >>>> traffic. > > >>>> > > >>>> In order to enable such an open system to function, we also need ways > > >>>> of ensuring that unicast addresses are unique and that there is some > > >>>> public, verifiable way of claiming ownership of IP space. Without > > >>>> this, the entire network is open to disruption and abuse by almost any > > >>>> operator. It's amazing we have gotten so far on the good will of most > > >>>> operators. > > >>>> > > >>>> The RIR model of lawyers, paperwork, and public databases works for a > > >>>> lot of people and organizations. IRR was the first step, but it was > > >>>> complex and a bit clunky to use. I see RPKI for Origin Validation as > > >>>> just the first/next step of extending this model of trust and > > >>>> numbering resource ownership into the routing protocol space more > > >>>> directly. > > >>>> From a technical standpoint, this logical extension of systems makes a > > >>>> lot of sense and I don't have a problem with it. > > >>>> > > >>>> For commercial network operators, a RIR registration is just the cost > > >>>> of doing business. > > >>>> But for many small nonprofits, regional amataur radio/network > > >>>> operators, or individuals, a few thousand dollars/euros a year is a > > >>>> lot of money that makes Internet independence out of reach. > > >>>> They end up having to resort to the hegemony of their local incumbent > > >>>> monopoly and chain themselves to the whims of their upstreams and > > >>>> regulators. > > >>>> > > >>>> I suspect many legacy resource holders find themselves in a similar > > >>>> limbo-state of not wanting to participate in the RIR model and pay > > >>>> money for essentially nothing. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Echoing some similar earlier sentiments to want to create a CA for > > >>>> legacy address holders: How feasible would it be to create something > > >>>> RIR-like, but noncommercial? > > >>>> A place for legacy address holders to coordinate and register > > >>>> resources seems like a natural fit. If we're going to operate a > > >>>> database of ROAs, we're going to need some database of address space > > >>>> ownership. > > >>>> For 44net use cases, this seems really straightforward, since we have > > >>>> the Portal to draw from. But for other organizations, it gets a bit > > >>>> more complicated to do properly. Given some random email > > >>>> address/account in some hypothetical legacy RIR, how can we really > > >>>> validate that they're authorized to take actions on behalf of some > > >>>> organization? > > >>>> To take some random examples from the IANA IPv4 list: DISA, USPS, > > >>>> AT&T, Apple, etc. Doing this right is going to take some process, > > >>>> record keeping, and well.... work. > > >>>> With this context, I can see how a lot of RIRs go commercial. However, > > >>>> with a bit of automation, good documentation and records, and some > > >>>> dedicated volunteers, this seems like a really doable/achievable thing > > >>>> in the netops community. > > >>>> > > >>>> I would be curious to know if anyone else shares these views/dreams > > >>>> and would like to chat about it. > > >>>> > > >>>> Stay safe and sane out there. > > >>>> > > >>>> Cheers, > > >>>> jof > > >>>> > > >>>> On Tue, 2 Jun 2020 at 08:18, Job Snijders via 44Net > > >>>> <44net(a)mailman.ampr.org> wrote: > > >>>>> Thomas, > > >>>>> > > >>>>> You say > > >>>>> > > >>>>> On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net > > >> wrote: > > >>>>>> DO NOT participate in RPKI! > > >>>>> And ... > > >>>>> > > >>>>>> We should be protecting our Internet!! Just saying... > > >>>>> What are you really saying? These statements seem at odds with each > > >>> other. > > >>>>> How do you protect your internet? Maybe I can learn some tricks from > > >>> you? > > >>>>> Kind regards, > > >>>>> > > >>>>> Job > > >>>>> _________________________________________ > > >>>>> 44Net mailing list > > >>>>> 44Net(a)mailman.ampr.org > > >>>>> https://mailman.ampr.org/mailman/listinfo/44net > > >>>> _________________________________________ > > >>>> 44Net mailing list > > >>>> 44Net(a)mailman.ampr.org > > >>>> https://mailman.ampr.org/mailman/listinfo/44net > > >>> > > >>> _________________________________________ > > >>> 44Net mailing list > > >>> 44Net(a)mailman.ampr.org > > >>> https://mailman.ampr.org/mailman/listinfo/44net > > >>> > > >> _________________________________________ > > >> 44Net mailing list > > >> 44Net(a)mailman.ampr.org > > >> https://mailman.ampr.org/mailman/listinfo/44net > > >> > > > _________________________________________ > > > 44Net mailing list > > > 44Net(a)mailman.ampr.org > > > https://mailman.ampr.org/mailman/listinfo/44net > > > > > > _________________________________________ > > 44Net mailing list > > 44Net(a)mailman.ampr.org > > https://mailman.ampr.org/mailman/listinfo/44net

7 8

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net