6 May
2024
6 May
'24
3:18 a.m.
# 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.org srv.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.
6 May
6 May
3:37 a.m.
—
Dave K9DC, K9IP
On May 5, 2024, at 16:18, Dan Cross via 44net
<44net(a)mailman.ampr.org> wrote:
* 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.
They work fine using any public nameserver.
dave@Dave-MBPMax:~$ dig @1.1.1.1 -x 44.44.48.1
; <<>> DiG 9.10.6 <<>> @1.1.1.1 -x 44.44.48.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51161
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 12 ("..")
;; QUESTION SECTION:
;1.48.44.44.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.48.44.44.in-addr.arpa. 300 IN PTR gw.kz2x.ampr.org.
; <<>> DiG 9.10.6 <<>> @1.1.1.1 -x 44.182.21.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42212
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 12 ("..")
;; QUESTION SECTION:
;1.21.182.44.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.21.182.44.in-addr.arpa. 300 IN PTR yo2tm.ampr.org.
5 a.m.
Dan,
Yes - the archives show we experienced packet loss in November 2020 and began to discuss
it on the reflector. The losses were mostly UDP.
If I understand the issue you describe, any of us can help you test by running tcpdump on
our tunl0 interface to determine if we receive 'PTR?' packets thru AMPRGW from
your public IP, correct?
tcpdump -vvvn -i tunl0 udp and port 53 and host 44.60.44.3 and host xxx.xxx.xxx.xxx
where xxx.xxx.xxx.xxx == a Public IP
73,
LynwoodKB3VWG
I have seen various failures in the past.
I have one theory. Some administrators blacklist the 44 space.
On Sunday, May 5, 2024 at 04:42:33 PM EDT, Dan Cross via 44net
<44net(a)mailman.ampr.org> wrote:
On Sun, May 5, 2024 at 4:38 PM Dave Gingrich <dave(a)dcg.us> wrote:
They work fine using any public nameserver.
Sure! But that wasn’t the question. ;-) The question is about queries directed to a
specific server not transiting AMPRGW.
- Dan C.
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
6:13 a.m.
On Sun, May 5, 2024 at 6:00 PM lleachii(a)aol.com <lleachii(a)aol.com> wrote:
Dan,
Yes - the archives show we experienced packet loss in November 2020 and began to discuss
it on the reflector. The losses were mostly UDP.
Interesting.
What's curious about this (to me, anyway) is that it's not _just_
packet loss, but (seemingly?) only loss of very specific packets. If
the problem were just random UDP packet loss, I'd expect some of the
queries that I observe to always succeed to occasionally fail, while
some of those that always seem to fail would occasionally succeed.
Instead, I see repeatable patterns of success and failure. Indeed, I
can alternate queries between succeeding and failure and the results
are very consistent.
Curiously, in between my original message and now, some queries
started working (consistently!) while others still consistently fail.
Also, just as a data point, the note about UDP reminded me that I
ought to test over TCP, and that works reliably for every case that I
tried.
If I understand the issue you describe, any of us can
help you test by running tcpdump on our tunl0 interface to determine if we receive
'PTR?' packets thru AMPRGW from your public IP, correct?
tcpdump -vvvn -i tunl0 udp and port 53 and host 44.60.44.3 and host xxx.xxx.xxx.xxx
where xxx.xxx.xxx.xxx == a Public IP
I think that's right; I've been running tests from 166.84.136.80. I
just tried to send a couple of queries to `dns-mdc.ampr.org` but got
no response.
I have seen various failures in the past.
I have one theory. Some administrators blacklist the 44 space.
If that were the case, I'd expect all success or all failure, or some
random combination of success and failure.
But instead, I see very specific success and failure cases, with no
discernable pattern to what works and what doesn't. It doesn't appear
to be totally random, nor is it an all-or-nothing sort of thing.
I can think of a few possibilities/questions.
1. Are these packets even making it to the upstream side of AMPRGW? I
have no way of knowing, really, and it's possible AMPRGW never sees
them. But why just these packets containing these specific PTR
queries? I suspect most of them arrive at UCSD upstream, but don't get
passed.
2. Does AMPRGW block incoming DNS requests to non-authoritative
servers? Or maybe there's an allowlist somewhere I'm not on? This
seems unlikely; first, no one seems to know anything about that and
I'd figure that they would if that sort of thing existed. Second, if
that were the case, I'd suspect all DNS queries to fail, or at least
all of a specific type (e.g., all `PTR?` queries or something like
that). But that doesn't fit the observed data.
3. Could it be that AMPRGW is doing some kind of deep packet
inspection and filtering queries that match certain, specific,
filters? I find this hard to believe; from what I know of AMPRGW
(which admittedly isn't THAT much, mostly reading between the lines of
old posts by Brian Kantor), I just don't think it's that kind of
system.
What seems more likely to me is that there's something specific, but
incidental, about the packets containing these queries that's tickling
AMPRGW in just the right way that it's dropping them. I looked at the
various stat files on gw.ampr.org/private, but nothing sticks out to
me as obvious.
Thanks again for the response, Lynwood.
- Dan C.
On Sunday, May 5, 2024 at 04:42:33 PM EDT, Dan Cross
via 44net <44net(a)mailman.ampr.org> wrote:
On Sun, May 5, 2024 at 4:38 PM Dave Gingrich <dave(a)dcg.us> wrote:
They work fine using any public nameserver.
Sure! But that wasn’t the question. ;-) The question is about queries directed to a
specific server not transiting AMPRGW.
- Dan C.
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
6:29 a.m.
Dan,
- I'm now running tcpdump on your SRC IP
- I normally don't allow DNS queries from the Public - so I've now allowed your
SRP IP for testing (53/udp)
I agree it's odd only certain packets "upset" AMPRGW. Test now, and I'll
provide my results.
- KB3VWG
On Sunday, May 5, 2024 at 07:14:31 PM EDT, Dan Cross <crossd(a)gmail.com> wrote:
On Sun, May 5, 2024 at 6:00 PM lleachii(a)aol.com <lleachii(a)aol.com> wrote:
Dan,
Yes - the archives show we experienced packet loss in November 2020 and began to discuss
it on the reflector. The losses were mostly UDP.
Interesting.
What's curious about this (to me, anyway) is that it's not _just_
packet loss, but (seemingly?) only loss of very specific packets. If
the problem were just random UDP packet loss, I'd expect some of the
queries that I observe to always succeed to occasionally fail, while
some of those that always seem to fail would occasionally succeed.
Instead, I see repeatable patterns of success and failure. Indeed, I
can alternate queries between succeeding and failure and the results
are very consistent.
Curiously, in between my original message and now, some queries
started working (consistently!) while others still consistently fail.
Also, just as a data point, the note about UDP reminded me that I
ought to test over TCP, and that works reliably for every case that I
tried.
If I understand the issue you describe, any of us can
help you test by running tcpdump on our tunl0 interface to determine if we receive
'PTR?' packets thru AMPRGW from your public IP, correct?
tcpdump -vvvn -i tunl0 udp and port 53 and host 44.60.44.3 and host xxx.xxx.xxx.xxx
where xxx.xxx.xxx.xxx == a Public IP
I think that's right; I've been running tests from 166.84.136.80. I
just tried to send a couple of queries to `dns-mdc.ampr.org` but got
no response.
I have seen various failures in the past.
I have one theory. Some administrators blacklist the 44 space.
If that were the case, I'd expect all success or all failure, or some
random combination of success and failure.
But instead, I see very specific success and failure cases, with no
discernable pattern to what works and what doesn't. It doesn't appear
to be totally random, nor is it an all-or-nothing sort of thing.
I can think of a few possibilities/questions.
1. Are these packets even making it to the upstream side of AMPRGW? I
have no way of knowing, really, and it's possible AMPRGW never sees
them. But why just these packets containing these specific PTR
queries? I suspect most of them arrive at UCSD upstream, but don't get
passed.
2. Does AMPRGW block incoming DNS requests to non-authoritative
servers? Or maybe there's an allowlist somewhere I'm not on? This
seems unlikely; first, no one seems to know anything about that and
I'd figure that they would if that sort of thing existed. Second, if
that were the case, I'd suspect all DNS queries to fail, or at least
all of a specific type (e.g., all `PTR?` queries or something like
that). But that doesn't fit the observed data.
3. Could it be that AMPRGW is doing some kind of deep packet
inspection and filtering queries that match certain, specific,
filters? I find this hard to believe; from what I know of AMPRGW
(which admittedly isn't THAT much, mostly reading between the lines of
old posts by Brian Kantor), I just don't think it's that kind of
system.
What seems more likely to me is that there's something specific, but
incidental, about the packets containing these queries that's tickling
AMPRGW in just the right way that it's dropping them. I looked at the
various stat files on gw.ampr.org/private, but nothing sticks out to
me as obvious.
Thanks again for the response, Lynwood.
- Dan C.
On Sunday, May 5, 2024 at 04:42:33 PM EDT, Dan Cross
via 44net <44net(a)mailman.ampr.org> wrote:
On Sun, May 5, 2024 at 4:38 PM Dave Gingrich <dave(a)dcg.us> wrote:
They work fine using any public nameserver.
Sure! But that wasn’t the question. ;-) The question is about queries directed to a
specific server not transiting AMPRGW.
- Dan C.
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
6:50 a.m.
On Sun, May 5, 2024 at 7:29 PM lleachii(a)aol.com <lleachii(a)aol.com> wrote:
I'm now running tcpdump on your SRC IP
I normally don't allow DNS queries from the Public - so I've now allowed your SRP
IP for testing (53/udp)
I agree it's odd only certain packets "upset" AMPRGW. Test now, and
I'll provide my results.
Thanks, Lynwood. The results largely mirror my own:
```
: gaja; host -4 44.44.48.1 44.60.44.3
;; connection timed out; no servers could be reached
: gaja; host -4 44.44.48.10 44.60.44.3
Using domain server:
Name: 44.60.44.3
Address: 44.60.44.3#53
Aliases:
10.48.44.44.in-addr.arpa domain name pointer tops20.kz2x.ampr.org.
: gaja; host -4 44.1.1.44 44.60.44.3
Using domain server:
Name: 44.60.44.3
Address: 44.60.44.3#53
Aliases:
44.1.1.44.in-addr.arpa domain name pointer ns.ardc.net.
: gaja; host -4 44.44.0.1 44.60.44.3
Using domain server:
Name: 44.60.44.3
Address: 44.60.44.3#53
Aliases:
1.0.44.44.in-addr.arpa domain name pointer gw.hamgatema.ampr.org.
: gaja; host -4 44.44.48.9 44.60.44.3
;; connection timed out; no servers could be reached
: gaja;
```
(I sent a few other queries, as well.)
It sure seems like the packet contents are getting hashed somewhere,
and a few bits difference one way or the other is a big determinant of
what gets through.
- Dan C.
On Sun, May 5, 2024 at 6:00 PM lleachii(a)aol.com
<lleachii(a)aol.com> wrote:
Dan,
Yes - the archives show we experienced packet loss in November 2020 and began to discuss
it on the reflector. The losses were mostly UDP.
Interesting.
What's curious about this (to me, anyway) is that it's not _just_
packet loss, but (seemingly?) only loss of very specific packets. If
the problem were just random UDP packet loss, I'd expect some of the
queries that I observe to always succeed to occasionally fail, while
some of those that always seem to fail would occasionally succeed.
Instead, I see repeatable patterns of success and failure. Indeed, I
can alternate queries between succeeding and failure and the results
are very consistent.
Curiously, in between my original message and now, some queries
started working (consistently!) while others still consistently fail.
Also, just as a data point, the note about UDP reminded me that I
ought to test over TCP, and that works reliably for every case that I
tried.
If I understand the issue you describe, any of us
can help you test by running tcpdump on our tunl0 interface to determine if we receive
'PTR?' packets thru AMPRGW from your public IP, correct?
tcpdump -vvvn -i tunl0 udp and port 53 and host 44.60.44.3 and host xxx.xxx.xxx.xxx
where xxx.xxx.xxx.xxx == a Public IP
I think that's right; I've been running tests from 166.84.136.80. I
just tried to send a couple of queries to `dns-mdc.ampr.org` but got
no response.
I have seen various failures in the past.
I have one theory. Some administrators blacklist the 44 space.
If that were the case, I'd expect all success or all failure, or some
random combination of success and failure.
But instead, I see very specific success and failure cases, with no
discernable pattern to what works and what doesn't. It doesn't appear
to be totally random, nor is it an all-or-nothing sort of thing.
I can think of a few possibilities/questions.
1. Are these packets even making it to the upstream side of AMPRGW? I
have no way of knowing, really, and it's possible AMPRGW never sees
them. But why just these packets containing these specific PTR
queries? I suspect most of them arrive at UCSD upstream, but don't get
passed.
2. Does AMPRGW block incoming DNS requests to non-authoritative
servers? Or maybe there's an allowlist somewhere I'm not on? This
seems unlikely; first, no one seems to know anything about that and
I'd figure that they would if that sort of thing existed. Second, if
that were the case, I'd suspect all DNS queries to fail, or at least
all of a specific type (e.g., all `PTR?` queries or something like
that). But that doesn't fit the observed data.
3. Could it be that AMPRGW is doing some kind of deep packet
inspection and filtering queries that match certain, specific,
filters? I find this hard to believe; from what I know of AMPRGW
(which admittedly isn't THAT much, mostly reading between the lines of
old posts by Brian Kantor), I just don't think it's that kind of
system.
What seems more likely to me is that there's something specific, but
incidental, about the packets containing these queries that's tickling
AMPRGW in just the right way that it's dropping them. I looked at the
various stat files on gw.ampr.org/private, but nothing sticks out to
me as obvious.
Thanks again for the response, Lynwood.
- Dan C.
> On Sunday, May 5, 2024 at 04:42:33 PM EDT, Dan Cross via 44net
<44net(a)mailman.ampr.org> wrote:
>
>
> On Sun, May 5, 2024 at 4:38 PM Dave Gingrich <dave(a)dcg.us> wrote:
>
> They work fine using any public nameserver.
>
>
> Sure! But that wasn’t the question. ;-) The question is about queries directed to a
specific server not transiting AMPRGW.
>
> - Dan C.
>
>
> _______________________________________________
> 44net mailing list -- 44net(a)mailman.ampr.org
> To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
6:59 a.m.
Dan,
Yea, odd. I never received the queries that show as timed out on your output (i.e. never
forwarded to me by AMPRGW):
root@OpenWrt:~# tcpdump -vvvn -i tunl0 host 44.60.44.3 and host 166.84.136.80tcpdump:
listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes23:44:17.337340 IP
(tos 0x28, ttl 49, id 27212, offset 0, flags [DF], proto TCP (6), length 64)
166.84.136.80.25518 > 44.60.44.3.53: Flags [S], cksum 0xe682 (correct), seq 686979005,
win 16384, options [mss 1460,nop,nop,sackOK,nop,wscale 6,nop,nop,TS val 1088111398 ecr 0],
length 023:44:24.168207 IP (tos 0x28, ttl 49, id 43802, offset 0, flags [none], proto UDP
(17), length 66) 166.84.136.80.16498 > 44.60.44.3.53: [udp sum ok] 5807+ PTR?
8.8.8.8.in-addr.arpa. (38)23:44:24.581889 IP (tos 0x0, ttl 63, id 32318, offset 0, flags
[none], proto UDP (17), length 90) 44.60.44.3.53 > 166.84.136.80.16498: [udp sum ok]
5807 q: PTR? 8.8.8.8.in-addr.arpa. 1/0/0 8.8.8.8.in-addr.arpa. [1d] PTR dns.google. (62)
23:44:46.903062 IP (tos 0x28, ttl 49, id
60097, offset 0, flags [none], proto UDP (17), length 70)
166.84.136.80.30975 >
44.60.44.3.53: [udp sum ok] 2214+ PTR? 10.48.44.44.in-addr.arpa. (42)
23:44:46.910643 IP
(tos 0x0, ttl 63, id 35006, offset 0, flags [none], proto UDP (17), length 104)
44.60.44.3.53 > 166.84.136.80.30975: [udp sum ok] 2214* q: PTR?
10.48.44.44.in-addr.arpa. 1/0/0 10.48.44.44.in-addr.arpa. [5m] PTR tops20.kz2x.ampr.org.
(76) 23:46:47.357818 IP (tos 0x28, ttl 49, id 20737, offset 0,
flags [none], proto UDP (17), length 70)
166.84.136.80.4397 > 44.60.44.3.53: [udp
sum ok] 29354+ PTR? 10.48.44.44.in-addr.arpa. (42)
23:46:47.363206 IP (tos 0x0, ttl 63,
id 49394, offset 0, flags [none], proto UDP (17), length 104)
44.60.44.3.53 >
166.84.136.80.4397: [udp sum ok] 29354* q: PTR? 10.48.44.44.in-addr.arpa. 1/0/0
10.48.44.44.in-addr.arpa. [5m] PTR tops20.kz2x.ampr.org. (76)
23:47:05.189580 IP (tos 0x28, ttl 49, id 42467, offset 0, flags [none], proto UDP (17),
length 68)
166.84.136.80.17824 > 44.60.44.3.53: [udp sum ok] 64416+ PTR?
44.1.1.44.in-addr.arpa. (40)
23:47:05.197534 IP (tos 0x0, ttl 63, id 52687, offset 0,
flags [none], proto UDP (17), length 93)
44.60.44.3.53 > 166.84.136.80.17824: [udp
sum ok] 64416* q: PTR? 44.1.1.44.in-addr.arpa. 1/0/0 44.1.1.44.in-addr.arpa. [1m] PTR
ns.ardc.net. (65) 23:47:13.291538 IP (tos 0x28, ttl
49, id 38510, offset 0, flags [none], proto UDP (17), length 68)
166.84.136.80.8044
> 44.60.44.3.53: [udp sum ok] 48056+ PTR? 1.0.44.44.in-addr.arpa. (40)
23:47:13.296700 IP (tos 0x0, ttl 63, id 53664, offset 0, flags [none], proto UDP (17),
length 103)
44.60.44.3.53 > 166.84.136.80.8044: [udp sum ok] 48056* q: PTR?
1.0.44.44.in-addr.arpa. 1/0/0 1.0.44.44.in-addr.arpa. [5m] PTR gw.hamgatema.ampr.org.
(75) 23:49:42.234256 IP (tos 0x28, ttl 49, id 6829, offset
0, flags [none], proto UDP (17), length 70)
166.84.136.80.13216 > 44.60.44.3.53:
[udp sum ok] 28034+ PTR? 1.21.182.44.in-addr.arpa. (42)
23:49:42.240120 IP (tos 0x0, ttl
63, id 5372, offset 0, flags [none], proto UDP (17), length 98)
44.60.44.3.53 >
166.84.136.80.13216: [udp sum ok] 28034* q: PTR? 1.21.182.44.in-addr.arpa. 1/0/0
1.21.182.44.in-addr.arpa. [5m] PTR yo2tm.ampr.org. (70)
On Sunday, May 5, 2024 at 07:50:48 PM EDT, Dan Cross <crossd(a)gmail.com> wrote:
On Sun, May 5, 2024 at 7:29 PM lleachii(a)aol.com <lleachii(a)aol.com> wrote:
I'm now running tcpdump on your SRC IP
I normally don't allow DNS queries from the Public - so I've now allowed your SRP
IP for testing (53/udp)
I agree it's odd only certain packets "upset" AMPRGW. Test now, and
I'll provide my results.
Thanks, Lynwood. The results largely mirror my own:
```
: gaja; host -4 44.44.48.1 44.60.44.3
;; connection timed out; no servers could be reached
: gaja; host -4 44.44.48.10 44.60.44.3
Using domain server:
Name: 44.60.44.3
Address: 44.60.44.3#53
Aliases:
10.48.44.44.in-addr.arpa domain name pointer tops20.kz2x.ampr.org.
: gaja; host -4 44.1.1.44 44.60.44.3
Using domain server:
Name: 44.60.44.3
Address: 44.60.44.3#53
Aliases:
44.1.1.44.in-addr.arpa domain name pointer ns.ardc.net.
: gaja; host -4 44.44.0.1 44.60.44.3
Using domain server:
Name: 44.60.44.3
Address: 44.60.44.3#53
Aliases:
1.0.44.44.in-addr.arpa domain name pointer gw.hamgatema.ampr.org.
: gaja; host -4 44.44.48.9 44.60.44.3
;; connection timed out; no servers could be reached
: gaja;
```
(I sent a few other queries, as well.)
It sure seems like the packet contents are getting hashed somewhere,
and a few bits difference one way or the other is a big determinant of
what gets through.
- Dan C.
On Sun, May 5, 2024 at 6:00 PM lleachii(a)aol.com
<lleachii(a)aol.com> wrote:
Dan,
Yes - the archives show we experienced packet loss in November 2020 and began to discuss
it on the reflector. The losses were mostly UDP.
Interesting.
What's curious about this (to me, anyway) is that it's not _just_
packet loss, but (seemingly?) only loss of very specific packets. If
the problem were just random UDP packet loss, I'd expect some of the
queries that I observe to always succeed to occasionally fail, while
some of those that always seem to fail would occasionally succeed.
Instead, I see repeatable patterns of success and failure. Indeed, I
can alternate queries between succeeding and failure and the results
are very consistent.
Curiously, in between my original message and now, some queries
started working (consistently!) while others still consistently fail.
Also, just as a data point, the note about UDP reminded me that I
ought to test over TCP, and that works reliably for every case that I
tried.
If I understand the issue you describe, any of us
can help you test by running tcpdump on our tunl0 interface to determine if we receive
'PTR?' packets thru AMPRGW from your public IP, correct?
tcpdump -vvvn -i tunl0 udp and port 53 and host 44.60.44.3 and host xxx.xxx.xxx.xxx
where xxx.xxx.xxx.xxx == a Public IP
I think that's right; I've been running tests from 166.84.136.80. I
just tried to send a couple of queries to `dns-mdc.ampr.org` but got
no response.
I have seen various failures in the past.
I have one theory. Some administrators blacklist the 44 space.
If that were the case, I'd expect all success or all failure, or some
random combination of success and failure.
But instead, I see very specific success and failure cases, with no
discernable pattern to what works and what doesn't. It doesn't appear
to be totally random, nor is it an all-or-nothing sort of thing.
I can think of a few possibilities/questions.
1. Are these packets even making it to the upstream side of AMPRGW? I
have no way of knowing, really, and it's possible AMPRGW never sees
them. But why just these packets containing these specific PTR
queries? I suspect most of them arrive at UCSD upstream, but don't get
passed.
2. Does AMPRGW block incoming DNS requests to non-authoritative
servers? Or maybe there's an allowlist somewhere I'm not on? This
seems unlikely; first, no one seems to know anything about that and
I'd figure that they would if that sort of thing existed. Second, if
that were the case, I'd suspect all DNS queries to fail, or at least
all of a specific type (e.g., all `PTR?` queries or something like
that). But that doesn't fit the observed data.
3. Could it be that AMPRGW is doing some kind of deep packet
inspection and filtering queries that match certain, specific,
filters? I find this hard to believe; from what I know of AMPRGW
(which admittedly isn't THAT much, mostly reading between the lines of
old posts by Brian Kantor), I just don't think it's that kind of
system.
What seems more likely to me is that there's something specific, but
incidental, about the packets containing these queries that's tickling
AMPRGW in just the right way that it's dropping them. I looked at the
various stat files on gw.ampr.org/private, but nothing sticks out to
me as obvious.
Thanks again for the response, Lynwood.
- Dan C.
> On Sunday, May 5, 2024 at 04:42:33 PM EDT, Dan Cross via 44net
<44net(a)mailman.ampr.org> wrote:
>
>
> On Sun, May 5, 2024 at 4:38 PM Dave Gingrich <dave(a)dcg.us> wrote:
>
> They work fine using any public nameserver.
>
>
> Sure! But that wasn’t the question. ;-) The question is about queries directed to a
specific server not transiting AMPRGW.
>
> - Dan C.
>
>
> _______________________________________________
> 44net mailing list -- 44net(a)mailman.ampr.org
> To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
7:04 a.m.
[-explicit Cc to Dave, +Cc to Chris]
On Sun, May 5, 2024 at 8:00 PM lleachii(a)aol.com <lleachii(a)aol.com> wrote:
Yea, odd. I never received the queries that show as
timed out on your output (i.e. never forwarded to me by AMPRGW):
Thanks for confirming, Lynwood. Your results match what I saw on my
AMPRNet gateway, as well.
That two different hosts are showing the same results strengthens the
argument that it's something upstream of both of us; in this case, the
obvious culprit is AMPRGW (though of course it could be something
between my VPS and AMPRGW, but I think that's unlikely for the reasons
I mentioned in my previous email).
Chris, any ideas here?
- Dan C.
root@OpenWrt:~# tcpdump -vvvn -i tunl0 host
44.60.44.3 and host 166.84.136.80
tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes
23:44:17.337340 IP (tos 0x28, ttl 49, id 27212, offset 0, flags [DF], proto TCP (6),
length 64)
166.84.136.80.25518 > 44.60.44.3.53: Flags [S], cksum 0xe682 (correct), seq
686979005, win 16384, options [mss 1460,nop,nop,sackOK,nop,wscale 6,nop,nop,TS val
1088111398 ecr 0], length 0
23:44:24.168207 IP (tos 0x28, ttl 49, id 43802, offset 0, flags [none], proto UDP (17),
length 66)
166.84.136.80.16498 > 44.60.44.3.53: [udp sum ok] 5807+ PTR? 8.8.8.8.in-addr.arpa.
(38)
23:44:24.581889 IP (tos 0x0, ttl 63, id 32318, offset 0, flags [none], proto UDP (17),
length 90)
44.60.44.3.53 > 166.84.136.80.16498: [udp sum ok] 5807 q: PTR?
8.8.8.8.in-addr.arpa. 1/0/0 8.8.8.8.in-addr.arpa. [1d] PTR dns.google. (62)
23:44:46.903062 IP (tos 0x28, ttl 49, id 60097, offset 0, flags [none], proto UDP (17),
length 70)
166.84.136.80.30975 > 44.60.44.3.53: [udp sum ok] 2214+ PTR?
10.48.44.44.in-addr.arpa. (42)
23:44:46.910643 IP (tos 0x0, ttl 63, id 35006, offset 0, flags [none], proto UDP (17),
length 104)
44.60.44.3.53 > 166.84.136.80.30975: [udp sum ok] 2214* q: PTR?
10.48.44.44.in-addr.arpa. 1/0/0 10.48.44.44.in-addr.arpa. [5m] PTR tops20.kz2x.ampr.org.
(76)
23:46:47.357818 IP (tos 0x28, ttl 49, id 20737, offset 0, flags [none], proto UDP (17),
length 70)
166.84.136.80.4397 > 44.60.44.3.53: [udp sum ok] 29354+ PTR?
10.48.44.44.in-addr.arpa. (42)
23:46:47.363206 IP (tos 0x0, ttl 63, id 49394, offset 0, flags [none], proto UDP (17),
length 104)
44.60.44.3.53 > 166.84.136.80.4397: [udp sum ok] 29354* q: PTR?
10.48.44.44.in-addr.arpa. 1/0/0 10.48.44.44.in-addr.arpa. [5m] PTR tops20.kz2x.ampr.org.
(76)
23:47:05.189580 IP (tos 0x28, ttl 49, id 42467, offset 0, flags [none], proto UDP (17),
length 68)
166.84.136.80.17824 > 44.60.44.3.53: [udp sum ok] 64416+ PTR?
44.1.1.44.in-addr.arpa. (40)
23:47:05.197534 IP (tos 0x0, ttl 63, id 52687, offset 0, flags [none], proto UDP (17),
length 93)
44.60.44.3.53 > 166.84.136.80.17824: [udp sum ok] 64416* q: PTR?
44.1.1.44.in-addr.arpa. 1/0/0 44.1.1.44.in-addr.arpa. [1m] PTR ns.ardc.net. (65)
23:47:13.291538 IP (tos 0x28, ttl 49, id 38510, offset 0, flags [none], proto UDP (17),
length 68)
166.84.136.80.8044 > 44.60.44.3.53: [udp sum ok] 48056+ PTR?
1.0.44.44.in-addr.arpa. (40)
23:47:13.296700 IP (tos 0x0, ttl 63, id 53664, offset 0, flags [none], proto UDP (17),
length 103)
44.60.44.3.53 > 166.84.136.80.8044: [udp sum ok] 48056* q: PTR?
1.0.44.44.in-addr.arpa. 1/0/0 1.0.44.44.in-addr.arpa. [5m] PTR gw.hamgatema.ampr.org.
(75)
23:49:42.234256 IP (tos 0x28, ttl 49, id 6829, offset 0, flags [none], proto UDP (17),
length 70)
166.84.136.80.13216 > 44.60.44.3.53: [udp sum ok] 28034+ PTR?
1.21.182.44.in-addr.arpa. (42)
23:49:42.240120 IP (tos 0x0, ttl 63, id 5372, offset 0, flags [none], proto UDP (17),
length 98)
44.60.44.3.53 > 166.84.136.80.13216: [udp sum ok] 28034* q: PTR?
1.21.182.44.in-addr.arpa. 1/0/0 1.21.182.44.in-addr.arpa. [5m] PTR yo2tm.ampr.org. (70)
On Sunday, May 5, 2024 at 07:50:48 PM EDT, Dan Cross <crossd(a)gmail.com> wrote:
On Sun, May 5, 2024 at 7:29 PM lleachii(a)aol.com <lleachii(a)aol.com> wrote:
I'm now running tcpdump on your SRC IP
I normally don't allow DNS queries from the Public - so I've now allowed your SRP
IP for testing (53/udp)
I agree it's odd only certain packets "upset" AMPRGW. Test now, and
I'll provide my results.
Thanks, Lynwood. The results largely mirror my own:
```
: gaja; host -4 44.44.48.1 44.60.44.3
;; connection timed out; no servers could be reached
: gaja; host -4 44.44.48.10 44.60.44.3
Using domain server:
Name: 44.60.44.3
Address: 44.60.44.3#53
Aliases:
10.48.44.44.in-addr.arpa domain name pointer tops20.kz2x.ampr.org.
: gaja; host -4 44.1.1.44 44.60.44.3
Using domain server:
Name: 44.60.44.3
Address: 44.60.44.3#53
Aliases:
44.1.1.44.in-addr.arpa domain name pointer ns.ardc.net.
: gaja; host -4 44.44.0.1 44.60.44.3
Using domain server:
Name: 44.60.44.3
Address: 44.60.44.3#53
Aliases:
1.0.44.44.in-addr.arpa domain name pointer gw.hamgatema.ampr.org.
: gaja; host -4 44.44.48.9 44.60.44.3
;; connection timed out; no servers could be reached
: gaja;
```
(I sent a few other queries, as well.)
It sure seems like the packet contents are getting hashed somewhere,
and a few bits difference one way or the other is a big determinant of
what gets through.
- Dan C.
> On Sun, May 5, 2024 at 6:00 PM lleachii(a)aol.com <lleachii(a)aol.com> wrote:
> > Dan,
> >
> > Yes - the archives show we experienced packet loss in November 2020 and began
to discuss it on the reflector. The losses were mostly UDP.
>
> Interesting.
>
> What's curious about this (to me, anyway) is that it's not _just_
> packet loss, but (seemingly?) only loss of very specific packets. If
> the problem were just random UDP packet loss, I'd expect some of the
> queries that I observe to always succeed to occasionally fail, while
> some of those that always seem to fail would occasionally succeed.
> Instead, I see repeatable patterns of success and failure. Indeed, I
> can alternate queries between succeeding and failure and the results
> are very consistent.
>
> Curiously, in between my original message and now, some queries
> started working (consistently!) while others still consistently fail.
> Also, just as a data point, the note about UDP reminded me that I
> ought to test over TCP, and that works reliably for every case that I
> tried.
>
> > If I understand the issue you describe, any of us can help you test by running
tcpdump on our tunl0 interface to determine if we receive 'PTR?' packets thru
AMPRGW from your public IP, correct?
> >
> > tcpdump -vvvn -i tunl0 udp and port 53 and host 44.60.44.3 and host
xxx.xxx.xxx.xxx
> >
> > where xxx.xxx.xxx.xxx == a Public IP
>
> I think that's right; I've been running tests from 166.84.136.80. I
> just tried to send a couple of queries to `dns-mdc.ampr.org` but got
> no response.
>
> > I have seen various failures in the past.
> >
> > I have one theory. Some administrators blacklist the 44 space.
>
> If that were the case, I'd expect all success or all failure, or some
> random combination of success and failure.
>
> But instead, I see very specific success and failure cases, with no
> discernable pattern to what works and what doesn't. It doesn't appear
> to be totally random, nor is it an all-or-nothing sort of thing.
>
> I can think of a few possibilities/questions.
>
> 1. Are these packets even making it to the upstream side of AMPRGW? I
> have no way of knowing, really, and it's possible AMPRGW never sees
> them. But why just these packets containing these specific PTR
> queries? I suspect most of them arrive at UCSD upstream, but don't get
> passed.
> 2. Does AMPRGW block incoming DNS requests to non-authoritative
> servers? Or maybe there's an allowlist somewhere I'm not on? This
> seems unlikely; first, no one seems to know anything about that and
> I'd figure that they would if that sort of thing existed. Second, if
> that were the case, I'd suspect all DNS queries to fail, or at least
> all of a specific type (e.g., all `PTR?` queries or something like
> that). But that doesn't fit the observed data.
> 3. Could it be that AMPRGW is doing some kind of deep packet
> inspection and filtering queries that match certain, specific,
> filters? I find this hard to believe; from what I know of AMPRGW
> (which admittedly isn't THAT much, mostly reading between the lines of
> old posts by Brian Kantor), I just don't think it's that kind of
> system.
>
> What seems more likely to me is that there's something specific, but
> incidental, about the packets containing these queries that's tickling
> AMPRGW in just the right way that it's dropping them. I looked at the
> various stat files on gw.ampr.org/private, but nothing sticks out to
> me as obvious.
>
> Thanks again for the response, Lynwood.
>
> - Dan C.
>
>
>
> > On Sunday, May 5, 2024 at 04:42:33 PM EDT, Dan Cross via 44net
<44net(a)mailman.ampr.org> wrote:
> >
> >
> > On Sun, May 5, 2024 at 4:38 PM Dave Gingrich <dave(a)dcg.us> wrote:
> >
> > They work fine using any public nameserver.
> >
> >
> > Sure! But that wasn’t the question. ;-) The question is about queries directed
to a specific server not transiting AMPRGW.
> >
> > - Dan C.
> >
> >
> > _______________________________________________
> > 44net mailing list -- 44net(a)mailman.ampr.org
> > To unsubscribe send an email to 44net-leave(a)mailman.ampr.org 
7 May
7 May
9:34 a.m.
I tried to resolve 44.44.48.1 and 44.182.21.1 who never resolve you said
Using your dns 44.44.48.29, they resolve without problem
$host -4 44.44.48.1 44.44.48.29
Using domain server:
Name: 44.44.48.29
Address: 44.44.48.29#53
Aliases:
1.48.44.44.in-addr.arpa domain name pointer gw.kz2x.ampr.org.
host -4 44.182.21.1 44.44.48.29
Using domain server:
Name: 44.44.48.29
Address: 44.44.48.29#53
Aliases:
1.21.182.44.in-addr.arpa domain name pointer yo2tm.ampr.org.
73,
Bob VE3TOK
On 2024-05-05 16:18, Dan Cross via 44net wrote:
# 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.org srv.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.
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
--
There is nothing permanent except change
-Heraclitus
229
days inactive
231
days old
9 comments
4 participants
participants (4)
-
Boudewijn (Bob) Tenty -
Dan Cross -
Dave Gingrich -
lleachii＠aol.com