16 Jun
2020
16 Jun
'20
1:23 p.m.
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
16 Jun
16 Jun
1:29 p.m.
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.
--
https://hambsd.org/
3:40 p.m.
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
17 Jun
17 Jun
6:05 a.m.
On Tue, Jun 16, 2020 at 8:41 PM G1FEF via 44Net <44net(a)mailman.ampr.org> wrote:
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
8:17 a.m.
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(a)mailman.ampr.org>
wrote:
8:38 a.m.
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
--
Charles J. Hargrove - N2NOV
NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Nets 441.100/136.5 PL
ARnewsline Broadcast Mon. @ 8:00PM
NYC-ARECS Weekly Net Mon. @ 8:30PM
http://www.nyc-arecs.org
NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM
on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32
"Information is the oxygen of the modern age. It seeps through the walls
topped
by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying
(The work praises the man.)
"No matter how big and powerful government gets, and the many services it
provides, it can never take the place of volunteers." - Ronald Reagan
8:59 a.m.
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:
16 Jun
16 Jun
1:53 p.m.
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
2:09 p.m.
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.
--
Dave, K9DC
Indianapolis, Indiana USA
6:48 p.m.
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:
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.
What is the problem you're seeking to solve if it's not legal identification
of transmissions?
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.
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.)
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
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
17 Jun
17 Jun
12:20 a.m.
On 17/06/20 03:23, Rob Janssen via 44Net wrote:
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 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). :)
That I would have to generate automatically, there's a LOT! (at least
200), though they are pretty generic
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).
Hmm, there's a difference between delegation and "dark and
secret".
This seems to conflate the two. :/
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
1803
days inactive
1804
days old
10 comments
11 participants
participants (11)
-
Bryan Fields -
Charles J. Hargrove -
Dave Gingrich -
G1FEF -
Iain R. Learmonth -
Janko Mivšek -
Mitchell Southgate -
Nat Morris -
Rob Janssen -
Tony Langdon -
W4RFC