I'm not seeing any changes to the RIP broadcasts (seems to be stuck at 843 lines for last couple of days).
Also can't download encap file from portal.ampr.org/api/v1/encap (should existing API key still work?)
Max
G4FDL
Thank you for bringing this to our attention. These functionalities are not online yet, and we are working in the interim to enable this functionality.
Thanks,
Rebecca KO4KVG
On 4/8/24 7:46 AM, metwo2--- via 44net wrote:
I'm not seeing any changes to the RIP broadcasts (seems to be stuck at 843 lines for last couple of days).
Also can't download encap file from portal.ampr.org/api/v1/encap (should existing API key still work?)
Max
G4FDL _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
I don't understand what you mean here Rebecca. Are you saying that as part of the portal overhaul, the management and prefix routing advertisements via the RIP routing is *known broken*? If so, why is this being done this way? The rollout of any new system shouldn't be done until it's feature complete and has been tested regardless if this is being done by volunteers or payed employees.
--David KI6ZHD
On 04/08/2024 10:52 AM, Rebecca Key via 44net wrote:
Thank you for bringing this to our attention. These functionalities are not online yet, and we are working in the interim to enable this functionality.
Thanks,
Rebecca KO4KVG
On 4/8/24 7:46 AM, metwo2--- via 44net wrote:
I'm not seeing any changes to the RIP broadcasts (seems to be stuck at 843 lines for last couple of days).
Also can't download encap file from portal.ampr.org/api/v1/encap (should existing API key still work?)
Max
G4FDL _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
+1
On 4/8/2024 3:36 PM, David Ranch via 44net wrote:
I don't understand what you mean here Rebecca. Are you saying that as part of the portal overhaul, the management and prefix routing advertisements via the RIP routing is *known broken*? If so, why is this being done this way? The rollout of any new system shouldn't be done until it's feature complete and has been tested regardless if this is being done by volunteers or payed employees.
--David KI6ZHD
On 04/08/2024 10:52 AM, Rebecca Key via 44net wrote:
Thank you for bringing this to our attention. These functionalities are not online yet, and we are working in the interim to enable this functionality.
Thanks,
Rebecca KO4KVG
On 4/8/24 7:46 AM, metwo2--- via 44net wrote:
I'm not seeing any changes to the RIP broadcasts (seems to be stuck at 843 lines for last couple of days).
Also can't download encap file from portal.ampr.org/api/v1/encap (should existing API key still work?)
Max
G4FDL
Let’s not forget that at the end of day “It’s just a hobby”.
Neil
On Mon, Apr 8, 2024, at 3:39 PM, Charles Hargrove via 44net wrote:
+1
On 4/8/2024 3:36 PM, David Ranch via 44net wrote:
I don't understand what you mean here Rebecca. Are you saying that as part of the portal overhaul, the management and prefix routing advertisements via the RIP routing is *known broken*? If so, why is this being done this way? The rollout of any new system shouldn't be done until it's feature complete and has been tested regardless if this is being done by volunteers or payed employees.
--David KI6ZHD
On 04/08/2024 10:52 AM, Rebecca Key via 44net wrote:
Thank you for bringing this to our attention. These functionalities are not online yet, and we are working in the interim to enable this functionality.
Thanks,
Rebecca KO4KVG
On 4/8/24 7:46 AM, metwo2--- via 44net wrote:
I'm not seeing any changes to the RIP broadcasts (seems to be stuck at 843 lines for last couple of days).
Also can't download encap file from portal.ampr.org/api/v1/encap (should existing API key still work?)
Max
G4FDL
-- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
44net Coordinator - Northeast USA
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 _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
The new portal has been tested quite thoroughly in a lab environment with dummy data. Now it’s live we want to make sure we don't break anything, so we are testing with the live data and enabling things as and when we are confident they are functioning correctly. So far we have found a few minor issues that have been fixed and I can confirm that the encap feed to the gateway server at UCSD is all working as it should with updates now being pushed once an hour.
As I am sure you can appreciate we could only simulate this until we went live with the new portal. To ensure nothing got broke, i.e. the entire IPIP mesh taken down, we paused the RIP updates until testing confirmed the new feed was working satisfactorily. I’m sure you all appreciate this methodical approach and I am also sure that the RIP updates getting paused for a little while will not have caused any problems, as Neil said: “It’s just a hobby” - HI
To confirm, RIP updates are now unpaused and will be populated once an hour from data in the new portal.
If anyone finds any anomalies please email newportal@ardc.net mailto:newportal@ardc.net with as much detail as you can about the issue you are seeing.
Thanks for your patience.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 8 Apr 2024, at 20:44, Neil Johnson via 44net 44net@mailman.ampr.org wrote:
Let’s not forget that at the end of day “It’s just a hobby”.
Neil
On Mon, Apr 8, 2024, at 3:39 PM, Charles Hargrove via 44net wrote:
+1
On 4/8/2024 3:36 PM, David Ranch via 44net wrote:
I don't understand what you mean here Rebecca. Are you saying that as part of the portal overhaul, the management and prefix routing advertisements via the RIP routing is *known broken*? If so, why is this being done this way? The rollout of any new system shouldn't be done until it's feature complete and has been tested regardless if this is being done by volunteers or payed employees.
--David KI6ZHD
On 04/08/2024 10:52 AM, Rebecca Key via 44net wrote:
Thank you for bringing this to our attention. These functionalities are not online yet, and we are working in the interim to enable this functionality.
Thanks,
Rebecca KO4KVG
On 4/8/24 7:46 AM, metwo2--- via 44net wrote:
I'm not seeing any changes to the RIP broadcasts (seems to be stuck at 843 lines for last couple of days).
Also can't download encap file from portal.ampr.org/api/v1/encap http://portal.ampr.org/api/v1/encap (should existing API key still work?)
Max
G4FDL
-- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
44net Coordinator - Northeast USA
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 _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org
-- Neil Johnson
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org
While this all may be true and thought to be the best method to pursue, when will the coordinators get unfettered access to the portal to at least the same level that we had before Wednesday? We can't even access setting up new gateways or allocations. Our level of "trust" may be too low. :(
On 4/8/2024 5:47 PM, Chris via 44net wrote:
The new portal has been tested quite thoroughly in a lab environment with dummy data. Now it’s live we want to make sure we don't break anything, so we are testing with the live data and enabling things as and when we are confident they are functioning correctly. So far we have found a few minor issues that have been fixed and I can confirm that the encap feed to the gateway server at UCSD is all working as it should with updates now being pushed once an hour.
As I am sure you can appreciate we could only simulate this until we went live with the new portal. To ensure nothing got broke, i.e. the entire IPIP mesh taken down, we paused the RIP updates until testing confirmed the new feed was working satisfactorily. I’m sure you all appreciate this methodical approach and I am also sure that the RIP updates getting paused for a little while will not have caused any problems, as Neil said: “It’s just a hobby” - HI
To confirm, RIP updates are now unpaused and will be populated once an hour from data in the new portal.
If anyone finds any anomalies please email newportal@ardc.net mailto:newportal@ardc.net with as much detail as you can about the issue you are seeing.
Thanks for your patience.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 8 Apr 2024, at 20:44, Neil Johnson via 44net 44net@mailman.ampr.org wrote:
Let’s not forget that at the end of day “It’s just a hobby”.
Neil
On Mon, Apr 8, 2024, at 3:39 PM, Charles Hargrove via 44net wrote:
+1
On 4/8/2024 3:36 PM, David Ranch via 44net wrote:
I don't understand what you mean here Rebecca. Are you saying that as part of the portal overhaul, the management and prefix routing advertisements via the RIP routing is *known broken*? If so, why is this being done this way? The rollout of any new system shouldn't be done until it's feature complete and has been tested regardless if
this
is being done by volunteers or payed employees.
--David KI6ZHD
On 04/08/2024 10:52 AM, Rebecca Key via 44net wrote:
Thank you for bringing this to our attention. These functionalities are not online yet, and we are working in the interim to enable this functionality.
Thanks,
Rebecca KO4KVG
On 4/8/24 7:46 AM, metwo2--- via 44net wrote:
I'm not seeing any changes to the RIP broadcasts (seems to be
stuck at
843 lines for last couple of days).
Also can't download encap file from portal.ampr.org/api/v1/encap
http://portal.ampr.org/api/v1/encap(should
existing API key still work?)
Max
G4FDL
Hi Charles,
We expect everything to be fully functional by the end of this week.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 8 Apr 2024, at 23:24, Charles Hargrove via 44net 44net@mailman.ampr.org wrote:
While this all may be true and thought to be the best method to pursue, when will the coordinators get unfettered access to the portal to at least the same level that we had before Wednesday? We can't even access setting up new gateways or allocations. Our level of "trust" may be too low. :(
On 4/8/2024 5:47 PM, Chris via 44net wrote:
The new portal has been tested quite thoroughly in a lab environment with dummy data. Now it’s live we want to make sure we don't break anything, so we are testing with the live data and enabling things as and when we are confident they are functioning correctly. So far we have found a few minor issues that have been fixed and I can confirm that the encap feed to the gateway server at UCSD is all working as it should with updates now being pushed once an hour. As I am sure you can appreciate we could only simulate this until we went live with the new portal. To ensure nothing got broke, i.e. the entire IPIP mesh taken down, we paused the RIP updates until testing confirmed the new feed was working satisfactorily. I’m sure you all appreciate this methodical approach and I am also sure that the RIP updates getting paused for a little while will not have caused any problems, as Neil said: “It’s just a hobby” - HI To confirm, RIP updates are now unpaused and will be populated once an hour from data in the new portal. If anyone finds any anomalies please email newportal@ardc.net mailto:newportal@ardc.net with as much detail as you can about the issue you are seeing. Thanks for your patience. 73, Chris - G1FEF — ARDC Administrator Web: https://www.ardc.net
On 8 Apr 2024, at 20:44, Neil Johnson via 44net 44net@mailman.ampr.org wrote:
Let’s not forget that at the end of day “It’s just a hobby”.
Neil
On Mon, Apr 8, 2024, at 3:39 PM, Charles Hargrove via 44net wrote:
+1
On 4/8/2024 3:36 PM, David Ranch via 44net wrote:
I don't understand what you mean here Rebecca. Are you saying that as part of the portal overhaul, the management and prefix routing advertisements via the RIP routing is *known broken*? If so, why is this being done this way? The rollout of any new system shouldn't be done until it's feature complete and has been tested regardless if this is being done by volunteers or payed employees.
--David KI6ZHD
On 04/08/2024 10:52 AM, Rebecca Key via 44net wrote:
Thank you for bringing this to our attention. These functionalities are not online yet, and we are working in the interim to enable this functionality.
Thanks,
Rebecca KO4KVG
On 4/8/24 7:46 AM, metwo2--- via 44net wrote: > I'm not seeing any changes to the RIP broadcasts (seems to be stuck at > 843 lines for last couple of days). > > Also can't download encap file from portal.ampr.org/api/v1/encap http://portal.ampr.org/api/v1/encap(should > existing API key still work?) > > Max > > G4FDL
-- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
44net Coordinator - Northeast USA
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 _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
On 4/8/2024 3:36 PM, David Ranch via 44net wrote:
I don't understand what you mean here Rebecca. Are you saying that as part of the portal overhaul, the management and prefix routing advertisements via the RIP routing is *known broken*? If so, why is this being done this way? The rollout of any new system shouldn't be done until it's feature complete and has been tested regardless if this is being done by volunteers or payed employees.
--David KI6ZHD
On 04/08/2024 10:52 AM, Rebecca Key via 44net wrote:
Thank you for bringing this to our attention. These functionalities are not online yet, and we are working in the interim to enable this functionality.
Thanks,
Rebecca KO4KVG
On 4/8/24 7:46 AM, metwo2--- via 44net wrote:
I'm not seeing any changes to the RIP broadcasts (seems to be stuck at 843 lines for last couple of days).
Also can't download encap file from portal.ampr.org/api/v1/encap (should existing API key still work?)
Max
G4FDL
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles?
There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
Thanks, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net https://www.ardc.net/
On 4/8/2024 3:36 PM, David Ranch via 44net wrote:
I don't understand what you mean here Rebecca. Are you saying that as part of the portal overhaul, the management and prefix routing advertisements via the RIP routing is *known broken*? If so, why is this being done this way? The rollout of any new system shouldn't be done until it's feature complete and has been tested regardless if this is being done by volunteers or payed employees. --David KI6ZHD On 04/08/2024 10:52 AM, Rebecca Key via 44net wrote:
Thank you for bringing this to our attention. These functionalities are not online yet, and we are working in the interim to enable this functionality.
Thanks,
Rebecca KO4KVG
On 4/8/24 7:46 AM, metwo2--- via 44net wrote:
I'm not seeing any changes to the RIP broadcasts (seems to be stuck at 843 lines for last couple of days).
Also can't download encap file from portal.ampr.org/api/v1/encap (should existing API key still work?)
Max
G4FDL
-- 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 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 _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles?
There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please?
Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
-- 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
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote:
The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please?
Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
That makes sense, the gateway server at UCSD is no longer running a DNS server.
We have four authoritative nameservers now:
ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net
None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10
We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point.
73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
-- 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
Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server.
We have four authoritative nameservers now:
ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net
None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10
We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point.
73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
> On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
In case it is of use to anyone you can also get NTP time from ns.ardc.net http://ns.ardc.net/ if you are on any 44Net IP. It is a stratum 2 server.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote:
Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
>> On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote: > > Has anyone noticed anything strange with encap routing and DNS entries since 4/10? Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
-- 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
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well. If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1. --- Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
You should update to use ns.ardc.net http://ns.ardc.net/ as your time source.
All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote:
I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well.
If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1.
Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 AXFR for AMPR.ORG works AXFR 44.in-addr.arpa does NOT work AXFR for 68.44.in-addr.arpa works I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
Should I also be adding 128.44.in-addr.arpa? May I receive all the [verified] parameters on your part?
73,
Lynwood KB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net http://ns.ardc.net/ if you are on any 44Net IP. It is a stratum 2 server.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote:
Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
> On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote: >>> On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote: >> >> Has anyone noticed anything strange with encap routing and DNS entries since 4/10? > Can you be a little more specific Charles? > There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
-- 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
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Chris,
A.) Please verify your new zones are:
- 0.44.in-addr.arpa - 68.44.in-addr.arpa - 128.44.in-addr.arpa
B.) Testing the command 'dig AXFR ampr.org @44.1.1.44'
- Works from SRC IP 44.60.44.128 - DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd: user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data.From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms D.) I noticed the high ping, is this server at UCSD or elsewhere? E.) I've updated my NTP configuration as well.
--- - Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net as your time source. All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote: I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well. If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1. --- Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
This is a prefix for NY State that I manage.
- 68.44.in-addr.arpa
Charles,
In this case, I'm referencing to Chris the "significant notation" needed for specifying/configuring the Reverse DNS Zones for AMPRNet's PTR Records. The network you mentioned just happens to be at the beginning of that range. I may be mistaken (which as it's been years since I had to reconfigure an infrastructure DNS server) - so I wanted Chris to verify the list reflected his configuration.
It previously was a complete zone named '44.in-addr.arpa', but has been subdivided after the sale of the bottom portion of the network.
73,
LynwoodKB3VWG
On Sunday, April 21, 2024 at 08:07:22 PM EDT, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
This is a prefix for NY State that I manage.
* 68.44.in-addr.arpa
Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS? I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
- Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided - Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old. If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
--- 73,
- LynwoodKB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
- 0.44.in-addr.arpa - 68.44.in-addr.arpa - 128.44.in-addr.arpa
B.) Testing the command 'dig AXFR ampr.org @44.1.1.44'
- Works from SRC IP 44.60.44.128 - DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd: user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data.From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms D.) I noticed the high ping, is this server at UCSD or elsewhere? E.) I've updated my NTP configuration as well.
--- - Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net as your time source. All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote: I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well. If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1. --- Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
Hi Lynwood,
Yes, I am the right person, I will email you off list so we can discuss.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 23 Apr 2024, at 13:17, lleachii@aol.com wrote:
Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS?
I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l -rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev
user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44 ;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old.
If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
73,
- Lynwood
KB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
0.44.in-addr.arpa 68.44.in-addr.arpa 128.44.in-addr.arpa
B.) Testing the command
'dig AXFR ampr.org @44.1.1.44'Works from SRC IP 44.60.44.128 DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd:
user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3 PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data. From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable 64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms 64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms
D.) I noticed the high ping, is this server at UCSD or elsewhere?
E.) I've updated my NTP configuration as well.
- Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net http://ns.ardc.net/ as your time source.
All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote:
I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well.
If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1.
Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 AXFR for AMPR.ORG works AXFR 44.in-addr.arpa does NOT work AXFR for 68.44.in-addr.arpa works I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
Should I also be adding 128.44.in-addr.arpa? May I receive all the [verified] parameters on your part?
73,
Lynwood KB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net http://ns.ardc.net/ if you are on any 44Net IP. It is a stratum 2 server.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote:
Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris >> On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote: > > AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. > Either something is wrong with it or it has been moved without > us being notified. > > On 4/19/2024 2:30 PM, Chris wrote: >>>> On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote: >>> >>> Has anyone noticed anything strange with encap routing and DNS entries since 4/10? >> Can you be a little more specific Charles? >> There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
-- 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
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Chris,
I wanted to thank you for your support and patience.
It ended up being firewall rule (that never affected the old 44.0.0.1 master configuration) - that prevented my server from initiating traffic bound for AMPRNet. I also wanted to publicly apologize. I'll email you off-reflector with more details.
Public Kudos to you!!
- LynwoodKB3VWG
On Tuesday, April 23, 2024 at 09:06:32 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood, Yes, I am the right person, I will email you off list so we can discuss. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 23 Apr 2024, at 13:17, lleachii@aol.com wrote: Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS? I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
- Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided - Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old. If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
--- 73,
- LynwoodKB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
- 0.44.in-addr.arpa - 68.44.in-addr.arpa - 128.44.in-addr.arpa
B.) Testing the command 'dig AXFR ampr.org @44.1.1.44'
- Works from SRC IP 44.60.44.128 - DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd: user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data.From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms D.) I noticed the high ping, is this server at UCSD or elsewhere? E.) I've updated my NTP configuration as well.
--- - Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net as your time source. All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote: I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well. If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1. --- Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
All,
44.60.44.3 is now up-to-date and as always, available as a recursive (client) DNS server that can be configured in AMPRNet hosts/clients.
user@dns-mdc:~$ ls /var/lib/bind -l-rw-r--r-- 1 bind bind 281 Apr 23 20:34 0.44.rev-rw-r--r-- 1 bind bind 227 Apr 23 19:30 128.44.rev-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 44.rev.old-rw-r--r-- 1 bind bind 14187 Apr 23 19:33 68.44.rev-rw-r--r-- 1 bind bind 2584957 Apr 23 20:50 ampr.org.hosts-rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 ampr.org.hosts.old
73,
LynwoodKB3VWG
On Tuesday, April 23, 2024 at 03:42:38 PM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Chris,
I wanted to thank you for your support and patience.
It ended up being firewall rule (that never affected the old 44.0.0.1 master configuration) - that prevented my server from initiating traffic bound for AMPRNet. I also wanted to publicly apologize. I'll email you off-reflector with more details.
Public Kudos to you!!
- LynwoodKB3VWG
On Tuesday, April 23, 2024 at 09:06:32 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood, Yes, I am the right person, I will email you off list so we can discuss. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 23 Apr 2024, at 13:17, lleachii@aol.com wrote: Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS? I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
- Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided - Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old. If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
--- 73,
- LynwoodKB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
- 0.44.in-addr.arpa - 68.44.in-addr.arpa - 128.44.in-addr.arpa
B.) Testing the command 'dig AXFR ampr.org @44.1.1.44'
- Works from SRC IP 44.60.44.128 - DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd: user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data.From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms D.) I noticed the high ping, is this server at UCSD or elsewhere? E.) I've updated my NTP configuration as well.
--- - Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net as your time source. All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote: I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well. If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1. --- Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
To Operators/Clubs/Coordinators/Trustees/National Amateur Societies/etc. with delegated AMPRNet /16 Subnets:
Greetings. Time has passed - I've needed to urgently communicate with you. I awaited clarity and verification regarding DNS from the New ARDC regime and Administrator (B.Kantor, SK was the last ARDC Admin I worked with before Chris - that was before 44/8 was subdivided). If you do not do so at this time:
- Please allow AXFR for AMPRNet SRC IPs for your x.44.in-addr.arpa Master DNS from 44.0.0.0/9 and 44.128.0.0/10 - If you cannot do so, in the coming days/weeks, I will directly locate you/your server operator and request access for 44.60.44.3 to AXFR via any means of WHOIS/contact in DNS responses/IP's via RIR/ARIN or AMPRPortal/etc. - I can also coordinate with you to use a.) an IPv6 SRC address, b.) my IPENCAP tunnel using other DST addressing, or c.) a Wireguard tunnel instead Those who already allow AXFR per RFC at this time, my sincere appreciation and thanks. I would like to ensure I have a East Coast US DNS copy of the ALL 44.0/9 and 44.128/10 network PTR Records.
Thanks and 73,
Lynwood - KB3VWGMaintainer of 44.60.44.3 (dns-mdc.ampr.org)
On Tuesday, April 23, 2024 at 05:25:51 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
All,
44.60.44.3 is now up-to-date and as always, available as a recursive (client) DNS server that can be configured in AMPRNet hosts/clients.
user@dns-mdc:~$ ls /var/lib/bind -l-rw-r--r-- 1 bind bind 281 Apr 23 20:34 0.44.rev-rw-r--r-- 1 bind bind 227 Apr 23 19:30 128.44.rev-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 44.rev.old-rw-r--r-- 1 bind bind 14187 Apr 23 19:33 68.44.rev-rw-r--r-- 1 bind bind 2584957 Apr 23 20:50 ampr.org.hosts-rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 ampr.org.hosts.old
73,
LynwoodKB3VWG
On Tuesday, April 23, 2024 at 03:42:38 PM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Chris,
I wanted to thank you for your support and patience.
It ended up being firewall rule (that never affected the old 44.0.0.1 master configuration) - that prevented my server from initiating traffic bound for AMPRNet. I also wanted to publicly apologize. I'll email you off-reflector with more details.
Public Kudos to you!!
- LynwoodKB3VWG
On Tuesday, April 23, 2024 at 09:06:32 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood, Yes, I am the right person, I will email you off list so we can discuss. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 23 Apr 2024, at 13:17, lleachii@aol.com wrote: Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS? I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
- Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided - Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old. If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
--- 73,
- LynwoodKB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
- 0.44.in-addr.arpa - 68.44.in-addr.arpa - 128.44.in-addr.arpa
B.) Testing the command 'dig AXFR ampr.org @44.1.1.44'
- Works from SRC IP 44.60.44.128 - DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd: user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data.From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms D.) I noticed the high ping, is this server at UCSD or elsewhere? E.) I've updated my NTP configuration as well.
--- - Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net as your time source. All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote: I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well. If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1. --- Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
FYI, there is already an east coast US authoritative DNS server: ns2.us.ardc.net http://ns2.us.ardc.net/
There is also one in Germany: ns1.de.ardc.net http://ns1.de.ardc.net/
and one in the UK: a.gw4.uk http://a.gw4.uk/
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 14:09, lleachii--- via 44net 44net@mailman.ampr.org wrote:
To Operators/Clubs/Coordinators/Trustees/National Amateur Societies/etc. with delegated AMPRNet /16 Subnets:
Greetings. Time has passed - I've needed to urgently communicate with you. I awaited clarity and verification regarding DNS from the New ARDC regime and Administrator (B.Kantor, SK was the last ARDC Admin I worked with before Chris - that was before 44/8 was subdivided).
If you do not do so at this time:
Please allow AXFR for AMPRNet SRC IPs for your x.44.in-addr.arpa Master DNS from 44.0.0.0/9 and 44.128.0.0/10 If you cannot do so, in the coming days/weeks, I will directly locate you/your server operator and request access for 44.60.44.3 to AXFR via any means of WHOIS/contact in DNS responses/IP's via RIR/ARIN or AMPRPortal/etc. I can also coordinate with you to use a.) an IPv6 SRC address, b.) my IPENCAP tunnel using other DST addressing, or c.) a Wireguard tunnel instead Those who already allow AXFR per RFC at this time, my sincere appreciation and thanks.
I would like to ensure I have a East Coast US DNS copy of the ALL 44.0/9 and 44.128/10 network PTR Records.
Thanks and 73,
Lynwood - KB3VWG Maintainer of 44.60.44.3 (dns-mdc.ampr.org)
On Tuesday, April 23, 2024 at 05:25:51 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
All,
44.60.44.3 is now up-to-date and as always, available as a recursive (client) DNS server that can be configured in AMPRNet hosts/clients.
user@dns-mdc:~$ ls /var/lib/bind -l -rw-r--r-- 1 bind bind 281 Apr 23 20:34 0.44.rev -rw-r--r-- 1 bind bind 227 Apr 23 19:30 128.44.rev -rw-r--r-- 1 bind bind 3221142 Feb 22 2023 44.rev.old -rw-r--r-- 1 bind bind 14187 Apr 23 19:33 68.44.rev -rw-r--r-- 1 bind bind 2584957 Apr 23 20:50 ampr.org.hosts -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 ampr.org.hosts.old
73,
Lynwood KB3VWG
On Tuesday, April 23, 2024 at 03:42:38 PM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Chris,
I wanted to thank you for your support and patience.
It ended up being firewall rule (that never affected the old 44.0.0.1 master configuration) - that prevented my server from initiating traffic bound for AMPRNet. I also wanted to publicly apologize.
I'll email you off-reflector with more details.
Public Kudos to you!!
- Lynwood
KB3VWG
On Tuesday, April 23, 2024 at 09:06:32 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood,
Yes, I am the right person, I will email you off list so we can discuss.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 23 Apr 2024, at 13:17, lleachii@aol.com wrote:
Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS?
I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l -rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev
user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44 ;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old.
If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
73,
- Lynwood
KB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
0.44.in-addr.arpa 68.44.in-addr.arpa 128.44.in-addr.arpa
B.) Testing the command
'dig AXFR ampr.org @44.1.1.44'Works from SRC IP 44.60.44.128 DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd:
user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3 PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data. From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable 64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms 64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms
D.) I noticed the high ping, is this server at UCSD or elsewhere?
E.) I've updated my NTP configuration as well.
- Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net http://ns.ardc.net/ as your time source.
All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote:
I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well.
If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1.
Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 AXFR for AMPR.ORG works AXFR 44.in-addr.arpa does NOT work AXFR for 68.44.in-addr.arpa works I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
Should I also be adding 128.44.in-addr.arpa? May I receive all the [verified] parameters on your part?
73,
Lynwood KB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net http://ns.ardc.net/ if you are on any 44Net IP. It is a stratum 2 server.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote:
Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
> On 4/20/2024 12:59 PM, Chris - G1FEF wrote: > The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? > Thanks > Chris >>> On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote: >> >> AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. >> Either something is wrong with it or it has been moved without >> us being notified. >> >> On 4/19/2024 2:30 PM, Chris wrote: >>>>> On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote: >>>> >>>> Has anyone noticed anything strange with encap routing and DNS entries since 4/10? >>> Can you be a little more specific Charles? >>> There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
-- 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
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Chris,
Those DNS servers aren't (and never have been) recursive - you noted that yourself. Most don't even AXFR according to RFC.
Users for years look for DNS servers, enter them into their clients - then wonder why they don't work, have failures for other domains, etc. Years ago, those on the Wiki agreed to maintain recursive/client DNS servers. I volunteered for EMCOMM, HSMM in the Atlantic/MDC area anyway - and because DNS latency for lookups to California and back were insane. Hence I asked you where ns.ardc.net was located due to the high ping. Also it is available to access for various International/NGO/government ENCOMM situations.
Since the late Brian Rodgers, SK passed away in Connecticut, I believe I'm one of the few on this [immediate] side of the pond. I hope this clarifies the mission of dns-mdc.ampr.org - I've been running the server about 10 years now.
Also, I added HAMWAN.ORG to the server.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 09:55:31 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
FYI, there is already an east coast US authoritative DNS server: ns2.us.ardc.net There is also one in Germany: ns1.de.ardc.net and one in the UK: a.gw4.uk 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 14:09, lleachii--- via 44net 44net@mailman.ampr.org wrote: To Operators/Clubs/Coordinators/Trustees/National Amateur Societies/etc. with delegated AMPRNet /16 Subnets:
Greetings. Time has passed - I've needed to urgently communicate with you. I awaited clarity and verification regarding DNS from the New ARDC regime and Administrator (B.Kantor, SK was the last ARDC Admin I worked with before Chris - that was before 44/8 was subdivided). If you do not do so at this time:
- Please allow AXFR for AMPRNet SRC IPs for your x.44.in-addr.arpa Master DNS from 44.0.0.0/9 and 44.128.0.0/10 - If you cannot do so, in the coming days/weeks, I will directly locate you/your server operator and request access for 44.60.44.3 to AXFR via any means of WHOIS/contact in DNS responses/IP's via RIR/ARIN or AMPRPortal/etc. - I can also coordinate with you to use a.) an IPv6 SRC address, b.) my IPENCAP tunnel using other DST addressing, or c.) a Wireguard tunnel instead Those who already allow AXFR per RFC at this time, my sincere appreciation and thanks. I would like to ensure I have a East Coast US DNS copy of the ALL 44.0/9 and 44.128/10 network PTR Records.
Thanks and 73,
Lynwood - KB3VWGMaintainer of 44.60.44.3 (dns-mdc.ampr.org)
On Tuesday, April 23, 2024 at 05:25:51 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
All,
44.60.44.3 is now up-to-date and as always, available as a recursive (client) DNS server that can be configured in AMPRNet hosts/clients.
user@dns-mdc:~$ ls /var/lib/bind -l-rw-r--r-- 1 bind bind 281 Apr 23 20:34 0.44.rev-rw-r--r-- 1 bind bind 227 Apr 23 19:30 128.44.rev-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 44.rev.old-rw-r--r-- 1 bind bind 14187 Apr 23 19:33 68.44.rev-rw-r--r-- 1 bind bind 2584957 Apr 23 20:50 ampr.org.hosts-rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 ampr.org.hosts.old
73,
LynwoodKB3VWG
On Tuesday, April 23, 2024 at 03:42:38 PM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Chris,
I wanted to thank you for your support and patience.
It ended up being firewall rule (that never affected the old 44.0.0.1 master configuration) - that prevented my server from initiating traffic bound for AMPRNet. I also wanted to publicly apologize. I'll email you off-reflector with more details.
Public Kudos to you!!
- LynwoodKB3VWG
On Tuesday, April 23, 2024 at 09:06:32 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood, Yes, I am the right person, I will email you off list so we can discuss. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 23 Apr 2024, at 13:17, lleachii@aol.com wrote: Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS? I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
- Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided - Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old. If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
--- 73,
- LynwoodKB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
- 0.44.in-addr.arpa - 68.44.in-addr.arpa - 128.44.in-addr.arpa
B.) Testing the command 'dig AXFR ampr.org @44.1.1.44'
- Works from SRC IP 44.60.44.128 - DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd: user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data.From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms D.) I noticed the high ping, is this server at UCSD or elsewhere? E.) I've updated my NTP configuration as well.
--- - Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net as your time source. All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote: I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well. If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1. --- Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
No, they are not recursive, but they are authoritative for ampr.org http://ampr.org/ and the 44 reverse zones. Not sure what the need is for recursive nameservers when there are some really fast public ones available like 1.1.1.1, 8.8.8.8, 9.9.9.9 etc - they all use anycast to get you to the closest point.
Also, if you are providing a recursive nameserver, why do you need to do zone transfers from ampr.org http://ampr.org/ and the 44 reverse zones? Your nameservers will automatically lookup (using recursion from the root) any requests it receives and will cache the result for the duration of the record’s TTL.
Just curious as you seem to be using DNS in a rather non-standard manner :-)
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 15:44, lleachii@aol.com wrote:
Chris,
Those DNS servers aren't (and never have been) recursive - you noted that yourself. Most don't even AXFR according to RFC.
Users for years look for DNS servers, enter them into their clients - then wonder why they don't work, have failures for other domains, etc.
Years ago, those on the Wiki agreed to maintain recursive/client DNS servers. I volunteered for EMCOMM, HSMM in the Atlantic/MDC area anyway - and because DNS latency for lookups to California and back were insane. Hence I asked you where ns.ardc.net was located due to the high ping. Also it is available to access for various International/NGO/government ENCOMM situations.
Since the late Brian Rodgers, SK passed away in Connecticut, I believe I'm one of the few on this [immediate] side of the pond.
I hope this clarifies the mission of dns-mdc.ampr.org - I've been running the server about 10 years now.
Also, I added HAMWAN.ORG to the server.
73,
Lynwood KB3VWG
On Wednesday, April 24, 2024 at 09:55:31 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
FYI, there is already an east coast US authoritative DNS server: ns2.us.ardc.net http://ns2.us.ardc.net/
There is also one in Germany: ns1.de.ardc.net http://ns1.de.ardc.net/
and one in the UK: a.gw4.uk http://a.gw4.uk/
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 14:09, lleachii--- via 44net 44net@mailman.ampr.org wrote:
To Operators/Clubs/Coordinators/Trustees/National Amateur Societies/etc. with delegated AMPRNet /16 Subnets:
Greetings. Time has passed - I've needed to urgently communicate with you. I awaited clarity and verification regarding DNS from the New ARDC regime and Administrator (B.Kantor, SK was the last ARDC Admin I worked with before Chris - that was before 44/8 was subdivided).
If you do not do so at this time:
Please allow AXFR for AMPRNet SRC IPs for your x.44.in-addr.arpa Master DNS from 44.0.0.0/9 and 44.128.0.0/10 If you cannot do so, in the coming days/weeks, I will directly locate you/your server operator and request access for 44.60.44.3 to AXFR via any means of WHOIS/contact in DNS responses/IP's via RIR/ARIN or AMPRPortal/etc. I can also coordinate with you to use a.) an IPv6 SRC address, b.) my IPENCAP tunnel using other DST addressing, or c.) a Wireguard tunnel instead Those who already allow AXFR per RFC at this time, my sincere appreciation and thanks.
I would like to ensure I have a East Coast US DNS copy of the ALL 44.0/9 and 44.128/10 network PTR Records.
Thanks and 73,
Lynwood - KB3VWG Maintainer of 44.60.44.3 (dns-mdc.ampr.org)
On Tuesday, April 23, 2024 at 05:25:51 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
All,
44.60.44.3 is now up-to-date and as always, available as a recursive (client) DNS server that can be configured in AMPRNet hosts/clients.
user@dns-mdc:~$ ls /var/lib/bind -l -rw-r--r-- 1 bind bind 281 Apr 23 20:34 0.44.rev -rw-r--r-- 1 bind bind 227 Apr 23 19:30 128.44.rev -rw-r--r-- 1 bind bind 3221142 Feb 22 2023 44.rev.old -rw-r--r-- 1 bind bind 14187 Apr 23 19:33 68.44.rev -rw-r--r-- 1 bind bind 2584957 Apr 23 20:50 ampr.org.hosts -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 ampr.org.hosts.old
73,
Lynwood KB3VWG
On Tuesday, April 23, 2024 at 03:42:38 PM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Chris,
I wanted to thank you for your support and patience.
It ended up being firewall rule (that never affected the old 44.0.0.1 master configuration) - that prevented my server from initiating traffic bound for AMPRNet. I also wanted to publicly apologize.
I'll email you off-reflector with more details.
Public Kudos to you!!
- Lynwood
KB3VWG
On Tuesday, April 23, 2024 at 09:06:32 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood,
Yes, I am the right person, I will email you off list so we can discuss.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 23 Apr 2024, at 13:17, lleachii@aol.com wrote:
Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS?
I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l -rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev
user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44 ;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old.
If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
73,
- Lynwood
KB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
0.44.in-addr.arpa 68.44.in-addr.arpa 128.44.in-addr.arpa
B.) Testing the command
'dig AXFR ampr.org @44.1.1.44'Works from SRC IP 44.60.44.128 DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd:
user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3 PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data. From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable 64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms 64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms
D.) I noticed the high ping, is this server at UCSD or elsewhere?
E.) I've updated my NTP configuration as well.
- Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net http://ns.ardc.net/ as your time source.
All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote:
I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well.
If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1.
Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 AXFR for AMPR.ORG works AXFR 44.in-addr.arpa does NOT work AXFR for 68.44.in-addr.arpa works I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
Should I also be adding 128.44.in-addr.arpa? May I receive all the [verified] parameters on your part?
73,
Lynwood KB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net http://ns.ardc.net/ if you are on any 44Net IP. It is a stratum 2 server.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote:
Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris > On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote: > > The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. > Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) > and things cleared out quickly. My personal JNOS also does public SMTP > messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. > The various state HamGates only had AMPR DNS, so they were backing up. > I can only go by what I was seeing vs what had been working for two years. > >> On 4/20/2024 12:59 PM, Chris - G1FEF wrote: >> The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? >> Thanks >> Chris >>>> On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote: >>> >>> AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. >>> Either something is wrong with it or it has been moved without >>> us being notified. >>> >>> On 4/19/2024 2:30 PM, Chris wrote: >>>>>> On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote: >>>>> >>>>> Has anyone noticed anything strange with encap routing and DNS entries since 4/10? >>>> Can you be a little more specific Charles? >>>> There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
-- 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
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org
Chris,
Regarding offering dns-mdc for use - and to understand client DNS server settings for hosts on AMPRNet: It seems you are being slightly circular in your reasoning. I've had to trouble you to ask about 44.5/16 and 44.15/16 a few times - and it's concerning. As you stated to me off-reflector - this is Public Information (as you had me seek it), and there's no need to hide. Also, many have volunteered to assist. To be clear, you've written:
Not sure what the need is for recursive nameservers when there are some really fast public ones available like 1.1.1.1, 8.8.8.8, 9.9.9.9 etc - they all use anycast to get you to the closest point.
---
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:That makes sense, the gateway server at UCSD is no longer running a DNS server.We have four authoritative nameservers now:ns.ardc.neta.gw4.ukns1.de.ardc.netns2.us.ardc.netNone of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. --- Also, if you are providing a recursive nameserver, why do you need to do zone transfers from ampr.org and the 44 reverse zones?
Today, your use case ignores normal users - where on April 20th you agreed:
- A user sets up AMPRNet
- A user sets up a client, IP, DNS (ns.ardc.net or gw.ampr.org and secondary DNS servers in the past- As you keep inferring should be done) - Users goes to XXyXXX.ampr.org - works - some PTR records work (...odd - because you are only "authoritative for ampr.org and [some of] the 44 reverse zones) - Wait....other domains and PTRs don't work...this sux =[ - Others have been telling you these issues, you seem to be ignoring them
Today's 24APR suggestion fails to identify this common problem and provides a fix - it also forgets your 20APR remarks acknowledging the issue - and that you volunteered to stand up a server somewhere to also solve that issue in one region (which is why I asked about latency to ns.ardc.net). To that end solution, I ask:
- 5.44.in-addr.arpa. - (Sweeden?) may I access your PTR records? - 15.44.in-addr.arpa. -(W8CMN?) may I access your PTR records? - 25.44.in-addr.arpa. - thank you HamWan for access
Your last comments regarding providing dns-mdc for users forgets your 20APR comments and incorrectly assumes this data traverses the Public Internet - and NOT primarily AMPRNet (hence reducing AMPRGW's need to handle traffic to Internet DNS servers), direct connections, etc. (recall, 44.0.0.1 previously had issues and was not recursive anyway). It's difficult to discuss when you're ignoring the simple day-to-day usage case of "a Client DNS Server IP(s) the user enters into the host for connectivity on AMPRNet". Since AMPRNet has never provided such a server, your understanding and changes on the use case confuses me - and I must ask for clarification.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 11:22:27 AM EDT, Chris chris@ardc.net wrote:
No, they are not recursive, but they are authoritative for ampr.org and the 44 reverse zones. Not sure what the need is for recursive nameservers when there are some really fast public ones available like 1.1.1.1, 8.8.8.8, 9.9.9.9 etc - they all use anycast to get you to the closest point. Also, if you are providing a recursive nameserver, why do you need to do zone transfers from ampr.org and the 44 reverse zones? Your nameservers will automatically lookup (using recursion from the root) any requests it receives and will cache the result for the duration of the record’s TTL. Just curious as you seem to be using DNS in a rather non-standard manner :-) 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 15:44, lleachii@aol.com wrote: Chris,
Those DNS servers aren't (and never have been) recursive - you noted that yourself. Most don't even AXFR according to RFC.
Users for years look for DNS servers, enter them into their clients - then wonder why they don't work, have failures for other domains, etc. Years ago, those on the Wiki agreed to maintain recursive/client DNS servers. I volunteered for EMCOMM, HSMM in the Atlantic/MDC area anyway - and because DNS latency for lookups to California and back were insane. Hence I asked you where ns.ardc.net was located due to the high ping. Also it is available to access for various International/NGO/government ENCOMM situations.
Since the late Brian Rodgers, SK passed away in Connecticut, I believe I'm one of the few on this [immediate] side of the pond. I hope this clarifies the mission of dns-mdc.ampr.org - I've been running the server about 10 years now.
Also, I added HAMWAN.ORG to the server.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 09:55:31 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
FYI, there is already an east coast US authoritative DNS server: ns2.us.ardc.net There is also one in Germany: ns1.de.ardc.net and one in the UK: a.gw4.uk 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 14:09, lleachii--- via 44net 44net@mailman.ampr.org wrote: To Operators/Clubs/Coordinators/Trustees/National Amateur Societies/etc. with delegated AMPRNet /16 Subnets:
Greetings. Time has passed - I've needed to urgently communicate with you. I awaited clarity and verification regarding DNS from the New ARDC regime and Administrator (B.Kantor, SK was the last ARDC Admin I worked with before Chris - that was before 44/8 was subdivided). If you do not do so at this time:
- Please allow AXFR for AMPRNet SRC IPs for your x.44.in-addr.arpa Master DNS from 44.0.0.0/9 and 44.128.0.0/10 - If you cannot do so, in the coming days/weeks, I will directly locate you/your server operator and request access for 44.60.44.3 to AXFR via any means of WHOIS/contact in DNS responses/IP's via RIR/ARIN or AMPRPortal/etc. - I can also coordinate with you to use a.) an IPv6 SRC address, b.) my IPENCAP tunnel using other DST addressing, or c.) a Wireguard tunnel instead Those who already allow AXFR per RFC at this time, my sincere appreciation and thanks. I would like to ensure I have a East Coast US DNS copy of the ALL 44.0/9 and 44.128/10 network PTR Records.
Thanks and 73,
Lynwood - KB3VWGMaintainer of 44.60.44.3 (dns-mdc.ampr.org)
On Tuesday, April 23, 2024 at 05:25:51 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
All,
44.60.44.3 is now up-to-date and as always, available as a recursive (client) DNS server that can be configured in AMPRNet hosts/clients.
user@dns-mdc:~$ ls /var/lib/bind -l-rw-r--r-- 1 bind bind 281 Apr 23 20:34 0.44.rev-rw-r--r-- 1 bind bind 227 Apr 23 19:30 128.44.rev-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 44.rev.old-rw-r--r-- 1 bind bind 14187 Apr 23 19:33 68.44.rev-rw-r--r-- 1 bind bind 2584957 Apr 23 20:50 ampr.org.hosts-rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 ampr.org.hosts.old
73,
LynwoodKB3VWG
On Tuesday, April 23, 2024 at 03:42:38 PM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Chris,
I wanted to thank you for your support and patience.
It ended up being firewall rule (that never affected the old 44.0.0.1 master configuration) - that prevented my server from initiating traffic bound for AMPRNet. I also wanted to publicly apologize. I'll email you off-reflector with more details.
Public Kudos to you!!
- LynwoodKB3VWG
On Tuesday, April 23, 2024 at 09:06:32 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood, Yes, I am the right person, I will email you off list so we can discuss. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 23 Apr 2024, at 13:17, lleachii@aol.com wrote: Chris,
Are you the person I should be contacting to ensure that there is a Atlantic Division/MDC Section DNS for AMPRNet - or should I contact another Ham regarding the infrastructure DNS? I seem to have inquires regarding DNS that are unresolved (see CLI output below), namely:
- Verify ns.ardc.net is configured for new global zones for Reverse DNS after 44/8 was subdivided - Why certain AMPRNet IPs cannot AXFR (per your email - "but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10")
user@dns-mdc:~$ ls /var/lib/bind/44.rev -l-rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev user@dns-mdc~$ dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44;; Connection to 44.1.1.44#53(44.1.1.44) for ampr.org failed: timed out.
If you are still working on this - I offer my sincere apologies. One issue seems to be over a year old. If you don't understand the ramifications - anyone using my server are receiving 1-year old PTR records.
--- 73,
- LynwoodKB3VWG
On Sunday, April 21, 2024 at 07:38:18 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
A.) Please verify your new zones are:
- 0.44.in-addr.arpa - 68.44.in-addr.arpa - 128.44.in-addr.arpa
B.) Testing the command 'dig AXFR ampr.org @44.1.1.44'
- Works from SRC IP 44.60.44.128 - DOES NOT work from SRC IP 44.60.44.3 - hence I still have failing transfers on dns-mdc.ampr.org (dig -b 44.60.44.3 AXFR ampr.org @44.1.1.44)
user@dns-mdc:~$ ls /var/lib/bind/ampr.org.hosts -l -rw-r--r-- 1 bind bind 2580501 Apr 11 09:08 /var/lib/bind/ampr.org.hosts
C.) This was also odd: user@dns-mdc:~$ ping 44.1.1.44 -I 44.60.44.3PING 44.1.1.44 (44.1.1.44) from 44.60.44.3 : 56(84) bytes of data.From 44.1.1.44 icmp_seq=1 Destination Protocol Unreachable64 bytes from 44.1.1.44: icmp_seq=2 ttl=49 time=210 ms64 bytes from 44.1.1.44: icmp_seq=3 ttl=49 time=208 ms D.) I noticed the high ping, is this server at UCSD or elsewhere? E.) I've updated my NTP configuration as well.
--- - Lynwood
On Sunday, April 21, 2024 at 06:47:26 AM EDT, Chris chris@ardc.net wrote:
You should update to use ns.ardc.net as your time source. All functionality on the gateway server is being deprecated except it’s role as the IPIP gateway i.e. encap/de-encap and RIP44d 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 21 Apr 2024, at 11:21, lleachii--- via 44net 44net@mailman.ampr.org wrote: I also wanted to note that 44.0.0.1 still appears to be a Stratum 2 NTP server as well. If this functionality is planned to switch, I also need to know to change my sanity check peers for 44.60.44.1. --- Lynwood
On Sunday, April 21, 2024 at 06:07:40 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
All,
- dns-mdc.ampr.org (44.60.44.3) has been reconfigured for ns.ardc.net (44.1.1.44) - dns-mdc.ampr.org is recursive for source IPs within 44.0.0.0/9 or 44.128.0.0/10 - AXFR for AMPR.ORG works - AXFR 44.in-addr.arpa does NOT work - AXFR for 68.44.in-addr.arpa works - I also have a Stratum 2 NTP server available at 44.60.44.1 (for source IPs within 44.0.0.0/9 or 44.128.0.0/10 or IPIP Tunnel Public IP addresses)
Chris,
- Should I also be adding 128.44.in-addr.arpa? - May I receive all the [verified] parameters on your part?
73,
LynwoodKB3VWG
On Saturday, April 20, 2024 at 04:11:07 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
In case it is of use to anyone you can also get NTP time from ns.ardc.net if you are on any 44Net IP. It is a stratum 2 server. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 20 Apr 2024, at 20:47, Charles J. Hargrove n2nov@n2nov.net wrote: Thank you, but it would have been useful to everyone to have this laid out way before the shutdown. I hat playing catch-up at work or in my hobby.
On 4/20/2024 2:40 PM, Chris - G1FEF wrote:
That makes sense, the gateway server at UCSD is no longer running a DNS server. We have four authoritative nameservers now: ns.ardc.net a.gw4.uk ns1.de.ardc.net ns2.us.ardc.net None of these permit recursive lookups, but you can do zone transfers from ns.ardc.net if you’re source IP is within 44.0.0.0/9 or 44.128.0.0/10 We are planning on setting up a recursive nameserver for 44.0.0.0/9 and 44.128.0.0/10 IPs at some point. 73, Chris
On 20 Apr 2024, at 18:11, Charles J. Hargrove n2nov@n2nov.net wrote:
The SMTP process in JNOS was piling up messages with 44.0.0.1 as a DNS server. Having seen that the issue was with 44.0.0.1, I changed to 8.8.8.8 (Google) and things cleared out quickly. My personal JNOS also does public SMTP messaging, so I already had 8.8.8.8 and a few others besides AMPR DNS. The various state HamGates only had AMPR DNS, so they were backing up. I can only go by what I was seeing vs what had been working for two years.
On 4/20/2024 12:59 PM, Chris - G1FEF wrote: The gateway server is still online and working, it’s not been moved, some of it’s functions have been deprecated, but I am able to SSH into it ok, so could you expand a bit on “unresponsive” please? Thanks Chris
On 20 Apr 2024, at 15:21, Charles J. Hargrove n2nov@n2nov.net wrote:
AMPR DNS at 44.0.0.1 has been unresponsive since April 11th. Either something is wrong with it or it has been moved without us being notified.
On 4/19/2024 2:30 PM, Chris wrote:
On 19 Apr 2024, at 18:42, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Has anyone noticed anything strange with encap routing and DNS entries since 4/10?
Can you be a little more specific Charles? There have been some major changes with encap and DNS in moving to the new portal, so if you are seeing any issues please let me know so they can be investigated/fixed
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different authoritative name servers in diverse areas and networks. BGP and IPIP included, if somebody wants a PTR record make a request like normal, but we will not be allowing transfers of zone files to any server not under our control. You are welcome to make PTR queries like anybody else but no special zone transfers will be allowed.
-- Fredric Moses - W8FSM - WRPA678
Frederic, How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
- What is that "normal request" in your paradigm? - Please explain - maybe I'm missing something? - What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP? What's being hidden?
73,
- LynwoodKB3VWG On Wednesday, April 24, 2024 at 12:26:36 PM EDT, Fredric Moses fred@moses.bz wrote:
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different authoritative name servers in diverse areas and networks. BGP and IPIP included, if somebody wants a PTR record make a request like normal, but we will not be allowing transfers of zone files to any server not under our control. You are welcome to make PTR queries like anybody else but no special zone transfers will be allowed. --Fredric Moses - W8FSM - WRPA678
Lynwood,
A request like normal is just a standard dns request.
If you want to be a open dns server for everyone on the AMPR network just do it. If someone asks for a ptr which your server does not own or have in it’s cache it’ll just look it up using the root servers like any normal dns server.
I don’t get why you **need** to have all reverses in your zones. Master or slave.
73, Ruben - ON3RVH
On 24 Apr 2024, at 18:35, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Frederic,
How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
* What is that "normal request" in your paradigm? * Please explain - maybe I'm missing something? * What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP?
What's being hidden?
73,
- Lynwood KB3VWG
On Wednesday, April 24, 2024 at 12:26:36 PM EDT, Fredric Moses fred@moses.bz wrote:
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different authoritative name servers in diverse areas and networks. BGP and IPIP included, if somebody wants a PTR record make a request like normal, but we will not be allowing transfers of zone files to any server not under our control. You are welcome to make PTR queries like anybody else but no special zone transfers will be allowed.
-- Fredric Moses - W8FSM - WRPA678
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Ruben,
You just asked (or suggest) I be the only available recursive nameserver for AMPRNet. You must have missed I've begun that for 10+ years ago. Yet to the contrary - you seem to miss the issue of its need and others existence for years? In cases where one does not add a gateway to use AMPRNet for Internet, how did users easily configure clients to use DNS for all of the domains/IP available over the AMPRNet (44.0/9-44.128.0/10 today) network/space/domain? The DNS servers prevented the disjointed issued that caused failures prior to dns-mdc's existence - now, you're just asking me to use my internet for those clients, yet this solution was to prevent usages of AMPRGW for Internet. So be it. The late B. Kantor, SK and my Late Regional Coordinator Applauded this - my late coordinator even setup DNS too, understanding the issue. As of the passing of N1URO, to my knowledge, I provided the first and not only client DNS server. So yes - I will just do it, but I humbly asked 44.15/16 spare me Internet when users connect to them - which might me useful in a emergency. They refused and that's OK. I appreciate the response from Federick. Normal PTR requests are fine. Thank you for understanding the issue preventing better usage of the network - on the network.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 12:44:40 PM EDT, Ruben ON3RVH via 44net 44net@mailman.ampr.org wrote:
Lynwood, A request like normal is just a standard dns request. If you want to be a open dns server for everyone on the AMPR network just do it. If someone asks for a ptr which your server does not own or have in it’s cache it’ll just look it up using the root servers like any normal dns server. I don’t get why you **need** to have all reverses in your zones. Master or slave. 73, Ruben - ON3RVH
On 24 Apr 2024, at 18:35, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Frederic, How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
- What is that "normal request" in your paradigm? - Please explain - maybe I'm missing something? - What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP? What's being hidden?
73,
- LynwoodKB3VWG On Wednesday, April 24, 2024 at 12:26:36 PM EDT, Fredric Moses fred@moses.bz wrote:
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different authoritative name servers in diverse areas and networks. BGP and IPIP included, if somebody wants a PTR record make a request like normal, but we will not be allowing transfers of zone files to any server not under our control. You are welcome to make PTR queries like anybody else but no special zone transfers will be allowed. --Fredric Moses - W8FSM - WRPA678
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Hi Lynwood,
Nobody is saying that a recursive nameserver inside the IPIP Tunnel Mesh is a bad idea, and thank you for providing this service, I am sure some folks will find it useful. As you rightly point out, it saves DNS queries going out and back in the UCSD gateway server. What I personally don't get is why you need access to AXFR / zone transfers? It simply isn’t required, in fact it’s a bad idea if you are relying on these to answer queries as they could easily be out of synch with the authoritative nameservers. It is also generating a lot of unnecessary traffic between your server and the authoritative servers, especially if you’re pulling them on a regular basis - so counter productive to your original intent ;-)
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 18:06, lleachii@aol.com wrote:
Ruben,
You just asked (or suggest) I be the only available recursive nameserver for AMPRNet. You must have missed I've begun that for 10+ years ago. Yet to the contrary - you seem to miss the issue of its need and others existence for years?
In cases where one does not add a gateway to use AMPRNet for Internet, how did users easily configure clients to use DNS for all of the domains/IP available over the AMPRNet (44.0/9-44.128.0/10 today) network/space/domain?
The DNS servers prevented the disjointed issued that caused failures prior to dns-mdc's existence - now, you're just asking me to use my internet for those clients, yet this solution was to prevent usages of AMPRGW for Internet. So be it. The late B. Kantor, SK and my Late Regional Coordinator Applauded this - my late coordinator even setup DNS too, understanding the issue.
As of the passing of N1URO, to my knowledge, I provided the first and not only client DNS server. So yes - I will just do it, but I humbly asked 44.15/16 spare me Internet when users connect to them - which might me useful in a emergency. They refused and that's OK.
I appreciate the response from Federick. Normal PTR requests are fine. Thank you for understanding the issue preventing better usage of the network - on the network.
73,
Lynwood KB3VWG
On Wednesday, April 24, 2024 at 12:44:40 PM EDT, Ruben ON3RVH via 44net 44net@mailman.ampr.org wrote:
Lynwood,
A request like normal is just a standard dns request.
If you want to be a open dns server for everyone on the AMPR network just do it. If someone asks for a ptr which your server does not own or have in it’s cache it’ll just look it up using the root servers like any normal dns server.
I don’t get why you **need** to have all reverses in your zones. Master or slave.
73, Ruben - ON3RVH
On 24 Apr 2024, at 18:35, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Frederic,
How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
What is that "normal request" in your paradigm? Please explain - maybe I'm missing something? What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP?
What's being hidden?
73,
- Lynwood
KB3VWG
On Wednesday, April 24, 2024 at 12:26:36 PM EDT, Fredric Moses fred@moses.bz wrote:
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different authoritative name servers in diverse areas and networks. BGP and IPIP included, if somebody wants a PTR record make a request like normal, but we will not be allowing transfers of zone files to any server not under our control. You are welcome to make PTR queries like anybody else but no special zone transfers will be allowed.
-- Fredric Moses - W8FSM - WRPA678
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org
Lynwood,
I did not ask that, nor did I suggest that. You also misread my mail or at least the point I was trying to make. (Maybe because you are enraged - at least you seem to be - or I did not make myself clear enough)
I get that you are and want to continue to be a recursive dns server for the ipip mesh and I do applaud the effort. But the point we are trying to make to you is that there is absolutely no need for your server to do AXFR requests.
73, Ruben - ON3RVH
On 24 Apr 2024, at 19:06, lleachii@aol.com wrote: You just asked (or suggest) I be the only available recursive nameserver for AMPRNet. You must have missed I've begun that for 10+ years ago. Yet to the contrary - you seem to miss the issue of its need and others existence for years?
Hi Lynwood,
As Ruben says - this was the point I was trying to get across in my last email - I am not criticising you, I am just curious to understand what you are trying to achieve as it does not make sense to me...
ARDC have setup four authoritative nameservers for ampr.org http://ampr.org/ and all the (now separate) reverse zones (ok, to be precise not ALL the reverse zones, as I said before we have a small number of delegated reverse zones - 5 or 6 from memory). Under normal circumstances NONE of these namservers need to allow AXFR / zone transfers to anyone, but as a few folks asked nicely I opened up ns.ardc.net http://ns.ardc.net/ (which is the primary) as a favour, but only to 44.0.0./9 & 44.128.0.0/10 source IPs.
To reiterate, these authoritative nameservers are:
ns.ardc.net (UK based primary) a.gw4.uk (UK based secondary) ns2.us.ardc.net (West coast US secondary) ns1.de.ardc.net (Germany based secondary)
As these are authoritative nameservers, best practice dictates that they are not also recursive nameservers.
If you, or anyone else wants to setup a recursive nameserver you are welcome to do so, no-one is going to stop you, nor do you have to ask anyone’s permission, but also you not need to get any special access to the zonefiles, as Frederic and others point out, you don't need to. If someone queries your recursive nameserver it will, by definition, recurse from the root servers down the tree to find one of the authoritative nameservers listed above to get the answer, your server will then cache that answer ready for the next time it is queried.
I hope that makes things clearer, but please, if I am not explaining it sufficiently do ask. It would also perhaps help me, and others, if you could explain why you want access to AXFR when it is not needed for a recursive nameserver (this is the non-standard bit I don’t get).
Thanks & 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 17:44, Ruben ON3RVH via 44net 44net@mailman.ampr.org wrote:
Lynwood,
A request like normal is just a standard dns request.
If you want to be a open dns server for everyone on the AMPR network just do it. If someone asks for a ptr which your server does not own or have in it’s cache it’ll just look it up using the root servers like any normal dns server.
I don’t get why you **need** to have all reverses in your zones. Master or slave.
73, Ruben - ON3RVH
On 24 Apr 2024, at 18:35, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Frederic,
How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
What is that "normal request" in your paradigm? Please explain - maybe I'm missing something? What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP?
What's being hidden?
73,
- Lynwood
KB3VWG
On Wednesday, April 24, 2024 at 12:26:36 PM EDT, Fredric Moses fred@moses.bz wrote:
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different authoritative name servers in diverse areas and networks. BGP and IPIP included, if somebody wants a PTR record make a request like normal, but we will not be allowing transfers of zone files to any server not under our control. You are welcome to make PTR queries like anybody else but no special zone transfers will be allowed.
-- Fredric Moses - W8FSM - WRPA678
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Chris,
It seems simple to me and I don't take it as criticism. I'm also in good company of those past who understood the issue. For me it seems stone-aged for users to wait 3-5 seconds for DNS requests, get no responses, experience failures, have to switch DNS servers or use AMPRGW to use 1.1.1.1, 8.8.8.8 and 9.9.9.9 (which are 150+ ms on my AMPRNet connection from MDC, how about the UK, other parts of Europe,etc.?). It was actually the reason our local EMCOMM sponsor failed to fund us year ago - we had basic DNS lookup failures/timeouts, had to change DNS servers on computers (as operating procedure), etc. I'm sure those anycasted servers [geo]located near UCSD - home of AMPRGW -hence the roundrtip delays for users using DNS over AMPRNet. How about the AMPRNet TBD server's location? Some suggest people use this DNS configuration it like its hyperspeed - it's not for many people on the Globe. Next - to be honest, there's delays (at least in the past) for AMPRNet queries making such configurations (I guess we're not that popular and you don't allow AXFR). That day still occurs for me today when not using or querying your servers directly - or nefarious caching that data randomly attempting PTR, etc).
- Is there some Wiki that tells users how to setup DNS servers like 1.1.1.1, 8.8.8.8, and 9.9.9.9 to reach their local anycast destination as you all suggest?
Lastly to note, if your AMPRNet has only IPENCAP connections, some of your suggestions require users setup their own DNS servers. Perhaps these /16's are not connected via IPENCAP - if so my apologies. Again PTR would suffice. I likewise regress without discussion of networks that use low cost metrics to reach a route (e.g. a BGP'ed network) - it seems unnecessary at this juncture. Thanks for the considerations and thought of those nonetheless - I never thought about all the notions of "special consideration", I thought it was clearly understood as necessary unless the network is unrelated to the ARDC AUP. It's RFC you allow AXFR. It seems odd the servers are configured to fail - but then I'm accused of seeking "special consideration" when asking for normal usage.
- KB3VWG
On Wednesday, April 24, 2024 at 01:16:09 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood, As Ruben says - this was the point I was trying to get across in my last email - I am not criticising you, I am just curious to understand what you are trying to achieve as it does not make sense to me... ARDC have setup four authoritative nameservers for ampr.org and all the (now separate) reverse zones (ok, to be precise not ALL the reverse zones, as I said before we have a small number of delegated reverse zones - 5 or 6 from memory). Under normal circumstances NONE of these namservers need to allow AXFR / zone transfers to anyone, but as a few folks asked nicely I opened up ns.ardc.net (which is the primary) as a favour, but only to 44.0.0./9 & 44.128.0.0/10 source IPs. To reiterate, these authoritative nameservers are: ns.ardc.net (UK based primary)a.gw4.uk (UK based secondary)ns2.us.ardc.net (West coast US secondary)ns1.de.ardc.net (Germany based secondary)
As these are authoritative nameservers, best practice dictates that they are not also recursive nameservers. If you, or anyone else wants to setup a recursive nameserver you are welcome to do so, no-one is going to stop you, nor do you have to ask anyone’s permission, but also you not need to get any special access to the zonefiles, as Frederic and others point out, you don't need to. If someone queries your recursive nameserver it will, by definition, recurse from the root servers down the tree to find one of the authoritative nameservers listed above to get the answer, your server will then cache that answer ready for the next time it is queried. I hope that makes things clearer, but please, if I am not explaining it sufficiently do ask. It would also perhaps help me, and others, if you could explain why you want access to AXFR when it is not needed for a recursive nameserver (this is the non-standard bit I don’t get). Thanks & 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 17:44, Ruben ON3RVH via 44net 44net@mailman.ampr.org wrote:
Lynwood, A request like normal is just a standard dns request. If you want to be a open dns server for everyone on the AMPR network just do it. If someone asks for a ptr which your server does not own or have in it’s cache it’ll just look it up using the root servers like any normal dns server. I don’t get why you **need** to have all reverses in your zones. Master or slave. 73, Ruben - ON3RVH
On 24 Apr 2024, at 18:35, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Frederic, How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
- What is that "normal request" in your paradigm? - Please explain - maybe I'm missing something? - What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP? What's being hidden?
73,
- LynwoodKB3VWG On Wednesday, April 24, 2024 at 12:26:36 PM EDT, Fredric Moses fred@moses.bz wrote:
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different authoritative name servers in diverse areas and networks. BGP and IPIP included, if somebody wants a PTR record make a request like normal, but we will not be allowing transfers of zone files to any server not under our control. You are welcome to make PTR queries like anybody else but no special zone transfers will be allowed. --Fredric Moses - W8FSM - WRPA678
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Hi Lynwood,
I am going to take this off-list with you as I think there is a fundamental misunderstanding here that I would like to resolve.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 18:46, lleachii@aol.com wrote:
Chris,
It seems simple to me and I don't take it as criticism. I'm also in good company of those past who understood the issue. For me it seems stone-aged for users to wait 3-5 seconds for DNS requests, get no responses, experience failures, have to switch DNS servers or use AMPRGW to use 1.1.1.1, 8.8.8.8 and 9.9.9.9 (which are 150+ ms on my AMPRNet connection from MDC, how about the UK, other parts of Europe,etc.?).
It was actually the reason our local EMCOMM sponsor failed to fund us year ago - we had basic DNS lookup failures/timeouts, had to change DNS servers on computers (as operating procedure), etc.
I'm sure those anycasted servers [geo]located near UCSD - home of AMPRGW -hence the roundrtip delays for users using DNS over AMPRNet.
How about the AMPRNet TBD server's location?
Some suggest people use this DNS configuration it like its hyperspeed - it's not for many people on the Globe. Next - to be honest, there's delays (at least in the past) for AMPRNet queries making such configurations (I guess we're not that popular and you don't allow AXFR). That day still occurs for me today when not using or querying your servers directly - or nefarious caching that data randomly attempting PTR, etc).
Is there some Wiki that tells users how to setup DNS servers like 1.1.1.1, 8.8.8.8, and 9.9.9.9 to reach their local anycast destination as you all suggest?
Lastly to note, if your AMPRNet has only IPENCAP connections, some of your suggestions require users setup their own DNS servers. Perhaps these /16's are not connected via IPENCAP - if so my apologies. Again PTR would suffice. I likewise regress without discussion of networks that use low cost metrics to reach a route (e.g. a BGP'ed network) - it seems unnecessary at this juncture.
Thanks for the considerations and thought of those nonetheless - I never thought about all the notions of "special consideration", I thought it was clearly understood as necessary unless the network is unrelated to the ARDC AUP. It's RFC you allow AXFR. It seems odd the servers are configured to fail - but then I'm accused of seeking "special consideration" when asking for normal usage.
- KB3VWG
On Wednesday, April 24, 2024 at 01:16:09 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood,
As Ruben says - this was the point I was trying to get across in my last email - I am not criticising you, I am just curious to understand what you are trying to achieve as it does not make sense to me...
ARDC have setup four authoritative nameservers for ampr.org http://ampr.org/ and all the (now separate) reverse zones (ok, to be precise not ALL the reverse zones, as I said before we have a small number of delegated reverse zones - 5 or 6 from memory). Under normal circumstances NONE of these namservers need to allow AXFR / zone transfers to anyone, but as a few folks asked nicely I opened up ns.ardc.net http://ns.ardc.net/ (which is the primary) as a favour, but only to 44.0.0./9 & 44.128.0.0/10 source IPs.
To reiterate, these authoritative nameservers are:
ns.ardc.net (UK based primary) a.gw4.uk (UK based secondary) ns2.us.ardc.net (West coast US secondary) ns1.de.ardc.net (Germany based secondary)
As these are authoritative nameservers, best practice dictates that they are not also recursive nameservers.
If you, or anyone else wants to setup a recursive nameserver you are welcome to do so, no-one is going to stop you, nor do you have to ask anyone’s permission, but also you not need to get any special access to the zonefiles, as Frederic and others point out, you don't need to. If someone queries your recursive nameserver it will, by definition, recurse from the root servers down the tree to find one of the authoritative nameservers listed above to get the answer, your server will then cache that answer ready for the next time it is queried.
I hope that makes things clearer, but please, if I am not explaining it sufficiently do ask. It would also perhaps help me, and others, if you could explain why you want access to AXFR when it is not needed for a recursive nameserver (this is the non-standard bit I don’t get).
Thanks & 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 17:44, Ruben ON3RVH via 44net 44net@mailman.ampr.org wrote:
Lynwood,
A request like normal is just a standard dns request.
If you want to be a open dns server for everyone on the AMPR network just do it. If someone asks for a ptr which your server does not own or have in it’s cache it’ll just look it up using the root servers like any normal dns server.
I don’t get why you **need** to have all reverses in your zones. Master or slave.
73, Ruben - ON3RVH
On 24 Apr 2024, at 18:35, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Frederic,
How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
What is that "normal request" in your paradigm? Please explain - maybe I'm missing something? What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP?
What's being hidden?
73,
- Lynwood
KB3VWG
On Wednesday, April 24, 2024 at 12:26:36 PM EDT, Fredric Moses fred@moses.bz wrote:
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different authoritative name servers in diverse areas and networks. BGP and IPIP included, if somebody wants a PTR record make a request like normal, but we will not be allowing transfers of zone files to any server not under our control. You are welcome to make PTR queries like anybody else but no special zone transfers will be allowed.
-- Fredric Moses - W8FSM - WRPA678
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org
Please tell me which RFC you are referring to that says you have to have AXFR access to all servers that host part of a larger network. I’d like to read up on that one.
73, Ruben - ON3RVH
On 24 Apr 2024, at 19:46, lleachii@aol.com wrote:
Chris,
It seems simple to me and I don't take it as criticism. I'm also in good company of those past who understood the issue. For me it seems stone-aged for users to wait 3-5 seconds for DNS requests, get no responses, experience failures, have to switch DNS servers or use AMPRGW to use 1.1.1.1, 8.8.8.8 and 9.9.9.9 (which are 150+ ms on my AMPRNet connection from MDC, how about the UK, other parts of Europe,etc.?).
It was actually the reason our local EMCOMM sponsor failed to fund us year ago - we had basic DNS lookup failures/timeouts, had to change DNS servers on computers (as operating procedure), etc.
I'm sure those anycasted servers [geo]located near UCSD - home of AMPRGW -hence the roundrtip delays for users using DNS over AMPRNet.
How about the AMPRNet TBD server's location?
Some suggest people use this DNS configuration it like its hyperspeed - it's not for many people on the Globe. Next - to be honest, there's delays (at least in the past) for AMPRNet queries making such configurations (I guess we're not that popular and you don't allow AXFR). That day still occurs for me today when not using or querying your servers directly - or nefarious caching that data randomly attempting PTR, etc).
* Is there some Wiki that tells users how to setup DNS servers like 1.1.1.1, 8.8.8.8, and 9.9.9.9 to reach their local anycast destination as you all suggest?
Lastly to note, if your AMPRNet has only IPENCAP connections, some of your suggestions require users setup their own DNS servers. Perhaps these /16's are not connected via IPENCAP - if so my apologies. Again PTR would suffice. I likewise regress without discussion of networks that use low cost metrics to reach a route (e.g. a BGP'ed network) - it seems unnecessary at this juncture.
Thanks for the considerations and thought of those nonetheless - I never thought about all the notions of "special consideration", I thought it was clearly understood as necessary unless the network is unrelated to the ARDC AUP. It's RFC you allow AXFR. It seems odd the servers are configured to fail - but then I'm accused of seeking "special consideration" when asking for normal usage.
- KB3VWG
On Wednesday, April 24, 2024 at 01:16:09 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood,
As Ruben says - this was the point I was trying to get across in my last email - I am not criticising you, I am just curious to understand what you are trying to achieve as it does not make sense to me...
ARDC have setup four authoritative nameservers for ampr.orghttp://ampr.org and all the (now separate) reverse zones (ok, to be precise not ALL the reverse zones, as I said before we have a small number of delegated reverse zones - 5 or 6 from memory). Under normal circumstances NONE of these namservers need to allow AXFR / zone transfers to anyone, but as a few folks asked nicely I opened up ns.ardc.nethttp://ns.ardc.net (which is the primary) as a favour, but only to 44.0.0./9 & 44.128.0.0/10 source IPs.
To reiterate, these authoritative nameservers are:
ns.ardc.net (UK based primary) a.gw4.uk (UK based secondary) ns2.us.ardc.net (West coast US secondary) ns1.de.ardc.net (Germany based secondary)
As these are authoritative nameservers, best practice dictates that they are not also recursive nameservers.
If you, or anyone else wants to setup a recursive nameserver you are welcome to do so, no-one is going to stop you, nor do you have to ask anyone’s permission, but also you not need to get any special access to the zonefiles, as Frederic and others point out, you don't need to. If someone queries your recursive nameserver it will, by definition, recurse from the root servers down the tree to find one of the authoritative nameservers listed above to get the answer, your server will then cache that answer ready for the next time it is queried.
I hope that makes things clearer, but please, if I am not explaining it sufficiently do ask. It would also perhaps help me, and others, if you could explain why you want access to AXFR when it is not needed for a recursive nameserver (this is the non-standard bit I don’t get).
Thanks & 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 24 Apr 2024, at 17:44, Ruben ON3RVH via 44net 44net@mailman.ampr.org wrote:
Lynwood,
A request like normal is just a standard dns request.
If you want to be a open dns server for everyone on the AMPR network just do it. If someone asks for a ptr which your server does not own or have in it’s cache it’ll just look it up using the root servers like any normal dns server.
I don’t get why you **need** to have all reverses in your zones. Master or slave.
73, Ruben - ON3RVH
On 24 Apr 2024, at 18:35, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Frederic,
How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
* What is that "normal request" in your paradigm? * Please explain - maybe I'm missing something? * What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP?
What's being hidden?
73,
- Lynwood KB3VWG
On Wednesday, April 24, 2024 at 12:26:36 PM EDT, Fredric Moses fred@moses.bz wrote:
As the admin for W8CMN and 44.15/16 our PTR records are hosted on seven different authoritative name servers in diverse areas and networks. BGP and IPIP included, if somebody wants a PTR record make a request like normal, but we will not be allowing transfers of zone files to any server not under our control. You are welcome to make PTR queries like anybody else but no special zone transfers will be allowed.
-- Fredric Moses - W8FSM - WRPA678
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.orgmailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.orgmailto:44net-leave@mailman.ampr.org
Oh boy do I hate these discussions.... All those people that see only their own world, cannot understand why their use case is different from that of others, immediately remark that others should do things differently (in the way they think is reasonable), and never even trying to understand the viewpoint and requirements of others.
It is a pity that what could be a nice project and a nice cooperation between technically interested people is so destroyed by this.
On Wed, Apr 24, 2024 at 1:54 PM Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
Oh boy do I hate these discussions.... All those people that see only their own world, cannot understand why their use case is different from that of others, immediately remark that others should do things differently (in the way they think is reasonable), and never even trying to understand the viewpoint and requirements of others.
It is a pity that what could be a nice project and a nice cooperation between technically interested people is so destroyed by this.
I don't know that it's quite that bad.
What I understand the use case to be is that: 1. KB3VWG has a recursive DNS server sitting on a very slow speed link (perhaps on an RF island). 2. He wants to be able to look up arbitrary AMPRnet host names, but the latency due to the RF island makes doing this in the standard recursive fashion difficult. Hence, 3. The desire to cache the entire `ampr.org` zone and reverse RRs, presumably by transferring them to said DNS server periodically via an AXFR. At least, that's my reading between the lines; it's admittedly not super clear whether the DNS server is on a slow link, or clients are on a slow link. I could see either as being a legitimate use case.
I think what G1FEF and ON3RVH are saying is that nothing precludes one from setting up a recursive DNS server that handles queries to the root for arbitrary AMPRNet DNS RRs oneself, and then configuring clients to connect to that. In that case, a client making a request from a slow RF island is still only making one request: to the recursive DNS server that will handle resolution from there, and eventually return the results to the slow client. But that's predicated on the recursive DNS server not being on a super-slow link.
Or maybe the request is to provision "official" recursive DNS servers in various places inside of AMPRnet to avoid having to traverse the public Internet to handle lookups. On the face of it, it's not an unreasonable request, but someone would have to coordinate it and provision the resources, etc.
Many DNS servers of various kinds support the concept of "forwarding" a query for specific zones to specific server (or set of servers); sort of an alternate root, if you will. For example, Unbound can do this via it's "Forward Zone" options: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#forwa... BIND has similar functionality when configured as a recursive resolver: https://bind9.readthedocs.io/en/latest/chapter3.html#resolver-caching-name-s... (see, section 3.3.3, "Forwarding Resolver Configuration"). With something like that, a recursive caching resolver on a slow island can forward to a nearby authoritative server without having to contact the root, and without any traffic leaving AMPRNet, and without having to use zone transfers to "seed" the local cache (which does seem fraught, as described).
- Dan C. (KZ2X)
That indeed sums it up quite good. Thanks Dan! And indeed the question is if Lynwood's server is also on a slow connection or not.
73, Ruben - ON3RVH
On 24 Apr 2024, at 20:47, Dan Cross via 44net 44net@mailman.ampr.org wrote:
On Wed, Apr 24, 2024 at 1:54 PM Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
Oh boy do I hate these discussions.... All those people that see only their own world, cannot understand why their use case is different from that of others, immediately remark that others should do things differently (in the way they think is reasonable), and never even trying to understand the viewpoint and requirements of others.
It is a pity that what could be a nice project and a nice cooperation between technically interested people is so destroyed by this.
I don't know that it's quite that bad.
What I understand the use case to be is that:
- KB3VWG has a recursive DNS server sitting on a very slow speed link
(perhaps on an RF island). 2. He wants to be able to look up arbitrary AMPRnet host names, but the latency due to the RF island makes doing this in the standard recursive fashion difficult. Hence, 3. The desire to cache the entire `ampr.org` zone and reverse RRs, presumably by transferring them to said DNS server periodically via an AXFR. At least, that's my reading between the lines; it's admittedly not super clear whether the DNS server is on a slow link, or clients are on a slow link. I could see either as being a legitimate use case.
I think what G1FEF and ON3RVH are saying is that nothing precludes one from setting up a recursive DNS server that handles queries to the root for arbitrary AMPRNet DNS RRs oneself, and then configuring clients to connect to that. In that case, a client making a request from a slow RF island is still only making one request: to the recursive DNS server that will handle resolution from there, and eventually return the results to the slow client. But that's predicated on the recursive DNS server not being on a super-slow link.
Or maybe the request is to provision "official" recursive DNS servers in various places inside of AMPRnet to avoid having to traverse the public Internet to handle lookups. On the face of it, it's not an unreasonable request, but someone would have to coordinate it and provision the resources, etc.
Many DNS servers of various kinds support the concept of "forwarding" a query for specific zones to specific server (or set of servers); sort of an alternate root, if you will. For example, Unbound can do this via it's "Forward Zone" options: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#forwa... BIND has similar functionality when configured as a recursive resolver: https://bind9.readthedocs.io/en/latest/chapter3.html#resolver-caching-name-s... (see, section 3.3.3, "Forwarding Resolver Configuration"). With something like that, a recursive caching resolver on a slow island can forward to a nearby authoritative server without having to contact the root, and without any traffic leaving AMPRNet, and without having to use zone transfers to "seed" the local cache (which does seem fraught, as described).
- Dan C. (KZ2X)
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
But it still focuses on one specific viewpoint and tries to ridicule other people's solutions and/or requirements. I think that is not the way we should interact. Especially not on a medium where not everyone has the same first language and thus some are at a disadvantage explaining or understanding the matter. We should approach each others messages in a neutral way, not all the time try to convince others that they are doing the wrong thing, and deny other people's requests and requirements.
E.g. in this matter I can (try to) explain that we also run our own DNS server with the 44-net zones on it. Until recently these were downloaded from the gw.ampr.org FTP server, but when that was removed we now use zone transfers.
Why? Why not "just query 8.8.8.8 and they will send the query to our servers"? Well, at least here (and even more so in other European regions and also elsewhere) the AMPRnet is not just a way to announce a large subnet on internet. We actually do have a radio network. We can reach other hams via radio, not via the internet. And some people like the idea that this network is functioning independently from the internet, e.g. to facilitate emergency communications. But also "because we can".
So, we have to provide our own DNS service, not rely on the internet, at least for the names and addresses that would be part of our network when it gets isolated. That is why we run a set of DNS servers (on an anycast address) that both serve net44 addresses and function as a recursive resolver for others. I have changed my scripts that used the FTP download into using zone transfers, and for our region it is reasonably complete. I don't care that much when we cannot transfer zones from a network in Michigan, because that probably will never be reachable for us when we have no internet. But other networks in Europe are in the server and are reachable without internet connectivity.
And I am no longer going to defend it. It is just the situation. When other people do not see the need, fine for them. We do see the need, so we do it. But I get really tired of those that always ridicule such things and/or are rejecting requests just because they themselves do not see the utility.
Rob
On 2024-04-24 21:01, Ruben ON3RVH via 44net wrote:
That indeed sums it up quite good. Thanks Dan! And indeed the question is if Lynwood's server is also on a slow connection or not.
73, Ruben - ON3RVH
On 24 Apr 2024, at 20:47, Dan Cross via 44net 44net@mailman.ampr.org wrote:
On Wed, Apr 24, 2024 at 1:54 PM Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
Oh boy do I hate these discussions.... All those people that see only their own world, cannot understand why their use case is different from that of others, immediately remark that others should do things differently (in the way they think is reasonable), and never even trying to understand the viewpoint and requirements of others.
It is a pity that what could be a nice project and a nice cooperation between technically interested people is so destroyed by this.
I don't know that it's quite that bad.
What I understand the use case to be is that:
- KB3VWG has a recursive DNS server sitting on a very slow speed link
(perhaps on an RF island). 2. He wants to be able to look up arbitrary AMPRnet host names, but the latency due to the RF island makes doing this in the standard recursive fashion difficult. Hence, 3. The desire to cache the entire `ampr.org` zone and reverse RRs, presumably by transferring them to said DNS server periodically via an AXFR. At least, that's my reading between the lines; it's admittedly not super clear whether the DNS server is on a slow link, or clients are on a slow link. I could see either as being a legitimate use case.
I think what G1FEF and ON3RVH are saying is that nothing precludes one from setting up a recursive DNS server that handles queries to the root for arbitrary AMPRNet DNS RRs oneself, and then configuring clients to connect to that. In that case, a client making a request from a slow RF island is still only making one request: to the recursive DNS server that will handle resolution from there, and eventually return the results to the slow client. But that's predicated on the recursive DNS server not being on a super-slow link.
Or maybe the request is to provision "official" recursive DNS servers in various places inside of AMPRnet to avoid having to traverse the public Internet to handle lookups. On the face of it, it's not an unreasonable request, but someone would have to coordinate it and provision the resources, etc.
Many DNS servers of various kinds support the concept of "forwarding" a query for specific zones to specific server (or set of servers); sort of an alternate root, if you will. For example, Unbound can do this via it's "Forward Zone" options: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#forwa... BIND has similar functionality when configured as a recursive resolver: https://bind9.readthedocs.io/en/latest/chapter3.html#resolver-caching-name-s... (see, section 3.3.3, "Forwarding Resolver Configuration"). With something like that, a recursive caching resolver on a slow island can forward to a nearby authoritative server without having to contact the root, and without any traffic leaving AMPRNet, and without having to use zone transfers to "seed" the local cache (which does seem fraught, as described).
- Dan C. (KZ2X)
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
On Wed, Apr 24, 2024 at 3:21 PM Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
But it still focuses on one specific viewpoint and tries to ridicule other people's solutions and/or requirements.
I can only assure you that I'm not trying to ridicule anyone, their solutions, their requirements, or their viewpoints.
- Dan C. (KZ2X)
We’re not ridiculing anyone or any point of view. We’re trying to understand the motivation/reasoning behind it all while saying that there are other ways to get the info he needs to his userbase.
Some are reluctant in allowing “anyone” to AXFR a zone to a server that they do not control or have access to and from an OPSEC point of view I completely understand that.
73, Ruben - ON3RVH
On 24 Apr 2024, at 21:22, Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
But it still focuses on one specific viewpoint and tries to ridicule other people's solutions and/or requirements. I think that is not the way we should interact. Especially not on a medium where not everyone has the same first language and thus some are at a disadvantage explaining or understanding the matter. We should approach each others messages in a neutral way, not all the time try to convince others that they are doing the wrong thing, and deny other people's requests and requirements.
E.g. in this matter I can (try to) explain that we also run our own DNS server with the 44-net zones on it. Until recently these were downloaded from the gw.ampr.org FTP server, but when that was removed we now use zone transfers.
Why? Why not "just query 8.8.8.8 and they will send the query to our servers"? Well, at least here (and even more so in other European regions and also elsewhere) the AMPRnet is not just a way to announce a large subnet on internet. We actually do have a radio network. We can reach other hams via radio, not via the internet. And some people like the idea that this network is functioning independently from the internet, e.g. to facilitate emergency communications. But also "because we can".
So, we have to provide our own DNS service, not rely on the internet, at least for the names and addresses that would be part of our network when it gets isolated. That is why we run a set of DNS servers (on an anycast address) that both serve net44 addresses and function as a recursive resolver for others. I have changed my scripts that used the FTP download into using zone transfers, and for our region it is reasonably complete. I don't care that much when we cannot transfer zones from a network in Michigan, because that probably will never be reachable for us when we have no internet. But other networks in Europe are in the server and are reachable without internet connectivity.
And I am no longer going to defend it. It is just the situation. When other people do not see the need, fine for them. We do see the need, so we do it. But I get really tired of those that always ridicule such things and/or are rejecting requests just because they themselves do not see the utility.
Rob
On 2024-04-24 21:01, Ruben ON3RVH via 44net wrote: That indeed sums it up quite good. Thanks Dan! And indeed the question is if Lynwood's server is also on a slow connection or not.
73, Ruben - ON3RVH
On 24 Apr 2024, at 20:47, Dan Cross via 44net 44net@mailman.ampr.org wrote:
On Wed, Apr 24, 2024 at 1:54 PM Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
Oh boy do I hate these discussions.... All those people that see only their own world, cannot understand why their use case is different from that of others, immediately remark that others should do things differently (in the way they think is reasonable), and never even trying to understand the viewpoint and requirements of others.
It is a pity that what could be a nice project and a nice cooperation between technically interested people is so destroyed by this.
I don't know that it's quite that bad.
What I understand the use case to be is that:
- KB3VWG has a recursive DNS server sitting on a very slow speed link
(perhaps on an RF island). 2. He wants to be able to look up arbitrary AMPRnet host names, but the latency due to the RF island makes doing this in the standard recursive fashion difficult. Hence, 3. The desire to cache the entire `ampr.org` zone and reverse RRs, presumably by transferring them to said DNS server periodically via an AXFR. At least, that's my reading between the lines; it's admittedly not super clear whether the DNS server is on a slow link, or clients are on a slow link. I could see either as being a legitimate use case.
I think what G1FEF and ON3RVH are saying is that nothing precludes one from setting up a recursive DNS server that handles queries to the root for arbitrary AMPRNet DNS RRs oneself, and then configuring clients to connect to that. In that case, a client making a request from a slow RF island is still only making one request: to the recursive DNS server that will handle resolution from there, and eventually return the results to the slow client. But that's predicated on the recursive DNS server not being on a super-slow link.
Or maybe the request is to provision "official" recursive DNS servers in various places inside of AMPRnet to avoid having to traverse the public Internet to handle lookups. On the face of it, it's not an unreasonable request, but someone would have to coordinate it and provision the resources, etc.
Many DNS servers of various kinds support the concept of "forwarding" a query for specific zones to specific server (or set of servers); sort of an alternate root, if you will. For example, Unbound can do this via it's "Forward Zone" options: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#forwa... BIND has similar functionality when configured as a recursive resolver: https://bind9.readthedocs.io/en/latest/chapter3.html#resolver-caching-name-s... (see, section 3.3.3, "Forwarding Resolver Configuration"). With something like that, a recursive caching resolver on a slow island can forward to a nearby authoritative server without having to contact the root, and without any traffic leaving AMPRNet, and without having to use zone transfers to "seed" the local cache (which does seem fraught, as described).
- Dan C. (KZ2X)
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Shhh! Secret Squirrel.
On 4/24/2024 4:22 PM, Ruben ON3RVH via 44net wrote:
from an OPSEC point of view
On 2024-04-24 23:27, Angelo Glorioso via 44net wrote:
Did anyone find the left handed screw driver yet?????
GEEZZ
On 4/24/2024 3:25 PM, Charles J. Hargrove via 44net wrote:
Shhh! Secret Squirrel.
On 4/24/2024 4:22 PM, Ruben ON3RVH via 44net wrote:
from an OPSEC point of view
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
This must be the most discussed topic since the new portal, over 30 responses. Had a great time reading all the replies.
How about the tickets? Anybody received any response? :)
Have a nice one!
All, I have been accused of:
- not being a native English speaker - being enraged - being asked how I'm hurt - despite I explained the issue with AMPRNet that hindered our usage of it here - to explain the RFC that tertiary servers use to obtain their zone??? - having my server on a low-speed link, yet it's on a 1 Gbps connection in a Data Center
I honestly thought it was a joke when Chris asked to access the server - this all was laughable; but I think I'm just done discussing. So many people have made up things while not understanding something simple as having a client work on AMPRNet when one goes thru the trouble to setup a mesh with no client DNS sever. I honestly thought that was simple. I just want people not to have timeouts and lookup failures. To be clear, I was born and raised in Washington, DC USA and I resent that statement on behalf of my neighborhood' (lol). There's been a lot of negative guessing about who I am personally taking place here- I find it quite rude.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 04:25:20 PM EDT, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Shhh! Secret Squirrel.
On 4/24/2024 4:22 PM, Ruben ON3RVH via 44net wrote:
from an OPSEC point of view
Good evening, everyone,
I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
1. We are HAMS, and one of our goals is to better the hobby for everyone. 2. I think finding a way to have multiple recursive DNS geographically disbursed is a good idea. 3. We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR. 4. While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel. 5. There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this. 6. Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious. 7. The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation.
As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning.
73, Jeff Parrish - KB9GXK
________________________________ From: lleachii--- via 44net 44net@mailman.ampr.org Sent: Wednesday, April 24, 2024 16:01 To: 44net@mailman.ampr.org 44net@mailman.ampr.org; Charles J. Hargrove n2nov@n2nov.net Subject: [44net] Re: DNS AXFR
All,
I have been accused of:
* not being a native English speaker * being enraged * being asked how I'm hurt - despite I explained the issue with AMPRNet that hindered our usage of it here * to explain the RFC that tertiary servers use to obtain their zone??? * having my server on a low-speed link, yet it's on a 1 Gbps connection in a Data Center
I honestly thought it was a joke when Chris asked to access the server - this all was laughable; but I think I'm just done discussing. So many people have made up things while not understanding something simple as having a client work on AMPRNet when one goes thru the trouble to setup a mesh with no client DNS sever. I honestly thought that was simple. I just want people not to have timeouts and lookup failures.
To be clear, I was born and raised in Washington, DC USA and I resent that statement on behalf of my neighborhood' (lol). There's been a lot of negative guessing about who I am personally taking place here- I find it quite rude.
73,
Lynwood KB3VWG
On Wednesday, April 24, 2024 at 04:25:20 PM EDT, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Shhh! Secret Squirrel.
On 4/24/2024 4:22 PM, Ruben ON3RVH via 44net wrote:
from an OPSEC point of view
-- 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
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.orgmailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.orgmailto:44net-leave@mailman.ampr.org
Jeff,
No. 6 - our ENCOMM sponsors have issues with the robustness of the network. I will be required to run that Server here anyways. This will only hinder our use, as we just received approvals from W3PGC's sponsor (home of the MDC section EC). I've been waiting to update on the DNS matter that was just resolved yesterday (aside from 2 /16's).
**BGP approval here also depend on a OLSR (used in HSMM) mesh via public safety controlled Layer1/Layer2 fiber to any radio towers, etc. as well.** Not sure others points need to be discussed.
No. 7 - I need to update my ENCAP DDNS - I hope this "ticket system" doesn't delay it.
--- - KB3VWG
On Wednesday, April 24, 2024 at 06:02:34 PM EDT, Jeff Parrish-Personal jeff@kb9gxk.net wrote:
Good evening, everyone, I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
- We are HAMS, and one of our goals is to better the hobby for everyone. - I think finding a way to have multiple recursive DNS geographically disbursed is a good idea. - We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR. - While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel. - There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this. - Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious. - The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation. As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning. 73,Jeff Parrish - KB9GXK
From: lleachii--- via 44net 44net@mailman.ampr.org Sent: Wednesday, April 24, 2024 16:01 To: 44net@mailman.ampr.org 44net@mailman.ampr.org; Charles J. Hargrove n2nov@n2nov.net Subject: [44net] Re: DNS AXFR All, I have been accused of:
- not being a native English speaker - being enraged - being asked how I'm hurt - despite I explained the issue with AMPRNet that hindered our usage of it here - to explain the RFC that tertiary servers use to obtain their zone??? - having my server on a low-speed link, yet it's on a 1 Gbps connection in a Data Center
I honestly thought it was a joke when Chris asked to access the server - this all was laughable; but I think I'm just done discussing. So many people have made up things while not understanding something simple as having a client work on AMPRNet when one goes thru the trouble to setup a mesh with no client DNS sever. I honestly thought that was simple. I just want people not to have timeouts and lookup failures. To be clear, I was born and raised in Washington, DC USA and I resent that statement on behalf of my neighborhood' (lol). There's been a lot of negative guessing about who I am personally taking place here- I find it quite rude.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 04:25:20 PM EDT, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Shhh! Secret Squirrel.
On 4/24/2024 4:22 PM, Ruben ON3RVH via 44net wrote:
from an OPSEC point of view
-- 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 _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Jeff, I also wanted to note that converting my server to BGP - means I must volunteer to run a IPENCAP tunnel as well, especially running the DNS. I also volunteered to do so to the old and new admin and coordinator. Look in the 44-net mailing archives to see why that would be necessary. It may shed light on why a recursive DNS is needed. A lot of those discussions - a SK participated in.
- Lynwood
On Wednesday, April 24, 2024 at 06:14:16 PM EDT, lleachii@aol.com lleachii@aol.com wrote:
Jeff,
No. 6 - our ENCOMM sponsors have issues with the robustness of the network. I will be required to run that Server here anyways. This will only hinder our use, as we just received approvals from W3PGC's sponsor (home of the MDC section EC). I've been waiting to update on the DNS matter that was just resolved yesterday (aside from 2 /16's).
**BGP approval here also depend on a OLSR (used in HSMM) mesh via public safety controlled Layer1/Layer2 fiber to any radio towers, etc. as well.** Not sure others points need to be discussed.
No. 7 - I need to update my ENCAP DDNS - I hope this "ticket system" doesn't delay it.
--- - KB3VWG
On Wednesday, April 24, 2024 at 06:02:34 PM EDT, Jeff Parrish-Personal jeff@kb9gxk.net wrote:
Good evening, everyone, I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
- We are HAMS, and one of our goals is to better the hobby for everyone. - I think finding a way to have multiple recursive DNS geographically disbursed is a good idea. - We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR. - While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel. - There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this. - Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious. - The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation. As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning. 73,Jeff Parrish - KB9GXK
From: lleachii--- via 44net 44net@mailman.ampr.org Sent: Wednesday, April 24, 2024 16:01 To: 44net@mailman.ampr.org 44net@mailman.ampr.org; Charles J. Hargrove n2nov@n2nov.net Subject: [44net] Re: DNS AXFR All, I have been accused of:
- not being a native English speaker - being enraged - being asked how I'm hurt - despite I explained the issue with AMPRNet that hindered our usage of it here - to explain the RFC that tertiary servers use to obtain their zone??? - having my server on a low-speed link, yet it's on a 1 Gbps connection in a Data Center
I honestly thought it was a joke when Chris asked to access the server - this all was laughable; but I think I'm just done discussing. So many people have made up things while not understanding something simple as having a client work on AMPRNet when one goes thru the trouble to setup a mesh with no client DNS sever. I honestly thought that was simple. I just want people not to have timeouts and lookup failures. To be clear, I was born and raised in Washington, DC USA and I resent that statement on behalf of my neighborhood' (lol). There's been a lot of negative guessing about who I am personally taking place here- I find it quite rude.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 04:25:20 PM EDT, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Shhh! Secret Squirrel.
On 4/24/2024 4:22 PM, Ruben ON3RVH via 44net wrote:
from an OPSEC point of view
-- 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 _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Jeff,
No. 5.
I hope now understanding that I waited for the honor talking to Chris to finally tell me in EN since 22FEB2023 since the Late Brian Kantor and my coordinators were aware - that I'm not poising OUR DNS records.
user@dns-mdc:~$ ls /var/lib/bind/44.rev.old -l -rw-r--r-- 1 bind bind 3221142 Feb 22 2023 /var/lib/bind/44.rev.old
- KB3VWG
On Wednesday, April 24, 2024 at 06:02:47 PM EDT, Jeff Parrish-Personal via 44net 44net@mailman.ampr.org wrote:
Good evening, everyone, I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
- We are HAMS, and one of our goals is to better the hobby for everyone. - I think finding a way to have multiple recursive DNS geographically disbursed is a good idea. - We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR. - While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel. - There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this. - Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious. - The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation. As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning. 73,Jeff Parrish - KB9GXK
From: lleachii--- via 44net 44net@mailman.ampr.org Sent: Wednesday, April 24, 2024 16:01 To: 44net@mailman.ampr.org 44net@mailman.ampr.org; Charles J. Hargrove n2nov@n2nov.net Subject: [44net] Re: DNS AXFR All, I have been accused of:
- not being a native English speaker - being enraged - being asked how I'm hurt - despite I explained the issue with AMPRNet that hindered our usage of it here - to explain the RFC that tertiary servers use to obtain their zone??? - having my server on a low-speed link, yet it's on a 1 Gbps connection in a Data Center
I honestly thought it was a joke when Chris asked to access the server - this all was laughable; but I think I'm just done discussing. So many people have made up things while not understanding something simple as having a client work on AMPRNet when one goes thru the trouble to setup a mesh with no client DNS sever. I honestly thought that was simple. I just want people not to have timeouts and lookup failures. To be clear, I was born and raised in Washington, DC USA and I resent that statement on behalf of my neighborhood' (lol). There's been a lot of negative guessing about who I am personally taking place here- I find it quite rude.
73,
LynwoodKB3VWG
On Wednesday, April 24, 2024 at 04:25:20 PM EDT, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
Shhh! Secret Squirrel.
On 4/24/2024 4:22 PM, Ruben ON3RVH via 44net wrote:
from an OPSEC point of view
-- 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 _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
I think a point that has not been clear: ARDC *do* allow AXFR on ns.ardc.net. No issue there. What people were complaining about is that some zones that have been delegated to other name servers do not allow AXFR. E.g. Fredric Moses - W8FSM has been explaining here that he won't allow AXFR on his zones.
Now why one would not allow AXFR on a reverse zone to someone in net44 is completely unclear to me. It is easy to work around, after all. Probably they based their policy on considerations about a forward zone, and about allowing transfer to everybody.
Rob
On 2024-04-25 00:02, Jeff Parrish-Personal via 44net wrote:
Good evening, everyone,
I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
- We are HAMS, and one of our goals is to better the hobby for everyone.
- I think finding a way to have multiple recursive DNS geographically disbursed is a good idea.
- We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR.
- While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel.
- There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this.
- Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious.
- The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation.
As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning.
73, Jeff Parrish - KB9GXK
We do have a small number of /16 reverse zones that are delegated to other name servers, what policies they decide to implement on their own servers is up to them, ARDC does not dictate policy in this regard, except to expect they operate industry best practices, don’t do anything that affects the security or reputation of ARDC and 44Net in general, i.e. the usual caveats.
TBH I am not completely comfortable allowing zone transfers on our nameservers, I have allowed it on one server because a few folks requested it, but I would like to work with them to move to an alternative when convenient so I can turn it off again.
It is not best practice to allow zone transfers, even if (as I have done) it is restricted to only 44Net source IPs. It leaves the name server open to DDOS attacks, it allows bad actors to get a full view of all hosts thus increasing the attack vectors, i.e. they have a better idea of which hosts to attack and what might be running on them.
There are better ways to get the information, i.e. via the Portal’s API that is authenticated and therefore we can be sure who is asking for the data.
Hope that clarifies the current situation, but feel free to ask if I can help further.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 25 Apr 2024, at 08:38, Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
I think a point that has not been clear: ARDC *do* allow AXFR on ns.ardc.net. No issue there. What people were complaining about is that some zones that have been delegated to other name servers do not allow AXFR. E.g. Fredric Moses - W8FSM has been explaining here that he won't allow AXFR on his zones.
Now why one would not allow AXFR on a reverse zone to someone in net44 is completely unclear to me. It is easy to work around, after all. Probably they based their policy on considerations about a forward zone, and about allowing transfer to everybody.
Rob
On 2024-04-25 00:02, Jeff Parrish-Personal via 44net wrote:
Good evening, everyone,
I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
- We are HAMS, and one of our goals is to better the hobby for everyone.
- I think finding a way to have multiple recursive DNS geographically disbursed is a good idea.
- We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR.
- While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel.
- There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this.
- Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious.
- The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation.
As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning.
73, Jeff Parrish - KB9GXK
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
On Thu, Apr 25, 2024 at 4:47 AM Chris via 44net 44net@mailman.ampr.org wrote:
[snip] TBH I am not completely comfortable allowing zone transfers on our nameservers, I have allowed it on one server because a few folks requested it, but I would like to work with them to move to an alternative when convenient so I can turn it off again.
It is not best practice to allow zone transfers, even if (as I have done) it is restricted to only 44Net source IPs. It leaves the name server open to DDOS attacks, it allows bad actors to get a full view of all hosts thus increasing the attack vectors, i.e. they have a better idea of which hosts to attack and what might be running on them.
There are better ways to get the information, i.e. via the Portal’s API that is authenticated and therefore we can be sure who is asking for the data.
While that level of caution is certainly appropriate for the public Internet, I have a hard time believing it's warranted on AMPRNet itself. Has anyone done an actual threat analysis for traffic originating inside the network itself?
- Dan C.
Isn't it more prudent for each user device to have their own security? Maybe that is where a more useful discussion should take place. The education of the user systems/allocation holders falls into line with amateur radio being a technical hobby/service and those who are more knowledgeable in our sphere should have more a sense of being an elmer instead of keeping the information to themselves and be seen as wielding a cudgel when "upstarts" ask questions to power. Money can sure corrupt viewpoints, eh?
On 4/25/2024 9:23 AM, Dan Cross via 44net wrote:
While that level of caution is certainly appropriate for the public Internet, I have a hard time believing it's warranted on AMPRNet itself. Has anyone done an actual threat analysis for traffic originating inside the network itself?
On 25 Apr 2024, at 14:23, Dan Cross crossd@gmail.com wrote:
On Thu, Apr 25, 2024 at 4:47 AM Chris via 44net 44net@mailman.ampr.org wrote:
[snip] TBH I am not completely comfortable allowing zone transfers on our nameservers, I have allowed it on one server because a few folks requested it, but I would like to work with them to move to an alternative when convenient so I can turn it off again.
It is not best practice to allow zone transfers, even if (as I have done) it is restricted to only 44Net source IPs. It leaves the name server open to DDOS attacks, it allows bad actors to get a full view of all hosts thus increasing the attack vectors, i.e. they have a better idea of which hosts to attack and what might be running on them.
There are better ways to get the information, i.e. via the Portal’s API that is authenticated and therefore we can be sure who is asking for the data.
While that level of caution is certainly appropriate for the public Internet, I have a hard time believing it's warranted on AMPRNet itself. Has anyone done an actual threat analysis for traffic originating inside the network itself?
- Dan C.
I regularly play “whack-a-mole” with people trying to hijack our address space using BGP. There have also been instances of bad gateways, the new portal has a bit more checking / vetting where on the old portal, anyone could register and setup a gateway and steal someone’s subnet, it could take a few days or even weeks to be noticed. I also regularly receive abuse reports, usually due to someone’s host on a 44 IP address having been compromised and doing all sorts of nasty things!
So unfortunately, it does happen and security should be one of our top priorities. Everyone is responsible for keeping their own systems secure, I am responsible for ensuring ARDC’s servers are kept secure, which is why I am slightly nervous about permitting zone transfers. I would prefer not to, so if anyone is currently doing zone transfers, please contact me off list so we can discuss whether there is a better way of achieving what you need.
I’m happy to give my time to work with you to achieve the best outcomes for all concerned.
Thank you, Chris - G1FEF
Rob,
I have had off-reflector inquires. I want to see your views about simply "localizing" the /16 zones as masters for anyone who cares (since I do receive a lot of traffic). Since the networks seem to have isolated themselves and they provide their own DNS, and are BGP, it really is unnecessary to discuss with them? Technically, the /16's "don't exist" on AMPRNet and are our of control of the ARDC (save removing their ARIN delegation). I would have asked the "admins" of those networks, but the last one said I soiled a relationship before I even sent a communication to them (funny - to me it seems someone communicated "something" to them). The IPIP mesh will pick up any islands - aside from the PTRs (which we don't have anyway)- all is well. And any bandwidth (like what AMPRGW attempted to save) due to non-cooperation is saved.They claim to run IPENCAP anyways. I bring this up because I've seen mentioned some API? - Is there a Wiki on this? - use only Authoritative servers, when that failed - Oh, I need a gateway to use 1.1.1.1, 8.8.8.8 and 9.9.9.9 - when that fails because I'm 2000km+ from the anycast endpoint server round-trip - make my own DNS - when that fails - oh well, maybe it's my language or I need to know what a DNS server is - but I have experience in IT
I'm being told those servers are down - and have have been for quite some time. Their failures (I won't speak on the current regime) are why B. Kantor and others permitted AXFR. I find it funny that the option is a failed or decommissioned server instead of RFC-documented processes. Albeit I'll acknowledge there's some myth about not allowing AXFR, DDoS, vector for malicious actors, etc. (to be honest, I'm ignoring the silliness and evasiveness - maybe it's been mistaken for my misunderstanding IT or EN). Let's keep the conversation to the specific topic - it's my direct intent not to solicit trolling.
73,
LynwoodKB3VWG
On Thursday, April 25, 2024 at 03:39:20 AM EDT, Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
I think a point that has not been clear: ARDC *do* allow AXFR on ns.ardc.net. No issue there. What people were complaining about is that some zones that have been delegated to other name servers do not allow AXFR. E.g. Fredric Moses - W8FSM has been explaining here that he won't allow AXFR on his zones.
Now why one would not allow AXFR on a reverse zone to someone in net44 is completely unclear to me. It is easy to work around, after all. Probably they based their policy on considerations about a forward zone, and about allowing transfer to everybody.
Rob
On 2024-04-25 00:02, Jeff Parrish-Personal via 44net wrote:
Good evening, everyone,
I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
1. We are HAMS, and one of our goals is to better the hobby for everyone. 2. I think finding a way to have multiple recursive DNS geographically disbursed is a good idea. 3. We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR. 4. While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel. 5. There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this. 6. Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious. 7. The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation.
As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning.
73, Jeff Parrish - KB9GXK
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Rob,
I should probably note the basic logic of my reasoning that prompted the inquiry to you:
- My intention is to use the "official AMPRNet" API to re-create the reverse zone (i.e. in a usable format) - I assume that it will omit or have missing 5, 15 and 25.44/16 subnets and hence, they should likewise be omitted
- KB3VWG
On Thursday, April 25, 2024 at 09:04:04 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Rob,
I have had off-reflector inquires. I want to see your views about simply "localizing" the /16 zones as masters for anyone who cares (since I do receive a lot of traffic). Since the networks seem to have isolated themselves and they provide their own DNS, and are BGP, it really is unnecessary to discuss with them? Technically, the /16's "don't exist" on AMPRNet and are our of control of the ARDC (save removing their ARIN delegation). I would have asked the "admins" of those networks, but the last one said I soiled a relationship before I even sent a communication to them (funny - to me it seems someone communicated "something" to them). The IPIP mesh will pick up any islands - aside from the PTRs (which we don't have anyway)- all is well. And any bandwidth (like what AMPRGW attempted to save) due to non-cooperation is saved.They claim to run IPENCAP anyways. I bring this up because I've seen mentioned some API? - Is there a Wiki on this? - use only Authoritative servers, when that failed - Oh, I need a gateway to use 1.1.1.1, 8.8.8.8 and 9.9.9.9 - when that fails because I'm 2000km+ from the anycast endpoint server round-trip - make my own DNS - when that fails - oh well, maybe it's my language or I need to know what a DNS server is - but I have experience in IT
I'm being told those servers are down - and have have been for quite some time. Their failures (I won't speak on the current regime) are why B. Kantor and others permitted AXFR. I find it funny that the option is a failed or decommissioned server instead of RFC-documented processes. Albeit I'll acknowledge there's some myth about not allowing AXFR, DDoS, vector for malicious actors, etc. (to be honest, I'm ignoring the silliness and evasiveness - maybe it's been mistaken for my misunderstanding IT or EN). Let's keep the conversation to the specific topic - it's my direct intent not to solicit trolling.
73,
LynwoodKB3VWG
On Thursday, April 25, 2024 at 03:39:20 AM EDT, Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
I think a point that has not been clear: ARDC *do* allow AXFR on ns.ardc.net. No issue there. What people were complaining about is that some zones that have been delegated to other name servers do not allow AXFR. E.g. Fredric Moses - W8FSM has been explaining here that he won't allow AXFR on his zones.
Now why one would not allow AXFR on a reverse zone to someone in net44 is completely unclear to me. It is easy to work around, after all. Probably they based their policy on considerations about a forward zone, and about allowing transfer to everybody.
Rob
On 2024-04-25 00:02, Jeff Parrish-Personal via 44net wrote:
Good evening, everyone,
I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
1. We are HAMS, and one of our goals is to better the hobby for everyone. 2. I think finding a way to have multiple recursive DNS geographically disbursed is a good idea. 3. We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR. 4. While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel. 5. There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this. 6. Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious. 7. The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation.
As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning.
73, Jeff Parrish - KB9GXK
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
I tested this in sandbox over past 24 hours - and:
- it's not very affective if there are hosts in the ampr zone, and that can change
- technically, to do so would be invalid/poison
I will leave as is the missing 44.15/16 - I will proceed to ask Sweeden (?) regarding 44.5/16. Regarding 44.25/16 - it's sick and unfortunate they said NO before I even asked; although I now know who encouraged them to do so.
Again, thanks HamWan for following policy - it made reconfiguration for 44.25/16 simple. Thanks to others for your ideas and views off-reflector, I did consider them. Lastly on a network where research should be encouraged - it's ashamed millions of dollars are given out by the regime to others; but 0 cares are given when it doesn't cost a dime for those actually making use (i.e. donated for 10+ years). Frankly, having sat here for over a year waiting to speak - I don't see with millions of dollars, how progress is slow on these AMPRNet projects, changes, broken services, etc. Given there's funding, I would again encourage ARDC to seek additional professional help. I always learned "charity begins at home". 501(c)3's should be careful about things like this - and I digress.
- Lynwood
On Thursday, April 25, 2024 at 09:29:26 AM EDT, lleachii@aol.com lleachii@aol.com wrote:
Rob,
I should probably note the basic logic of my reasoning that prompted the inquiry to you:
- My intention is to use the "official AMPRNet" API to re-create the reverse zone (i.e. in a usable format) - I assume that it will omit or have missing 5, 15 and 25.44/16 subnets and hence, they should likewise be omitted
- KB3VWG
On Thursday, April 25, 2024 at 09:04:04 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Rob,
I have had off-reflector inquires. I want to see your views about simply "localizing" the /16 zones as masters for anyone who cares (since I do receive a lot of traffic). Since the networks seem to have isolated themselves and they provide their own DNS, and are BGP, it really is unnecessary to discuss with them? Technically, the /16's "don't exist" on AMPRNet and are our of control of the ARDC (save removing their ARIN delegation). I would have asked the "admins" of those networks, but the last one said I soiled a relationship before I even sent a communication to them (funny - to me it seems someone communicated "something" to them). The IPIP mesh will pick up any islands - aside from the PTRs (which we don't have anyway)- all is well. And any bandwidth (like what AMPRGW attempted to save) due to non-cooperation is saved.They claim to run IPENCAP anyways. I bring this up because I've seen mentioned some API? - Is there a Wiki on this? - use only Authoritative servers, when that failed - Oh, I need a gateway to use 1.1.1.1, 8.8.8.8 and 9.9.9.9 - when that fails because I'm 2000km+ from the anycast endpoint server round-trip - make my own DNS - when that fails - oh well, maybe it's my language or I need to know what a DNS server is - but I have experience in IT
I'm being told those servers are down - and have have been for quite some time. Their failures (I won't speak on the current regime) are why B. Kantor and others permitted AXFR. I find it funny that the option is a failed or decommissioned server instead of RFC-documented processes. Albeit I'll acknowledge there's some myth about not allowing AXFR, DDoS, vector for malicious actors, etc. (to be honest, I'm ignoring the silliness and evasiveness - maybe it's been mistaken for my misunderstanding IT or EN). Let's keep the conversation to the specific topic - it's my direct intent not to solicit trolling.
73,
LynwoodKB3VWG
On Thursday, April 25, 2024 at 03:39:20 AM EDT, Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
I think a point that has not been clear: ARDC *do* allow AXFR on ns.ardc.net. No issue there. What people were complaining about is that some zones that have been delegated to other name servers do not allow AXFR. E.g. Fredric Moses - W8FSM has been explaining here that he won't allow AXFR on his zones.
Now why one would not allow AXFR on a reverse zone to someone in net44 is completely unclear to me. It is easy to work around, after all. Probably they based their policy on considerations about a forward zone, and about allowing transfer to everybody.
Rob
On 2024-04-25 00:02, Jeff Parrish-Personal via 44net wrote:
Good evening, everyone,
I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
1. We are HAMS, and one of our goals is to better the hobby for everyone. 2. I think finding a way to have multiple recursive DNS geographically disbursed is a good idea. 3. We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR. 4. While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel. 5. There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this. 6. Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious. 7. The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation.
As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning.
73, Jeff Parrish - KB9GXK
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Correction "Regarding 44.**15***/16 - it's sick and unfortunate..."
Thanks again to HamWan - who did.
Lynwood On Friday, April 26, 2024 at 08:01:01 AM EDT, lleachii@aol.com lleachii@aol.com wrote:
I tested this in sandbox over past 24 hours - and:
- it's not very affective if there are hosts in the ampr zone, and that can change
- technically, to do so would be invalid/poison
I will leave as is the missing 44.15/16 - I will proceed to ask Sweeden (?) regarding 44.5/16. Regarding 44.25/16 - it's sick and unfortunate they said NO before I even asked; although I now know who encouraged them to do so.
Again, thanks HamWan for following policy - it made reconfiguration for 44.25/16 simple. Thanks to others for your ideas and views off-reflector, I did consider them. Lastly on a network where research should be encouraged - it's ashamed millions of dollars are given out by the regime to others; but 0 cares are given when it doesn't cost a dime for those actually making use (i.e. donated for 10+ years). Frankly, having sat here for over a year waiting to speak - I don't see with millions of dollars, how progress is slow on these AMPRNet projects, changes, broken services, etc. Given there's funding, I would again encourage ARDC to seek additional professional help. I always learned "charity begins at home". 501(c)3's should be careful about things like this - and I digress.
- Lynwood
On Thursday, April 25, 2024 at 09:29:26 AM EDT, lleachii@aol.com lleachii@aol.com wrote:
Rob,
I should probably note the basic logic of my reasoning that prompted the inquiry to you:
- My intention is to use the "official AMPRNet" API to re-create the reverse zone (i.e. in a usable format) - I assume that it will omit or have missing 5, 15 and 25.44/16 subnets and hence, they should likewise be omitted
- KB3VWG
On Thursday, April 25, 2024 at 09:04:04 AM EDT, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Rob,
I have had off-reflector inquires. I want to see your views about simply "localizing" the /16 zones as masters for anyone who cares (since I do receive a lot of traffic). Since the networks seem to have isolated themselves and they provide their own DNS, and are BGP, it really is unnecessary to discuss with them? Technically, the /16's "don't exist" on AMPRNet and are our of control of the ARDC (save removing their ARIN delegation). I would have asked the "admins" of those networks, but the last one said I soiled a relationship before I even sent a communication to them (funny - to me it seems someone communicated "something" to them). The IPIP mesh will pick up any islands - aside from the PTRs (which we don't have anyway)- all is well. And any bandwidth (like what AMPRGW attempted to save) due to non-cooperation is saved.They claim to run IPENCAP anyways. I bring this up because I've seen mentioned some API? - Is there a Wiki on this? - use only Authoritative servers, when that failed - Oh, I need a gateway to use 1.1.1.1, 8.8.8.8 and 9.9.9.9 - when that fails because I'm 2000km+ from the anycast endpoint server round-trip - make my own DNS - when that fails - oh well, maybe it's my language or I need to know what a DNS server is - but I have experience in IT
I'm being told those servers are down - and have have been for quite some time. Their failures (I won't speak on the current regime) are why B. Kantor and others permitted AXFR. I find it funny that the option is a failed or decommissioned server instead of RFC-documented processes. Albeit I'll acknowledge there's some myth about not allowing AXFR, DDoS, vector for malicious actors, etc. (to be honest, I'm ignoring the silliness and evasiveness - maybe it's been mistaken for my misunderstanding IT or EN). Let's keep the conversation to the specific topic - it's my direct intent not to solicit trolling.
73,
LynwoodKB3VWG
On Thursday, April 25, 2024 at 03:39:20 AM EDT, Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
I think a point that has not been clear: ARDC *do* allow AXFR on ns.ardc.net. No issue there. What people were complaining about is that some zones that have been delegated to other name servers do not allow AXFR. E.g. Fredric Moses - W8FSM has been explaining here that he won't allow AXFR on his zones.
Now why one would not allow AXFR on a reverse zone to someone in net44 is completely unclear to me. It is easy to work around, after all. Probably they based their policy on considerations about a forward zone, and about allowing transfer to everybody.
Rob
On 2024-04-25 00:02, Jeff Parrish-Personal via 44net wrote:
Good evening, everyone,
I have been passively watching this heated discussion. I usually wouldn't jump in on it, but I have some input.
1. We are HAMS, and one of our goals is to better the hobby for everyone. 2. I think finding a way to have multiple recursive DNS geographically disbursed is a good idea. 3. We must remember that any DNS we get from ARDC, whether ampr.org or ardc.net, is still technically an ARDC ZONE, and they have the right to choose whether they will allow AXFR. 4. While you need to have a DNS entry created in the ARCH Portal for IPIP to work, if you have your own domain name, you can still use that. I own kb9gxk.net and will publish it under my domain for anything I wish to allow others to access. I chose Cloudflare for this as I can use their CloudflareD option to allow public access via my IP but keep the actual HAM traffic going through my IPIP tunnel. 5. There are no RFCs stating that a DNS server MUST allow for AXFR. That easily allows for DNS poisoning. I'm hoping that ARDC's DNS servers are using DNSSEC to help prevent this. 6. Lynwood, if you have a server in a Data Center, why would you not work with them to get a BGP connection instead of using IPIP? I'm not saying you have to; I'm just curious. 7. The new portal has given us much more access than the old one, and there are bound to be bugs and delays as many more requests are being processed. I'm still having an issue with my DNS stuff, but I am patiently waiting. In my case, my IPs were previously assigned, and my "DNS Name" was created in the wrong domain, so when I had asked for the previous assignments to be removed, I couldn't create the proper entries for my IPs to work correctly. Again, I know they are backed up with tickets, and I will wait patiently.
This whole discussion could have been handled differently. This could have started as a proposal of ideas and asking for implementation.
As a side note, when I get passionate about something I believe and decide to write an email, I use Grammarly to a) make sure my grammar is correct and b) check the tone of the email. I have learned that my passion can be very off-putting, so I have found a way to say what I need to, but it is not demeaning.
73, Jeff Parrish - KB9GXK
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
On Wed, Apr 24, 2024 at 5:02 PM lleachii--- via 44net 44net@mailman.ampr.org wrote:
I have been accused of:
[snip] having my server on a low-speed link, yet it's on a 1 Gbps connection in a Data Center
I think I was the one who suggested that might be the case. I can say that I did not mean that in a disparaging way, but rather it was just how I had understood the use case. I apologize if that was mistaken on my part.
I honestly thought it was a joke when Chris asked to access the server - this all was laughable; but I think I'm just done discussing. So many people have made up things while not understanding something simple as having a client work on AMPRNet when one goes thru the trouble to setup a mesh with no client DNS sever. I honestly thought that was simple. I just want people not to have timeouts and lookup failures.
I guess I really don't understand the use case, then. Forgive me, I'm not trying to be rude or obtuse. I thought you had set up a DNS server?
To be clear, I was born and raised in Washington, DC USA and I resent that statement on behalf of my neighborhood' (lol). There's been a lot of negative guessing about who I am personally taking place here- I find it quite rude.
Hey, DC people represent! (I was also born in DC, but haven't lived anywhere near the district save for a short stint in Quantico when I was in the Marines).
- Dan C. (KZ2X)
Make the request to the root server like any other resolver does. We don’t have to allow you anything you are not ARDC nor was anything about allowing XFRS in any of the documents that was signed for when we got our allocation or when we then had to submit for approval of reverse delegation of our allocations. Some people or groups might not want to give you special treatment is all. Welcome to the network.
Nothing is hidden, make a PTR request to your resolver and you will get a response through the proper way things work.
-- Fredric Moses - W8FSM - WRPA678
On Apr 24, 2024, at 12:34, lleachii@aol.com wrote:
Frederic,
How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
What is that "normal request" in your paradigm? Please explain - maybe I'm missing something? What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP?
What's being hidden?
73,
- Lynwood
KB3VWG
Frederic,
Thanks. I assume your use case does not assume some radio only, etc. networks - and other anomalies, and that's OK - as you know how "your" network is connected to the Internet and others. Since your use case seems to omit the circumstance a user may not have such connection, yet access to 44.60.44.3 assumes connection - as I noted normal PTR records are OK if one happens to make such a lookup. Again, thank you for your consideration.
- KB3VWG
On Wednesday, April 24, 2024 at 12:49:35 PM EDT, Fredric Moses via 44net 44net@mailman.ampr.org wrote:
Make the request to the root server like any other resolver does. We don’t have to allow you anything you are not ARDC nor was anything about allowing XFRS in any of the documents that was signed for when we got our allocation or when we then had to submit for approval of reverse delegation of our allocations. Some people or groups might not want to give you special treatment is all. Welcome to the network. Nothing is hidden, make a PTR request to your resolver and you will get a response through the proper way things work. --Fredric Moses - W8FSM - WRPA678
On Apr 24, 2024, at 12:34, lleachii@aol.com wrote: Frederic, How does someone "make a request like normal" if their client DNS server is set to 44.1.1.44, but your 7 authoritative servers are not (nor ns2.ardc.net, UK, DE etc. - but others)?
- What is that "normal request" in your paradigm? - Please explain - maybe I'm missing something? - What if this user doesn't use IPIP for Internet, but needs to accesses hamwan or your subnet?
This is why it's better to simply follow RFC - or maybe your network is not being used for AMPRNet according the AUP? What's being hidden?
73,
- LynwoodKB3VWG _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Our use case does assume “Radio Only” networks and not just BGP. It’s why we have an IPIP gateway setup at one of our datacenters that handles the IPIP mesh for those AMPR users who are not BGP speaking. Even though BGP is our primary external connection for other non IPIP networks.
You seem pretty enraged about this “thing” you are providing and have provided for years now that nobody here on our networks are even using. We provide our own dns-cache servers for our users to use as how it should be. Having XFR of our zone file which is over 5MB mind you does not effect in any way your or other users ability on the IPIP mesh to connect to any IP address’s in our 44.15/16 allocation.
I would also for future note if you are asking an out of the ordinary question of other admins that telling them if they do not do what you ask that they are some how violating ARDC’s terms of service for allocations and are hiding things. You come hostile like that don’t be surprised when you get told no even if your “project” might do some good. As you have soiled the relationship.
Chris and others have told you it’s not needed and why what you are requesting isn’t a good idea so no need to pile that on. But if for some reason you can’t reach any 44.15/16 IP via the IPIP mesh please provide traceroutes.
BTW - Please show me on the DNS server where the lack of XFR’s hurt you...
-- Fredric Moses - W8FSM - WRPA678
On Apr 24, 2024, at 13:18, lleachii@aol.com wrote:
Frederic,
Thanks. I assume your use case does not assume some radio only, etc. networks - and other anomalies, and that's OK - as you know how "your" network is connected to the Internet and others.
Since your use case seems to omit the circumstance a user may not have such connection, yet access to 44.60.44.3 assumes connection - as I noted normal PTR records are OK if one happens to make such a lookup.
Again, thank you for your consideration.
- KB3VWG
I made some DNS changes to my subdomain yesterday and around 2 hours later they showed up in DNS when I used nslookup. I later made some more amendments but it's now 24 hours later and they still don't show.
Are the changes transferred in batches? if so what is the update frequency?
Thanks
Max
G4FDL
Those updates are normally fast, at least with the old DNS at ucsd.edu, a half hour or so when I query the Google DNS, it depends. Strange that they didn't show up if you didn't make a mistake. Try it a second time, it will tell you or the same entry was already there, and refuses to do it in that case, at least with the old one.
Bob VE3TOK
On 2024-04-24 17:41, G4FDL via 44net wrote:
I made some DNS changes to my subdomain yesterday and around 2 hours later they showed up in DNS when I used nslookup. I later made some more amendments but it's now 24 hours later and they still don't show.
Are the changes transferred in batches? if so what is the update frequency?
Thanks
Max
G4FDL
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
I wonder if the Time To Live (TTL) has been changed?
When a query for a DNS record is made to a non-authoritative server and it isn’t cached. The non-authoritative server makes a query to the authoritative server. When the authoritative server sends its response it tells the non-authoritative server how long to cache the response.
The TTL can be found in the SOA record which can be queried from the authoritative server using a tool called “dig”. Dig is a much more capable and feature rich tool than nslookup and can be found on most Linux distributions.
N0SFH
On Wed, Apr 24, 2024, at 5:51 PM, Boudewijn (Bob) Tenty via 44net wrote:
Those updates are normally fast, at least with the old DNS at ucsd.edu, a half hour or so when I query the Google DNS, it depends. Strange that they didn't show up if you didn't make a mistake. Try it a second time, it will tell you or the same entry was already there, and refuses to do it in that case, at least with the old one.
Bob VE3TOK
On 2024-04-24 17:41, G4FDL via 44net wrote:
I made some DNS changes to my subdomain yesterday and around 2 hours later they showed up in DNS when I used nslookup. I later made some more amendments but it's now 24 hours later and they still don't show.
Are the changes transferred in batches? if so what is the update frequency?
Thanks
Max
G4FDL
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
-- There is nothing permanent except change -Heraclitus
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
The updates have been stuck since late April 23, at serial number 2024042318 We'll probably have to wait until the issue has been resolved. Before that, they were applied on the hour.
On 2024-04-24 23:41, G4FDL via 44net wrote:
I made some DNS changes to my subdomain yesterday and around 2 hours later they showed up in DNS when I used nslookup. I later made some more amendments but it's now 24 hours later and they still don't show.
Are the changes transferred in batches? if so what is the update frequency?
Thanks
Max
G4FDL
Mea culpa!
I noticed that the updates were running way too often, i.e. it was incrementing the serial even when no updates had occurred, on checking the code I spotted the bug causing this and thought i had fixed it. In fact I had introduced another bug that meant NO updates were being run!
I have now fixed the issue, and tested to make sure!!
Apologies,
Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 25 Apr 2024, at 08:31, Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
The updates have been stuck since late April 23, at serial number 2024042318 We'll probably have to wait until the issue has been resolved. Before that, they were applied on the hour.
On 2024-04-24 23:41, G4FDL via 44net wrote:
I made some DNS changes to my subdomain yesterday and around 2 hours later they showed up in DNS when I used nslookup. I later made some more amendments but it's now 24 hours later and they still don't show.
Are the changes transferred in batches? if so what is the update frequency?
Thanks
Max
G4FDL
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Chris,
Ok there are still 3 zones that are stuck. Please check the bind logs using some monitoring script to find zone loading errors that sometimes persist for several days. I had to do the same in the days when I loaded the FTP zone file.
(egrep "named.* zone .*(error|failed)" $log; grep "named.* malformed" $log)
Rob
On 2024-04-25 10:51, Chris via 44net wrote:
Mea culpa!
I noticed that the updates were running way too often, i.e. it was incrementing the serial even when no updates had occurred, on checking the code I spotted the bug causing this and thought i had fixed it. In fact I had introduced another bug that meant NO updates were being run!
I have now fixed the issue, and tested to make sure!!
Apologies,
Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 25 Apr 2024, at 08:31, Rob PE1CHL via 44net 44net@mailman.ampr.org wrote:
The updates have been stuck since late April 23, at serial number 2024042318 We'll probably have to wait until the issue has been resolved. Before that, they were applied on the hour.
On 2024-04-24 23:41, G4FDL via 44net wrote:
I made some DNS changes to my subdomain yesterday and around 2 hours later they showed up in DNS when I used nslookup. I later made some more amendments but it's now 24 hours later and they still don't show.
Are the changes transferred in batches? if so what is the update frequency?
Thanks
Max
G4FDL
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
-
Angelo Glorioso -
Boudewijn (Bob) Tenty -
Charles Hargrove -
Charles J. Hargrove -
Chris -
Chris - G1FEF
-
Dan Cross -
David Ranch -
Fredric Moses -
G4FDL -
Jeff Parrish-Personal -
lleachii＠aol.com -
metwo2＠gmail.com
-
Neil Johnson -
Razvan -
Rebecca Key -
Rob PE1CHL -
Ruben ON3RVH