api.weather.gov DNS resolution hangs through pihole

Help Community Help
1

The issue I am facing:

DNS lookups for api.weather.gov are failing. dig/nslookup hang when trying to resolve the domain through pihole.

For example the following command never returns, I have to ctrl^c it.

dig api.weather.gov
;; Truncated, retrying in TCP mode.
;; communications error to 192.168.8.2#53: end of file

In my pihole logs I see:

Nov  9 15:34:59 dnsmasq[313]: query[A] api.weather.gov from 192.168.14.197
Nov  9 15:34:59 dnsmasq[313]: forwarded api.weather.gov to 192.168.0.1
Nov  9 15:34:59 dnsmasq[313]: dnssec-query[DNSKEY] weather.gov to 192.168.0.1
Nov  9 15:34:59 dnsmasq[313]: reply weather.gov is truncated[DNSKEY]
Nov  9 15:34:59 dnsmasq[313]: validation result is TRUNCATED
Nov  9 15:34:59 dnsmasq[313]: reply is truncated
Nov  9 15:34:59 dnsmasq[63387]: query[A] api.weather.gov from 192.168.14.197

This is causing a bunch of log spam and DB growth due to Home Assistant constantly trying to resolve the domain which results in huge floods of logs like:

Nov  9 15:35:04 dnsmasq[63392]: query[A] api.weather.gov from 192.168.0.72
Nov  9 15:35:04 dnsmasq[313]: query[NS] . from 192.168.0.72
Nov  9 15:35:04 dnsmasq[313]: forwarded . to 192.168.0.1
Nov  9 15:35:04 dnsmasq[313]: validation result is SECURE
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[63394]: query[A] api.weather.gov from 192.168.0.72
Nov  9 15:35:04 dnsmasq[313]: query[NS] . from 192.168.0.72
Nov  9 15:35:04 dnsmasq[313]: forwarded . to 192.168.0.1
Nov  9 15:35:04 dnsmasq[313]: validation result is SECURE
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[313]: reply . is <NS>
Nov  9 15:35:04 dnsmasq[63396]: query[A] api.weather.gov from 192.168.0.72
Nov  9 15:35:04 dnsmasq[313]: query[NS] . from 192.168.0.72

Changing my DNS resolver to my router (to use ISP DNS) works just fine

~ nslookup
> server 192.168.0.1
Default server: 192.168.0.1
Address: 192.168.0.1#53
> api.weather.gov
Server:		192.168.0.1
Address:	192.168.0.1#53

Non-authoritative answer:
api.weather.gov	canonical name = sancert.weather.gov.edgekey.net.
sancert.weather.gov.edgekey.net	canonical name = e278.dscg.akamaiedge.net.
Name:	e278.dscg.akamaiedge.net
Address: 23.197.100.19

Details about my system:

I'm running two piholes in a primary/secondary DNS setup. Both exhibit the same failure when trying to resolve this specific domain.

Debug logs: https://tricorder.pi-hole.net/nu97hUVn/
Docker Config: pihole docker compose · GitHub

What I have changed since installing Pi-hole:

Not sure what changed, I noticed this because DNS resolution was failing due to SHM errors as my pihole-FTL.db had grown to over 3GiB. I've increased the SHM allocated to the docker container and dropped my stats retention down to 28 days to address the knock-on performance issue.

2

Trying from nslookup on ubuntu vs osx I get a slightly "better" failure mode:

nslookup
> weather.gov
;; Truncated, retrying in TCP mode.
;; communications error to 192.168.8.2#53: end of file
;; communications error to 192.168.8.2#53: end of file
;; communications error to 192.168.8.2#53: end of file
;; communications error to 192.168.8.3#53: end of file
;; no servers could be reached

This seems to happen for all weather.gov related domains

3

Another bit of digging makes me think the root cause here was an update to my UDM-SE yesterday to v8.6.9

If I do dig @192.168.0.1 +tcp DNSKEY +dnssec weather.gov it just hangs.

If I do the same command against my ISP's DNS server dig @192.152.0.1 +tcp DNSKEY +dnssec weather.gov it works.

I have my pihole's set up to just use my router as upstream DNS so that it just passes through the the ISP. Changing that to hard-code my ISP's DNS in the pihole fixes the weather.gov lookups

4

Could you post your Docker compose/YAML/run command here pls?
Sounds like 53 UDP is not coming through somewhere:

ports:
  - "53:53/tcp"
  - "53:53/udp"

https://github.com/pi-hole/docker-pi-hole#quick-start

Also check if firewall rules on the router have changed?

