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
Hi,
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.
Thanks, Iain.
On 16 Jun 2020, at 18:29, Iain R. Learmonth via 44Net 44net@mailman.ampr.org wrote:
Hi,
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.
If you have a /24 or larger allocated and would like the reverse zone delegated to your own nameservers then by all means drop me an email. You will need a minimum of two nameservers already setup to answer to PTR records within your allocation before I can get the delegation completed.
Trust is the key here: if you’re using your allocation for something other than RF links then (so long as it’s ham related and not commercial of course) you can use whatever domain name you want in your forward and reverse zones. Some countries *require* that you identify any RF transmissions and in those cases the holder of the allocation is responsible for ensuring suitable identification is configured into your DNS setup if not using the ampr.org http://ampr.org/ and it’s reverse.
73, Chris - G1FEF
On Tue, Jun 16, 2020 at 8:41 PM G1FEF via 44Net 44net@mailman.ampr.org wrote:
On 16 Jun 2020, at 18:29, Iain R. Learmonth via 44Net 44net@mailman.ampr.org wrote:
Hi,
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.
If you have a /24 or larger allocated and would like the reverse zone delegated to your own nameservers then by all means drop me an email. You will need a minimum of two nameservers already setup to answer to PTR records within your allocation before I can get the delegation completed.
We do exactly this for our local repeater group site which works well. We have a /24 which I arranged via Chris, our own RIPE public ASN, BGP 2x1G transit from an on-site ISP. Then asked for the /24 DNS to be delegated to our domain providers DNS servers, so we can use their simple control panel to update records instantly.
All our hosts are with-in our own treffgarne.org zone, so we can manage ourselves without waiting on others.
Photo of our install featuring our DMR repeater, APRS iGate / digipeater, BGP router, IP PDU and UPS. https://twitter.com/treffgarnegroup/status/1140215534056812545/photo/1
@ 3600 NS ns0.portfast.net. @ 3600 NS ns1.portfast.net. @ 3600 NS ns2.portfast.net.uk. 1 3600 PTR router1.treffgarne.org. 25 3600 PTR router1.treffgarne.org. 26 3600 PTR dhcp26.treffgarne.org. 27 3600 PTR dhcp27.treffgarne.org. 28 3600 PTR dhcp28.treffgarne.org. 29 3600 PTR dhcp29.treffgarne.org. 30 3600 PTR dhcp30.treffgarne.org. 65 3600 PTR router1.treffgarne.org. 66 3600 PTR ups1.treffgarne.org. 67 3600 PTR pdu1.treffgarne.org. 81 3600 PTR router1.treffgarne.org. 82 3600 PTR gb7dp.treffgarne.org. 83 3600 PTR mb7uy.treffgarne.org.
We plan to add POCSAG in the near future.
The DHCP pool is for when repeater group members are onsite and connected locally via an ethernet cable. I don't think we are breaking any policies by doing things in this way.
Kind regards,
Nat,
-- Nat
https://nat.ms +44 7531 750292
Looking at Nats config, that is a pretty tidy configuration which makes more sense than everyone having to call sign.amprnet.org.
Sensible naming is key to all this as having a ton of all being like 2e0emo.amprnet.net makes it harder to identify past the call sign.
Oh POCSAG that could be quiet cool there a few us in the UK looking at more packet radio like it on a discord server
73's
2E0EMO
On Wed, 17 Jun 2020 at 11:06, Nat Morris via 44Net 44net@mailman.ampr.org wrote:
On Tue, Jun 16, 2020 at 8:41 PM G1FEF via 44Net 44net@mailman.ampr.org wrote:
On 16 Jun 2020, at 18:29, Iain R. Learmonth via 44Net <
44net@mailman.ampr.org> wrote:
Hi,
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.
If you have a /24 or larger allocated and would like the reverse zone
delegated to your own nameservers then by all means drop me an email. You will need a minimum of two nameservers already setup to answer to PTR records within your allocation before I can get the delegation completed.
We do exactly this for our local repeater group site which works well. We have a /24 which I arranged via Chris, our own RIPE public ASN, BGP 2x1G transit from an on-site ISP. Then asked for the /24 DNS to be delegated to our domain providers DNS servers, so we can use their simple control panel to update records instantly.
All our hosts are with-in our own treffgarne.org zone, so we can manage ourselves without waiting on others.
Photo of our install featuring our DMR repeater, APRS iGate / digipeater, BGP router, IP PDU and UPS. https://twitter.com/treffgarnegroup/status/1140215534056812545/photo/1
@ 3600 NS ns0.portfast.net. @ 3600 NS ns1.portfast.net. @ 3600 NS ns2.portfast.net.uk. 1 3600 PTR router1.treffgarne.org. 25 3600 PTR router1.treffgarne.org. 26 3600 PTR dhcp26.treffgarne.org. 27 3600 PTR dhcp27.treffgarne.org. 28 3600 PTR dhcp28.treffgarne.org. 29 3600 PTR dhcp29.treffgarne.org. 30 3600 PTR dhcp30.treffgarne.org. 65 3600 PTR router1.treffgarne.org. 66 3600 PTR ups1.treffgarne.org. 67 3600 PTR pdu1.treffgarne.org. 81 3600 PTR router1.treffgarne.org. 82 3600 PTR gb7dp.treffgarne.org. 83 3600 PTR mb7uy.treffgarne.org.
We plan to add POCSAG in the near future.
The DHCP pool is for when repeater group members are onsite and connected locally via an ethernet cable. I don't think we are breaking any policies by doing things in this way.
Kind regards,
Nat,
-- Nat
https://nat.ms +44 7531 750292
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
What can be simpler than (in somewhat reverse order):
.ampr.org [where we hams derive our allocations] .n2nov [who is responsible for this IP address] gw [purpose of this IP address]
44.68.41.2 = gw.n2nov.ampr.org
Email servers for instance need to be on addresses with a reverse DNS pointing to the same name. To fight a spam, otherwise won't be accepted by majority of other email servers.
How can we achieve something like this?
mail44.hamradio.si 44.150.0.10 44.150.0.10 mail44.hamradio.si
73 de Janko S57NK
Charles J. Hargrove via 44Net je 17. 06. 20 ob 14:38 napisal:
What can be simpler than (in somewhat reverse order):
.ampr.org [where we hams derive our allocations] .n2nov [who is responsible for this IP address] gw [purpose of this IP address]
44.68.41.2 = gw.n2nov.ampr.org
I just received my allocation yesterday so I am brand new to ampr. I can't seem to connect to the wiki to see if there's a description of the DNS architecture so some of this may be obvious to everyone else.
Some of the internet providers I have worked with in the past deal with this issue at the time of initial allocation. One idea to insure regulatory compliance would be to automatically generate the A and PTR records for all addresses allocated. The automatically generated A record name could include the callsign perhaps with a text representation of the IP address, just as Rob described. For usability purposes, CNAME records can be maintained so that the operator can utilize whatever name they prefer for their applications. You could theoretically store the CNAMEs in subdomains to help ease administration burden.
Bill
On Jun 16, 2020, at 13:23, Rob Janssen via 44Net 44net@mailman.ampr.org wrote: 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?
The reason I did this was because I needed PTR records in something other than ampr.org. Even my own nameserver needed to be in my own domain. Lookup 44.48.24.44 or 44.136.33.1. If the robot could provide names not necessarily in ampr.org, I could have lived with that. Although it is still far easier for me to manage my allocations on my own machines.
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.
On 6/16/20 1:23 PM, Rob Janssen via 44Net wrote:
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).
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.
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).
What is the problem you're seeking to solve if it's not legal identification of transmissions?
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.
DNS NS records handle this now. When you allocate a /24, your name servers are setup to handle x.190.44.in-addr.arpa. This works and works well requiring no manual or non-standard software. DNSSEC could be added to secure it if needed.
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.
What does this solve? If you have evidence of non-ham use of 44net space, email the ARDC board. AFIK there is no procedure to report this.
Allowing you to have a copy of my zone file isn't going to fix it. I can just use CNAME records and jump to another domain. Should I be forced to give AXFR access to any CNAME domains too? I can't do this for a number of services and services in my hamcolo, as everyone has control over their own reverse dns. (side bar, if anyone needs a VM for something ping me offlist.)
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.
Again, this is non-standard and doesn't add any functionality over and above reverse DNS. If you want to see who is responsible for an IP in 44net, you can use the portal or rwhois.
These proposals are asking DNS to do something it's not designed for. There is also the need for a procedure regarding what to do when a person suspects non-ham use of 44net by a licensee. Defining what would constituent this use is going to be hard, and then what would be acceptable proof of it. There would need to be clear and public proceeding to enforce this as well.
73s
On 17/06/20 03:23, Rob Janssen via 44Net wrote:
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).
Hmm, I've been more inclined to consider something transmitted directly by MY station as the important legal identifier - e.g. AX.25 origin callsign, and for the 44.190.x.x subnet, there's no legal requirement, since that's technically not on the air.
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).
I have no issues with any DNS registrations per se, but I do find the current process of going through a coordinator to be a major barrier. I tend to be someone eho takes a few goes at getting things right, then leaving them for a lengthy period of time, until the next significant upgrades.
But the current process is not really helpful to me. It's the same reason I never got into DXing - the paperwork and processes (with QSL cards in that example). :)
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.
That I would have to generate automatically, there's a LOT! (at least 200), though they are pretty generic
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?
I would find operating with my own DNS servers much easier, it's the administrative overhead that's the barrier, and besides everywhere else, I am in control of my own DNS, even when running on someone else's servers (except for IPv4 reverse, because I don't control those address spaces).
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.
Hmm, there's a difference between delegation and "dark and secret". This seems to conflate the two. :/