Hi,
Several weeks ago I requested postal address verification via the new
portal, however it is still set as new (unassigned).
Is there some expected time-span for assignment?
I couldn't really find more info on that on this list, so I decided to
start this thread.
Thanks,
~ SP6KEK
For years, I usually make a DNS request to my coordinator and CC Chris. It takes less than 1 hours. I believe I've been waiting 3 days on 20+ tickets in the new Portal.I should note, I haven't been able to request the DNS changes - because the records are currently in an "unclaimed" status and not assigned to my call. I'm still waiting to "claim" them.Since Chirs and my coordinator have since responded to me here and off-reflector, who should I be contacting regarding tickets in the Portal?Again, I don't wish to seem impatient or entitled - especially given I now realize that others have been waiting months.Thanks and 73,LynwoodKB3VWG
-------- Original message --------From: Jim Kutsch KY2D via 44net <44net(a)mailman.ampr.org> Date: 5/12/24 10:50 (GMT-05:00) To: '44Net general discussion' <44net(a)mailman.ampr.org> Subject: [44net] Re: Postal address verification Unless Maine is an exception, I’m in the U.S. and my address verification request has been pending since April 12. No postcard received yet. . 73 Jim KY2D From: Dave Gingrich via 44net <44net(a)mailman.ampr.org> Sent: Sunday, May 12, 2024 9:59To: 44Net general discussion <44net(a)mailman.ampr.org>Subject: [44net] Re: Postal address verification It is much easier for the team to verify callsigns and addresses for U.S. domestic people. For some non-US locations it is nearly impossible. Tickets and any associated documents are completely deleted when they are acted upon. The team is very paranoid of leaving any personally identifiable information laying around in a database somewhere. — Dave K9DC, K9IP On May 12, 2024, at 08:58, Cara Salter via 44net <44net(a)mailman.ampr.org> wrote: On 5/12/24 08:03, femsci via 44net wrote:Several weeks ago I requested postal address verification via the new portal, however it is still set as new (unassigned).Is there some expected time-span for assignment?I couldn't really find more info on that on this list, so I decided to start this thread.Interesting -- my address verification ticket was approved (from what I can tell) on the same day.Slight tangent -- is there a way to view resolved tickets? When I go to Tickets -> View My Tickets there's nothing listed.73,Cara KC1KZT
Le 05/05/2024 à 11:28, Rob PE1CHL via 44net a écrit :
> I am disappointed that the current system is focused on a completely different
> use-case than we have here
I quite agree.
For subnet 44.151 (France), I have IP creation requests pending and I
still don't know if it's possible.
For BGP France requests, I don't even know where the BGP France IPs
are since they're no longer in 44.151.
I guess we'll have to wait, so I'll wait.
That's all I can do.
😉
What would be a step forward is if coadmins could themselves create
requestor IPs and manage their associate dns/reverse dns.
Best regards,
Ludovic - F5PBG
Does ns.ardc.org have an access policy restricting traffic to only IPs with a DNS entry (i.e. Intra-AMPRNet only)?
That differs from what I've been told, so I wish ask.
I'm having a difficult time with one of my valid AMPRNet IPs and have been struggling for days. I only have success with IPS having DNS entries.
73,
LynwoodKB3VWG
All,
I have 22 "unassigned" tickets in the Portal. I assume these have tasks I usually emailed my coordinator about. how do they get resolved?
I don't want to sound "entitled" - I just don't understand what's occurring-since I've been responded to and assumed over 1 year notice (I've been told ARDC had 2 year notice). I noted I'd have a DNS matter soon and and as understand coordinators don't know what to do.
Forgive me if this is the wrong channel to communicate, but I've noted this before publicly and privately with no response.
Also, my trust, IPv4 and IPv6 request trust level are incorrect.
Thanks and 73,
KB3VWG
I rebooted my AMPRNet router after an upgrade earlier today, and now
IPENCAP traffic doesn't seem to be flowing through the UCSD gateway. I
wonder if this is expected behavior?
I've verified that all interfaces on the router are working as
expected: I can ping the _external_ address of the UCSD gateway from
my router's external interface:
```
marconi# ping -V 23 -I 23.30.150.141 169.228.34.84
PING 169.228.34.84 (169.228.34.84): 56 data bytes
64 bytes from 169.228.34.84: icmp_seq=0 ttl=48 time=86.937 ms
64 bytes from 169.228.34.84: icmp_seq=1 ttl=48 time=85.409 ms
64 bytes from 169.228.34.84: icmp_seq=2 ttl=48 time=90.166 ms
64 bytes from 169.228.34.84: icmp_seq=3 ttl=48 time=90.180 ms
64 bytes from 169.228.34.84: icmp_seq=4 ttl=48 time=82.058 ms
64 bytes from 169.228.34.84: icmp_seq=5 ttl=48 time=83.595 ms
^C
--- 169.228.34.84 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 82.058/86.391/90.180/3.067 ms
marconi#
```
But suppose I try to `ping` an external IPv4 address from a machine
inside of my subnet. Then those messages seem to be dropped. E.g.,
dumping on the encap interface:
```
tcpdump: listening on gif1, link-type LOOP
15:51:46.955189 44.44.48.29 > 142.250.80.4: icmp: echo request
(id:cf3d seq:507) [icmp cksum ok] (ttl 254, id 62634, len 84)
15:51:46.975585 44.44.48.29.34992 > 152.70.159.102.123: [udp sum ok]
v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref
(unspec)(a)0.000000000 orig 0.000000000 rec -0.000000000 xmt
-501608111.378157913 [tos 0x10] (ttl 63, id 42418, len 76)
15:51:47.955108 44.44.48.29 > 142.250.80.4: icmp: echo request
(id:cf3d seq:508) [icmp cksum ok] (ttl 254, id 6160, len 84)
15:51:48.953556 44.44.48.29 > 142.250.80.4: icmp: echo request
(id:cf3d seq:509) [icmp cksum ok] (ttl 254, id 5705, len 84)
15:51:49.955095 44.44.48.29 > 142.250.80.4: icmp: echo request
(id:cf3d seq:510) [icmp cksum ok] (ttl 254, id 38617, len 84)
15:51:50.955135 44.44.48.29 > 142.250.80.4: icmp: echo request
(id:cf3d seq:511) [icmp cksum ok] (ttl 254, id 13652, len 84)
15:51:51.953550 44.44.48.29 > 142.250.80.4: icmp: echo request
(id:cf3d seq:512) [icmp cksum ok] (ttl 254, id 15767, len 84)
^C
8 packets received by filter
0 packets dropped by kernel
```
(Note: the UDP packet is just an NTP request on the machine that
happens to be running `ping`, but it's unrelated.)
I can see that such packets are being routed out of my external
interface, while properly encapsulated. e.g.,
```
tcpdump: listening on cnmac1, link-type EN10MB
15:52:14.955137 23.30.150.141 > 169.228.34.84: 44.44.48.29 >
142.250.80.4: icmp: echo request (id:cf3d seq:535) (ttl 254, id 35282,
len 84) (ttl 64, id 61599, len 104)
15:52:15.335038 35.203.211.24.57286 > 23.30.150.141.999: S [tcp sum
ok] 4102707815:4102707815(0) win 65535 <mss 1460> [tos 0x20] (ttl 56,
id 54321, len 44)
15:52:15.335165 23.30.150.141.999 > 35.203.211.24.57286: R [bad tcp
cksum a4a9! -> d8a0] 0:0(0) ack 4102707816 win 0 (DF) [tos 0x10] (ttl
64, id 61784, len 40)
15:52:15.955143 23.30.150.141 > 169.228.34.84: 44.44.48.29 >
142.250.80.4: icmp: echo request (id:cf3d seq:536) (ttl 254, id 27600,
len 84) (ttl 64, id 37135, len 104)
15:52:16.955121 23.30.150.141 > 169.228.34.84: 44.44.48.29 >
142.250.80.4: icmp: echo request (id:cf3d seq:537) (ttl 254, id 62216,
len 84) (ttl 64, id 5987, len 104)
15:52:17.025154 23.30.150.141 > 169.228.34.84: 44.44.48.29.6711 >
152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist
0.000000 disp 0.000000 ref (unspec)(a)0.000000000 orig 0.000000000 rec
-0.000000000 xmt +824494743.794610023 [tos 0x10] (ttl 63, id 64906,
len 76) [tos 0x10] (ttl 64, id 14623, len 96)
15:52:17.955195 23.30.150.141 > 169.228.34.84: 44.44.48.29 >
142.250.80.4: icmp: echo request (id:cf3d seq:538) (ttl 254, id 59942,
len 84) (ttl 64, id 39191, len 104)
^C
20 packets received by filter
0 packets dropped by kernel
```
However, if I try to `ping` a machine I own elsewhere on the network
where I can run `tcpdump`, the traffic never seems to get there.
Further, I can `ping` my external interface from elsewhere on the
network. That all appears to be working. IPv6 works, so I'm fairly
confident in e.g. my firewall rules and so on.
Curiously, I am receiving RIP packets from 44.0.0.1 on the multicast
group, and I can `ping` other machines inside the AMPRNet mesh, but
this all strongly implies that the UCSD gateway is dropping traffic to
and from my subnet.
Is that expected? Thanks!
- Dan C. (KZ2X)
All,
I did some work on restoring my netflow collectors - and the first thing I noticed was the NTP server ns.ardc.net is giving me an error. It seems that it does not allow queries from our Gateway Public IPs as AMPRGW previously did. This provides a chicken-or-the-egg issue on some of my configs if any time-based services are needed (i.e. if I only rely on ns.ardc.net for time). This could be a serious issue if e.g. tunnels were switched to Wireguard (i.e. needing time for encryption).
A SK (I will not name) frowned upon NTP via IPENCAP for obvious reasons (I hope the DNS discussions make clear that a UDP NTP packet with latency or delays from 2 rounds trips is BAD).
I'm looking into the implications for myself and possibly for others by not considering this before the change was made. I'm now working on routes/rules to make an exception for this IP; but it will require some testing as this would be on my main (non-AMPRNet) routing table, which is BAD.
I haven't taken time to determine if this will cause issues for other use cases. I am still run the Stratum 2 server for those who may realize that they are no longer syncing only on AMRPNet's NTP services.
IP: 44.60.44.1Hostname: kb3vwg-001.ampr.orgAccess Policy: (123/udp open to 44net and Public GW IPs)
73,
LynwoodKB3VWG
Hi folks,
In addition to helping to ideally clarify some of the questions that
have come up on the mailing list, given the tone of some of the recent
communications, it seems prudent to remind this group of ARDC’s Code of
Conduct:
https://www.ardc.net/about/legal/code-of-conduct/
The policy outlines examples of unacceptable behavior, the process for
dealing with incident reports, as well as varying types of outcomes.
It is true that the new Portal rollout has caused some confusion, and I
completely understand the frustration that comes with it. At the same
time, ARDC is committed to facilitating a “supportive, productive, and
fun learning environment.” Before sending an email, I ask that everyone
pause, breathe, and re-read, looking for opportunities to remove
language that could be considered accusatory, hostile, or aggressive.
Our goal is to solve problems together, and flaming the fires of
division impedes progress in that direction.
Thank you for your attention,
Rosy
--
Rosy Schechter - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ardc.net
Hi everyone,
Just a note to say QSL on many of the recent messages, as well as to
provide some information that hopefully addresses some of the inquiries
and concerns.
In particular, there are many questions about what regional coordinators
can and cannot do with the new portal, as well as requests for more
clarity surrounding the Level of Trust (LoT).
At a high level, here are some brief updates about each of those items:
1. One of the biggest concerns we have heard from coordinators is that
they are not able to administer their address space on the new Portal.
Specifically, members report that they are unable to place requests for
address space in the regional/country allocations. The new portal
defaults to keeping address assignments private, however you can enable
requests by changing the network’s “Mode” from “Private” to “Open,” this
will allow members to place requests within the assignment. If anyone
requires further information on how to manage this, please contact:
newportal(a)ardc.net.
2. As many of you have pointed out, having a single person administering
the Portal also creates a bottleneck. Additionally, it creates a single
point of failure. The new Portal has the facility to assign tasks to
various Administrator roles to address this issue.
3. The Level of Trust (LoT) was established so that we at ARDC can
better ensure a user’s identity with a significant degree of confidence.
In general, there are two major categories: 1) BGP users and 2) non-BGP
users (i.e., “everyone else”). As there is a greater risk associated
with BGP, a higher LoT is required, and thus, more information will be
required for BGP allocations.
For non-BGP users (/25 addresses and smaller), we only verify your email
address, given name, family name, and active call signs. BGP usage
requires additional postal address verification, which takes a few more
steps. Many thanks to BGP users, in particular, for your patience here.
With the Portal and with 44Net in general – the goal is to do what we
can to increase usage and to make our technology better. We're also
evolving as an organization, which means evolving processes to become
more collaborative and streamlined in everything from policy development
to tech releases. We still have some way to go to reach an optimal
state. It's difficult to get there without hitting some snags and bumps,
particularly when working with dozens of intelligent people with varying
ideas about the “right” way to build something. We are committed to
getting there, and we are already learning lessons from this experience
that will make the next rollout better.
In the meantime, to anyone who feels like they aren’t being heard,
please know that you are. We are taking this feedback seriously for
future features and processes.
We’ll also follow up with regional coordinators to find a time for a
group discussion in the coming weeks.
Please also note – as some of you have likely seen – we are down a key
employee due to him becoming SK:
https://www.ardc.net/remembering-john-hays-k7ve-sk/
We had another employee depart a couple of weeks before John’s death.
The loss of these two people means a loss of 20% of our staff. As a
result, we are unexpectedly working through things more slowly than we
would like. I ask everyone for patience while we get our feet back under
us and restaff (which will take at least a couple of months).
I hope this message helps to clarify where we’re at. As always, if you
have any questions and/or would like further clarification, please don’t
hesitate to reach out, and we will help as much as we can. Thank you
again to everyone for your patience, and we also appreciate the
productive components of the feedback received.
73,
Rosy KJ7RYV
--
Rosy Schechter - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ardc.net
# Summary
Given that DNS has been a popular topic of discussion lately, I
thought it might be useful to try and put some words about it on the
Wiki. In preparation for this, I was playing around with the recursive
DNS server on my subnet, and I ran into some strange behavior that I
don't understand; perhaps someone else knows what's going on? To my
eye, it looks like some types of PTR queries are being dropped at or
before AMPRGW; this behavior is repeatable.
# Setup and Context
* I have a machine on my allocated subnet (44.44.48.29) that is
running a recursive, caching DNS server (that is, a resolver).
* The resolver is configured with stub zones that forward requests for
ampr.org, 44.in-addr.arpa and 128.44.in-addr.arpa to the authoritative
servers for those zones listed on the Wiki
* The resolver is configured to respond to requests issued over both
IPv4 and IPv6
* Machines on my subnet are configured to query this server.
* I have configured my firewall to allow access to the `domain` port
(e.g., UDP/53) on that machine from a few places on the Internet ---
but not all.
# Observations
What I observe is inconsistent, but repeatable, failures when issuing
PTR queries for certain IP addresses via IPv4 from the external
Internet.
* Forward queries from all sources seem to work fine. At least, I
haven't observed any that fail (other than for, say, non-existent
hostnames).
* Similarly, PTR queries issued from the hosts on my subnet all seem
to work as expected.
* PTR queries issued over IPv6 seem to work fine from any source.
* PTR queries issued over IPv4 from other networks locally connected
to my home network (I have several ethernets and TCP/IP networks at
home, interconnected with a set of routers and switches) all seem to
work fine.
* PTR queries for _some_ IP addresses issued over IPv4 from external
machines on the Internet work reliably. For example, I can reliably
query for 44.1.1.44, 44.0.0.1, 127.0.0.1, and 8.8.8.8 and I don't
believe I've ever seen any of these queries fail.
* PTR queries for _most_ 44Net IP addresses issued over IPv4 from
external machines on the Internet fail reliably. For example, I
cannot query for 44.44.48.1 (my gateway), or 44.182.21.1 (YO2LOJ's
machine). I don't believe I have ever seen any of these queries
succeed.
Note that the only thing that differs in the last two cases is the
address I'm trying to resolve.
Now the interesting part. For the failing queries, I've observed that
the actual query traffic _never makes it to my gateway from UCSD_.
That is, the encapsulated datagram carrying the UDP packet containing
the query never makes it to the external gateway.
I issued these queries with the `host` tool.
To verify this, I ran `tcpdump` in several places:
1. At the source machine where I issued the DNS queries:
tcpdump -vvn host 44.44.48.29
2. On my gateway, examining the encapsulated traffic on the external interface:
tcpdump -vvni cnmac1 ip proto 4 and 'ip[29:1] == 17 and (ip[42:2]
== 53 or ip[40:2] == 53)'
(Note the `ip[...]` expressions are matching in the encapsulated
IP and UDP headers.)
3. On the DNS server machine itself:
tcpdump -vvn udp port domain or tcp port domain
To verify that everything is working as expected, first I issue a
successful forward query:
```
: gaja; host -4 kz2x.ampr.orgsrv.kz2x.ampr.org
Using domain server:
Name: srv.kz2x.ampr.org
Address: 44.44.48.29#53
Aliases:
kz2x.ampr.org has address 44.44.48.2
kz2x.ampr.org has IPv6 address 2603:3005:b04:8144:48:edff:fe9c:c00
: gaja;
```
Note that the query succeeded (the astute reader may notice that
that's missing an MX record, but ignore that for now), but let's look
at the `tcpdump` output at each stage just to see what it looks like.
Note that the data is in my cache, so I omit the details of recursive
queries down to the roots, etc.
From the local machine where I issue the query, one sees:
```
20:07:31.444583 166.84.136.80.35777 > 44.44.48.29.53: [udp sum ok]
32707+ A? kz2x.ampr.org.(31) (ttl 64, id 18835, len 59)
20:07:31.603276 44.44.48.29.53 > 166.84.136.80.35777: [udp sum ok]
32707* q: A? kz2x.ampr.org. 1/0/0 kz2x.ampr.org. A 44.44.48.2(47) (ttl
40, id 12176, len 75)
20:07:31.605932 166.84.136.80.22717 > 44.44.48.29.53: [udp sum ok]
7616+ AAAA? kz2x.ampr.org.(31) (ttl 64, id 58081, len 59)
20:07:31.761378 44.44.48.29.53 > 166.84.136.80.22717: [udp sum ok]
7616* q: AAAA? kz2x.ampr.org. 1/0/0 kz2x.ampr.org. AAAA
2603:3005:b04:8144:48:edff:fe9c:c00(59) (ttl 40, id 62606, len 87)
20:07:31.762560 166.84.136.80.28977 > 44.44.48.29.53: [udp sum ok]
58832+ MX? kz2x.ampr.org.(31) (ttl 64, id 41619, len 59)
20:07:31.911483 44.44.48.29.53 > 166.84.136.80.28977: 58832* q: MX?
kz2x.ampr.org. 0/1/0 ns: kz2x.ampr.org. SOA[|domain] (ttl 40, id
37627, len 110)
```
From the external interface on my AMPRNet gateway machine, I see:
20:07:31.523609 169.228.34.84 > 23.30.150.141: 166.84.136.80.35777 >
44.44.48.29.53: [udp sum ok] 32707+ A? kz2x.ampr.org.(31) [tos 0x28]
(ttl 49, id 18835, len 59) (ttl 48, id 486, len 79)
20:07:31.524290 23.30.150.141 > 169.228.34.84: 44.44.48.29.53 >
166.84.136.80.35777: [udp sum ok] 32707* q: A? kz2x.ampr.org. 1/0/0
kz2x.ampr.org. A 44.44.48.2(47) (ttl 63, id 12176, len 75) (ttl 64, id
12041, len 95)
20:07:31.683608 169.228.34.84 > 23.30.150.141: 166.84.136.80.22717 >
44.44.48.29.53: [udp sum ok] 7616+ AAAA? kz2x.ampr.org.(31) [tos 0x28]
(ttl 49, id 58081, len 59) (ttl 48, id 6515, len 79)
20:07:31.684262 23.30.150.141 > 169.228.34.84: 44.44.48.29.53 >
166.84.136.80.22717: 7616* q: AAAA? kz2x.ampr.org. 1/0/0
kz2x.ampr.org. AAAA[|domain] (ttl 63, id 62606, len 87) (ttl 64, id
48275, len 107)
20:07:31.836445 169.228.34.84 > 23.30.150.141: 166.84.136.80.28977 >
44.44.48.29.53: [udp sum ok] 58832+ MX? kz2x.ampr.org.(31) [tos 0x28]
(ttl 49, id 41619, len 59) (ttl 48, id 6629, len 79)
20:07:31.837067 23.30.150.141 > 169.228.34.84: 44.44.48.29.53 >
166.84.136.80.28977: 58832* q: MX? kz2x.ampr.org. 0/1/0 ns:
kz2x.ampr.org. SOA[|domain] (ttl 63, id 37627, len 110) (ttl 64, id
12165, len 130)
And on the DNS server machine itself:
```
20:07:31.520610 166.84.136.80.35777 > 44.44.48.29.53: [udp sum ok]
32707+ A? kz2x.ampr.org.(31) [tos 0x28] (ttl 48, id 44358, len 59)
20:07:31.520796 44.44.48.29.53 > 166.84.136.80.35777: [udp sum ok]
32707* q: A? kz2x.ampr.org. 1/0/0 kz2x.ampr.org. A 44.44.48.2(47) (ttl
64, id 33360, len 75)
20:07:31.680599 166.84.136.80.22717 > 44.44.48.29.53: [udp sum ok]
7616+ AAAA? kz2x.ampr.org.(31) [tos 0x28] (ttl 48, id 23293, len 59)
20:07:31.680766 44.44.48.29.53 > 166.84.136.80.22717: [udp sum ok]
7616* q: AAAA? kz2x.ampr.org. 1/0/0 kz2x.ampr.org. AAAA
2603:3005:b04:8144:48:edff:fe9c:c00(59) (ttl 64, id 31261, len 87)
20:07:31.833404 166.84.136.80.28977 > 44.44.48.29.53: [udp sum ok]
58832+ MX? kz2x.ampr.org.(31) [tos 0x28] (ttl 48, id 44916, len 59)
20:07:31.833578 44.44.48.29.53 > 166.84.136.80.28977: 58832* q: MX?
kz2x.ampr.org. 0/1/0 ns: kz2x.ampr.org. SOA[|domain] (ttl 64, id
28444, len 110)
```
These results are all expected. Similarly for a successful reverse query:
```
: gaja; host -4 44.1.1.44 srv.kz2x.ampr.org
Using domain server:
Name: srv.kz2x.ampr.org
Address: 44.44.48.29#53
Aliases:
44.1.1.44.in-addr.arpa domain name pointer ns.ardc.net.
: gaja;
```
As seen from the source host:
```
20:13:37.445021 166.84.136.80.4339 > 44.44.48.29.53: [udp sum ok]
61470+ PTR? 44.1.1.44.in-addr.arpa.(40) (ttl 64, id 34902, len 68)
20:13:37.609712 44.44.48.29.53 > 166.84.136.80.4339: [udp sum ok]
61470 q: PTR? 44.1.1.44.in-addr.arpa. 1/0/0 44.1.1.44.in-addr.arpa.
PTR ns.ardc.net.(65) (ttl 40, id 15635, len 93)
```
From the gateway:
```
20:13:37.523609 169.228.34.84 > 23.30.150.141: 166.84.136.80.4339 >
44.44.48.29.53: [udp sum ok] 61470+ PTR? 44.1.1.44.in-addr.arpa.(40)
[tos 0x28] (ttl 49, id 34902, len 68) (ttl 48, id 13407, len 88)
20:13:37.533691 23.30.150.141 > 169.228.34.84: 44.44.48.29.53 >
166.84.136.80.4339: 61470 q: PTR? 44.1.1.44.in-addr.arpa. 1/0/0
44.1.1.44.in-addr.arpa. PTR[|domain] (ttl 63, id 15635, len 93) (ttl
64, id 52552, len 113)
```
And at the DNS server:
```
20:13:37.520500 166.84.136.80.4339 > 44.44.48.29.53: [udp sum ok]
61470+ PTR? 44.1.1.44.in-addr.arpa.(40) [tos 0x28] (ttl 48, id 22620,
len 68)
20:13:37.520691 44.44.48.29.53 > 166.84.136.80.4339: [udp sum ok]
61470 q: PTR? 44.1.1.44.in-addr.arpa. 1/0/0 44.1.1.44.in-addr.arpa.
PTR ns.ardc.net.(65) (ttl 64, id 59842, len 93)
```
Okay, but what about a failing query? Let's try one:
```
: gaja; host -4 44.44.48.29 srv.kz2x.ampr.org
;; connection timed out; no servers could be reached
: gaja;
```
Uh oh. As seen from the source host:
```
20:15:26.775880 166.84.136.80.29535 > 44.44.48.29.53: [udp sum ok]
39502+ PTR? 29.48.44.44.in-addr.arpa.(42) (ttl 64, id 59475, len 70)
20:15:27.776870 166.84.136.80.29535 > 44.44.48.29.53: [udp sum ok]
39502+ PTR? 29.48.44.44.in-addr.arpa.(42) (ttl 64, id 40687, len 70)
```
But at the gateway, nothing at all is seen; no relevant data is
received from the AMPRGW, and of course, similarly at the DNS server
as well.
So it appears that these queries are being lost, either at AMPRGW or
before. Has anyone seen this before? Is it expected?
- Dan C.