Ps. there is no need to post the full debug log here that can contain private details!
Select "Upload" when you run the debugger and it will return a token URL after the upload process that can be posted here.
Only the devs/mods have access and the log gets purged after 48h.

EDIT: Oh below connects/test via TCP only:

dig +tcp ...

And below one via UDP only:

dig +notcp ...

You could also try if lowering sending packet size to 512 bytes does come through (in case UDP max packet size is limmited somewhere upstream or on the return path):

dig +noedns ...

Eg (10.0.0.4 = Pi-hole):

$ dig +notcp +noedns @10.0.0.4 pi.hole

; <<>> DiG 9.18.24-1-Debian <<>> +notcp +noedns @10.0.0.4 pi.hole
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57972
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;pi.hole.                       IN      A

;; ANSWER SECTION:
pi.hole.                2       IN      A       10.0.0.4

;; Query time: 3 msec
;; SERVER: 10.0.0.4#53(10.0.0.4) (UDP)
;; WHEN: Sat Nov 09 20:15:14 CET 2024
;; MSG SIZE  rcvd: 41

Above the answer is 41 bytes which should easily fit in a single 512 bytes UDP packet before truncating happens via TCP.

EDIT2: Oh if I query your troubled domain, the answer is 129 bytes which should still fit in a single 512 byte UDP packet:

$ dig +notcp +noedns @10.0.0.4 api.weather.gov
[..]
;; MSG SIZE  rcvd: 129

At Google:

$ dig +notcp +noedns @8.8.8.8 api.weather.gov
[..]
;; MSG SIZE  rcvd: 129
5

Oh blast, above I was wrongly assuming it going wrong for A record lookups but its the DNSKEY record lookup going wrong.
You should narrow your search down to below dnskey lookup via UDP only:

dig +notcp @192.168.0.1 weather.gov. dnskey

And against whatever addresses you've configured in the router for upstream DNS (Internet/WAN DNS settings).

6

FYI, truncating via TCP usually happens if there is no reply from upstream via UDP.
Which could be bc the answer doesnt fit in a single UDP packet.
Or something to/from upstream is limiting UDP packet size.
Or a firewall or network misconfiguration :wink:

In that case, the client DNS implementation repeats the same query again only this time via TCP which allows the answer to be split up/fragmented in multiple TCP packets which isn't possible via UDP.
Or at least, the (dated) DNS implementation doesnt support reconstructing fragmented UDP packets like modern software nowadays can.
Only fragmented TCP packets can be reconstructed into an answer.

7

Updated my original post with the docker config and the debug link, I had posted a manually redacted log because I wasn't familiar with the dev/moderator only debug feature, thats handy.

The container is running in host-only mode, it is the only container on the rPi.

notcp works:

dig +notcp @192.168.0.1 weather.gov. dnskey

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +notcp @192.168.0.1 weather.gov. dnskey
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61943
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;weather.gov.			IN	DNSKEY

;; ANSWER SECTION:
weather.gov.		7012	IN	DNSKEY	256 3 8 AwEAAcWSKBOx84Dyr2cfAV5DIhdLuCv1+z59gMmXsHUrXjv6VT6fskd0 8eLUgwu5soZ9deiWTJO3YOaZ90w/NAmi4UPYQH/c/qFZF5zpV/6CgJun cDs5uF1LMOtUOuXtB4B237xEdxUbDto/uyoZ7J1bVW+v2E+DtUR3sJix p4OnFKAJ
weather.gov.		7012	IN	DNSKEY	256 3 8 AwEAAcgiUp99sZO0YeyU/ymtCQ6Y3jDOBf0oL4gUv9t+4KXJBXZkQes1 VMhx287J6YbqFbDiJya2Lq0CF9c401fVSeeIrHMrn8ed+cectJioI8MA WtbWqxwFxbTxx+kvcxhKN8IaM6jwlFhOOVTg5QUmq0Zb1vuOHvpTrtRu YqS9ci/N
weather.gov.		7012	IN	DNSKEY	257 3 8 AwEAAeJ8o1o+vidSOKS9AeFPhVLShcwttH5RqvAxPhfqEGvsk3PGY73L kxuh/tCtJf799340d98CeNnlQhjEZL/sTtArBEezavNZJINN78PpwdjY Y71gSKRxACfUSQpRQTTNag28SDemEALUKqYOB16AhJr9wUr8WBPyq9S3 pPQG1Iy82cp/dMrHp/tN0InY88xNOZ2Vkzg1HCg/XxFOZYLyHJcaQca1 +ax1fttAImkhnak+G2MV7y0LizBWOQr8pXEro4BcNwYPonlYwwWlQhMd oYBhJLkm1aUZkX7IPATRABsjDTlml3Asn7tKRSYiKQpsI5IaT7m5sB7i TG847LKpqvE=
weather.gov.		7012	IN	DNSKEY	257 3 8 AwEAAcQUtFoZy5/pGqGctz6JyRhQUs9oAT95dtYgKvLPQoCbw3SfFs9N kT5xEmFtzwvf2cIJebnS6GjBW2Zujr+b4uNfN9SCouechVolcYUyyQUc A49+IRqI3PC0djqgQs59/fq6etmAEimEuCea3a+Xi8UnlP643ITFhAs3 ++d/ytmt0lxKOBaCpmxTGsyXv71lRUHvhcehNJoY2gv8kJpZuhbO/bWn gw6uHOFgZKoJuK0XztIhYfpgfGoT0jQcl2OI6NOoAiAd3TBqls7139ZV k7VYEoBZRrvXNwjylactB/GFyKN4AziAT3JeURA2xZhQxlXJVcYwFMIy FFb+Bf6Mcfc=

;; Query time: 5 msec
;; SERVER: 192.168.0.1#53(192.168.0.1) (UDP)
;; WHEN: Sat Nov 09 16:18:27 PST 2024
;; MSG SIZE  rcvd: 888

tcp hangs

dig +tcp @192.168.0.1 weather.gov. dnskey
;; Connection to 192.168.0.1#53(192.168.0.1) for weather.gov. failed: timed out.
;; no servers could be reached

noedns falls back correctly

dig +noedns 192.168.0.1 weather.gov. dnskey

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +noedns 192.168.0.1 weather.gov. dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10484
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;192.168.0.1.			IN	A

;; AUTHORITY SECTION:
.			2694	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2024110901 1800 900 604800 86400

;; Query time: 1 msec
;; SERVER: 192.168.8.2#53(192.168.8.2) (UDP)
;; WHEN: Sat Nov 09 16:19:27 PST 2024
;; MSG SIZE  rcvd: 104

;; Truncated, retrying in TCP mode.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48303
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;weather.gov.			IN	DNSKEY

;; ANSWER SECTION:
weather.gov.		6952	IN	DNSKEY	256 3 8 AwEAAcgiUp99sZO0YeyU/ymtCQ6Y3jDOBf0oL4gUv9t+4KXJBXZkQes1 VMhx287J6YbqFbDiJya2Lq0CF9c401fVSeeIrHMrn8ed+cectJioI8MA WtbWqxwFxbTxx+kvcxhKN8IaM6jwlFhOOVTg5QUmq0Zb1vuOHvpTrtRu YqS9ci/N
weather.gov.		6952	IN	DNSKEY	257 3 8 AwEAAeJ8o1o+vidSOKS9AeFPhVLShcwttH5RqvAxPhfqEGvsk3PGY73L kxuh/tCtJf799340d98CeNnlQhjEZL/sTtArBEezavNZJINN78PpwdjY Y71gSKRxACfUSQpRQTTNag28SDemEALUKqYOB16AhJr9wUr8WBPyq9S3 pPQG1Iy82cp/dMrHp/tN0InY88xNOZ2Vkzg1HCg/XxFOZYLyHJcaQca1 +ax1fttAImkhnak+G2MV7y0LizBWOQr8pXEro4BcNwYPonlYwwWlQhMd oYBhJLkm1aUZkX7IPATRABsjDTlml3Asn7tKRSYiKQpsI5IaT7m5sB7i TG847LKpqvE=
weather.gov.		6952	IN	DNSKEY	257 3 8 AwEAAcQUtFoZy5/pGqGctz6JyRhQUs9oAT95dtYgKvLPQoCbw3SfFs9N kT5xEmFtzwvf2cIJebnS6GjBW2Zujr+b4uNfN9SCouechVolcYUyyQUc A49+IRqI3PC0djqgQs59/fq6etmAEimEuCea3a+Xi8UnlP643ITFhAs3 ++d/ytmt0lxKOBaCpmxTGsyXv71lRUHvhcehNJoY2gv8kJpZuhbO/bWn gw6uHOFgZKoJuK0XztIhYfpgfGoT0jQcl2OI6NOoAiAd3TBqls7139ZV k7VYEoBZRrvXNwjylactB/GFyKN4AziAT3JeURA2xZhQxlXJVcYwFMIy FFb+Bf6Mcfc=
weather.gov.		6952	IN	DNSKEY	256 3 8 AwEAAcWSKBOx84Dyr2cfAV5DIhdLuCv1+z59gMmXsHUrXjv6VT6fskd0 8eLUgwu5soZ9deiWTJO3YOaZ90w/NAmi4UPYQH/c/qFZF5zpV/6CgJun cDs5uF1LMOtUOuXtB4B237xEdxUbDto/uyoZ7J1bVW+v2E+DtUR3sJix p4OnFKAJ

;; Query time: 24 msec
;; SERVER: 192.168.8.2#53(192.168.8.2) (TCP)
;; WHEN: Sat Nov 09 16:19:27 PST 2024
;; MSG SIZE  rcvd: 877

The issue seems to 100% be in the Unifi UDM-SE. When I try these queries directly against the UDM-SE (192.168.0.1) or the PiHole when it's upstream is the UDM-SE they fail in the same ways.

When querying my ISP's DNS servers directly or PiHole where it is configured to use the ISP DNS servers things work just fine.

To be clear, I've figured out this is NOT an issue with PiHole but with the Unifi gear.

1 Like
8

Forget below!
I noticed you made a typo above.
Its missing the @ before the 192.168.0.1 IP :smiley:

Whats strange for above lookup is that the initial UDP query is not answered by the 192.168.0.1 IP but instead by below 192.168.8.2 IP:

Same for the follow up TCP query when truncating kicks in bc the answer exceeds the 512 bytes limit (I assume):

Do you have any ideas whats going on?
Some kind of DNS redirecting?

Could check router settings for DNS redirect settings or similar.
Some routers call it "DNS filter".

9

:man_facepalming:

noedns times out against the USG-SE as well.

$ dig +noedns @192.168.0.1 weather.gov. dnskey
;; Truncated, retrying in TCP mode.
;; Connection to 192.168.0.1#53(192.168.0.1) for weather.gov. failed: timed out.
;; no servers could be reached

;; Connection to 192.168.0.1#53(192.168.0.1) for weather.gov. failed: timed out.
;; no servers could be reached

;; Connection to 192.168.0.1#53(192.168.0.1) for weather.gov. failed: timed out.
;; no servers could be reached

So the only variant that works is explicitly disabling TCP.

I have the "DNS Shield" and "Ad Block" features disabled on the USG-SE, nothing else should be touching DNS as far as I can find. If I find time I'll downgrade the USG and see if it resolves things.

10

What if you run the +tcp lookup against the routers configured upstream DNS server(s)?
The ones in the WAN/Internet DNS settings.

EDIT: Not sure if you tried that below:

And maybe also check below bit:

11

No DNS filtering of any kind set up on the router.

ISP DNS servers respond just fine:

$ dig +tcp @192.152.0.1 weather.gov. dnskey

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +tcp @192.152.0.1 weather.gov. dnskey
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18051
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;weather.gov.			IN	DNSKEY

;; ANSWER SECTION:
weather.gov.		7200	IN	DNSKEY	256 3 8 AwEAAcWSKBOx84Dyr2cfAV5DIhdLuCv1+z59gMmXsHUrXjv6VT6fskd0 8eLUgwu5soZ9deiWTJO3YOaZ90w/NAmi4UPYQH/c/qFZF5zpV/6CgJun cDs5uF1LMOtUOuXtB4B237xEdxUbDto/uyoZ7J1bVW+v2E+DtUR3sJix p4OnFKAJ
weather.gov.		7200	IN	DNSKEY	257 3 8 AwEAAeJ8o1o+vidSOKS9AeFPhVLShcwttH5RqvAxPhfqEGvsk3PGY73L kxuh/tCtJf799340d98CeNnlQhjEZL/sTtArBEezavNZJINN78PpwdjY Y71gSKRxACfUSQpRQTTNag28SDemEALUKqYOB16AhJr9wUr8WBPyq9S3 pPQG1Iy82cp/dMrHp/tN0InY88xNOZ2Vkzg1HCg/XxFOZYLyHJcaQca1 +ax1fttAImkhnak+G2MV7y0LizBWOQr8pXEro4BcNwYPonlYwwWlQhMd oYBhJLkm1aUZkX7IPATRABsjDTlml3Asn7tKRSYiKQpsI5IaT7m5sB7i TG847LKpqvE=
weather.gov.		7200	IN	DNSKEY	257 3 8 AwEAAcQUtFoZy5/pGqGctz6JyRhQUs9oAT95dtYgKvLPQoCbw3SfFs9N kT5xEmFtzwvf2cIJebnS6GjBW2Zujr+b4uNfN9SCouechVolcYUyyQUc A49+IRqI3PC0djqgQs59/fq6etmAEimEuCea3a+Xi8UnlP643ITFhAs3 ++d/ytmt0lxKOBaCpmxTGsyXv71lRUHvhcehNJoY2gv8kJpZuhbO/bWn gw6uHOFgZKoJuK0XztIhYfpgfGoT0jQcl2OI6NOoAiAd3TBqls7139ZV k7VYEoBZRrvXNwjylactB/GFyKN4AziAT3JeURA2xZhQxlXJVcYwFMIy FFb+Bf6Mcfc=
weather.gov.		7200	IN	DNSKEY	256 3 8 AwEAAcgiUp99sZO0YeyU/ymtCQ6Y3jDOBf0oL4gUv9t+4KXJBXZkQes1 VMhx287J6YbqFbDiJya2Lq0CF9c401fVSeeIrHMrn8ed+cectJioI8MA WtbWqxwFxbTxx+kvcxhKN8IaM6jwlFhOOVTg5QUmq0Zb1vuOHvpTrtRu YqS9ci/N

;; Query time: 69 msec
;; SERVER: 192.152.0.1#53(192.152.0.1) (TCP)
;; WHEN: Sun Nov 10 15:36:03 PST 2024
;; MSG SIZE  rcvd: 888

$ dig +noedns @192.152.0.1 weather.gov. dnskey
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +noedns @192.152.0.1 weather.gov. dnskey
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55537
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;weather.gov.			IN	DNSKEY

;; ANSWER SECTION:
weather.gov.		7129	IN	DNSKEY	257 3 8 AwEAAeJ8o1o+vidSOKS9AeFPhVLShcwttH5RqvAxPhfqEGvsk3PGY73L kxuh/tCtJf799340d98CeNnlQhjEZL/sTtArBEezavNZJINN78PpwdjY Y71gSKRxACfUSQpRQTTNag28SDemEALUKqYOB16AhJr9wUr8WBPyq9S3 pPQG1Iy82cp/dMrHp/tN0InY88xNOZ2Vkzg1HCg/XxFOZYLyHJcaQca1 +ax1fttAImkhnak+G2MV7y0LizBWOQr8pXEro4BcNwYPonlYwwWlQhMd oYBhJLkm1aUZkX7IPATRABsjDTlml3Asn7tKRSYiKQpsI5IaT7m5sB7i TG847LKpqvE=
weather.gov.		7129	IN	DNSKEY	257 3 8 AwEAAcQUtFoZy5/pGqGctz6JyRhQUs9oAT95dtYgKvLPQoCbw3SfFs9N kT5xEmFtzwvf2cIJebnS6GjBW2Zujr+b4uNfN9SCouechVolcYUyyQUc A49+IRqI3PC0djqgQs59/fq6etmAEimEuCea3a+Xi8UnlP643ITFhAs3 ++d/ytmt0lxKOBaCpmxTGsyXv71lRUHvhcehNJoY2gv8kJpZuhbO/bWn gw6uHOFgZKoJuK0XztIhYfpgfGoT0jQcl2OI6NOoAiAd3TBqls7139ZV k7VYEoBZRrvXNwjylactB/GFyKN4AziAT3JeURA2xZhQxlXJVcYwFMIy FFb+Bf6Mcfc=
weather.gov.		7129	IN	DNSKEY	256 3 8 AwEAAcgiUp99sZO0YeyU/ymtCQ6Y3jDOBf0oL4gUv9t+4KXJBXZkQes1 VMhx287J6YbqFbDiJya2Lq0CF9c401fVSeeIrHMrn8ed+cectJioI8MA WtbWqxwFxbTxx+kvcxhKN8IaM6jwlFhOOVTg5QUmq0Zb1vuOHvpTrtRu YqS9ci/N
weather.gov.		7129	IN	DNSKEY	256 3 8 AwEAAcWSKBOx84Dyr2cfAV5DIhdLuCv1+z59gMmXsHUrXjv6VT6fskd0 8eLUgwu5soZ9deiWTJO3YOaZ90w/NAmi4UPYQH/c/qFZF5zpV/6CgJun cDs5uF1LMOtUOuXtB4B237xEdxUbDto/uyoZ7J1bVW+v2E+DtUR3sJix p4OnFKAJ

;; Query time: 4 msec
;; SERVER: 192.152.0.1#53(192.152.0.1) (TCP)
;; WHEN: Sun Nov 10 15:37:14 PST 2024
;; MSG SIZE  rcvd: 877
12

Ok, that narrows it down a bit.
Still have no clue :wink:

EDIT: Oh I figured out you cant use both +tcp and +noedns at the same time.
The +noedns argument always tries via UDP first before switching to TCP.
At least thats what I observe (tcpdump).

Oops, +noedns +tcp does TCP first.
Was lookin at wrong session :wink:

sudo tcpdump -ntvi any port 53

13

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.