HTTPS (Type 65) queries regularly return neither answers nor SOA in response

Help
1

Expected Behaviour:

HTTPS/Type 65 queries sometimes return no data, and sometimes return a CNAME from upstream servers.
Expected behavior (determined by comparing 8.8.8.8 responses in wireshark) would be to always reply with a SOA record in the reply, and also return the associated CNAME record returned from upstream when available. Wireshark shows this not happening reliably. I have tried, but am unable to pinpoint an exact cause.

Installation/Hardware: Synology Docker:

  • Docker Tag 2022.01.1
  • Pi-hole v5.10
  • FTL v5.15
  • Web Interface v5.12

Client: Iphone 13 Pro / 15.5

Wireshark / monitoring setup: I have a unifi 8-port POE switch connecting my wireless AP. I have a USB ethernet adapter connected to a second port on the same switch and set to mirroring mode for the port the AP is connected to. This USB adapter is connected to a pc with wireshark and has all TCPIP disabled on the adapter, with only NPCAP enabled on it, so that its only function is to mirror packets to/from the AP into wireshark.

Note: I started down this path because of the discussion in this thread on limiting IP address tracking. I note that in that thread, there remains no specific root cause known. However, while comparing wireshark captures between 8.8.8.8 queries from the phone and pihole replies, I found the differences noted above. I am not intending to claim this topic is a root cause or even directly linked to the attached thread... but merely sharing how I came upon the differences.

For the screen-shot shown below, limit IP address tracking is set to off... however, I have not found that setting makes a difference for the behavior claimed in this topic. The only thing that changes the behavior is whether I use the pihole as a dns server or not.

Actual Behaviour:

The Pi-Hole web interface confirms that for type65 / https queries that contain a CNAME entry, the upstream service does return the proper entry (queries that do not find a cname entry will show 'NODATA' in the response column).

I believe based on what the pi-hole UI is showing that it receives a CNAME record in response to the forwarded query.

image
image1465×110 17.3 KB

However, the response actually returned to the client is not including the CNAME record, nor is including a SOA record either (which should always be present in the response for this query).

(Note the time-stamp in the images to correlate the two queries between wireshark and the website.)

image
image3187×1352 186 KB

EDIT: After a suggestion from yubiuser, I have done some more testing with captures and only the google upstream DNS. The additional image I had previously pasted here, does appear to be specific to the behavior differences between opendns and google.

I am removing the image that was previously here, because the specific concern I still have is the scenario above where the cname was returned by the upstream service, but then removed in the pi-hole reply to the client.

Thank you.

I did spend about an hour searching github issues, this site, and the internet as a whole for a similarly reported issue to this one... or at least if someone had linked this behavior to the apple IP tracking thread linked above, but I did not find any other posts / issues / or links, so created a new topic.

This is my first topic here. Thank you for any help.

J.P.

Debug Token:

https://tricorder.pi-hole.net/wrfW4xPN/

2

My guess would be that the difference is caused by the upstream DNS resolver. You configured Pi-hole with a lot of different upstream servers

    PIHOLE_DNS_1=8.8.8.8
    PIHOLE_DNS_2=8.8.4.4
    PIHOLE_DNS_3=208.67.222.222
    PIHOLE_DNS_4=208.67.220.220
    PIHOLE_DNS_5=4.2.2.1
    PIHOLE_DNS_6=4.2.2.2
    PIHOLE_DNS_7=1.1.1.1
    PIHOLE_DNS_8=1.0.0.1

Looking at your Query Log screenshot you can see that OpenDNS returned the CNAME. As you made all your test by comparing to 8.8.8.8 I would suggest you use only this one as Pi-hole's upstream and see if you get the same response as querying 8.8.8.8 directly. Afterwards, change to OpenDNS only and see if the behavior changes.

4

P.S. Pi-hole has a internal package dump option. This might come handy in your analysis.
https://docs.pi-hole.net/ftldns/package_dump/

1 Like
5

Thank you for your reply.

I agree multiple upstream servers may have somewhat different behaviors. Maybe that explains the larger list of replies shown in my last image.

Yes, as you mention, the pi-hole UI image does show a CNAME returned in that specific example.

However, I need to point out that for the same compared query response (the wireshark image shows the exact time-stamp), I believe that pi-hole is stripping the returned CNAME from the reply to the client even though the upstream server included it.

Yes, I did go on and make further comparisons in another image, I understand your reply in terms of the broader comparison.

However my specific concern / report is that Pihole seems to be stripping the CNAME from the reply back to the client even in the cases where the upstream server includes it.

6

Thanks for your suggestion.

After some testing and isolation of upstream services, I do see that the second observation I had made regarding SOA inclusions in type 65 replies does appear specific to the google upstream service.

I edited my original post, removing that image, since its not specifically related to the problem I was reporting, only a guess on my part.

7

I tried your example with different resolver (shown here only Pi-hole with unbound and 8.8.8.8) and they all returned only a CNAME with out an A-Record.

dig -t TYPE65 www.bing.com @10.0.1.5

; <<>> DiG 9.19.1-1+ubuntu18.04.1+isc+1-Ubuntu <<>> -t TYPE65 www.bing.com @10.0.1.5
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25664
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;www.bing.com.			IN	HTTPS

;; ANSWER SECTION:
www.bing.com.		3448	IN	CNAME	a-0001.a-afdentry.net.trafficmanager.net.
a-0001.a-afdentry.net.trafficmanager.net. 50 IN	CNAME www-bing-com.dual-a-0001.a-msedge.net.
www-bing-com.dual-a-0001.a-msedge.net. 50 IN CNAME dual-a-0001.a-msedge.net.

;; AUTHORITY SECTION:
a-msedge.net.		89	IN	SOA	ns1.a-msedge.net. msnhst.microsoft.com. 2016092901 1800 900 2419200 240

;; Query time: 20 msec
;; SERVER: 10.0.1.5#53(10.0.1.5) (UDP)
;; WHEN: Sun Jun 12 21:32:12 CEST 2022
;; MSG SIZE  rcvd: 214


dig -t TYPE65 www.bing.com @8.8.8.8

; <<>> DiG 9.19.1-1+ubuntu18.04.1+isc+1-Ubuntu <<>> -t TYPE65 www.bing.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33321
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.bing.com.			IN	HTTPS

;; ANSWER SECTION:
www.bing.com.		3482	IN	CNAME	a-0001.a-afdentry.net.trafficmanager.net.
a-0001.a-afdentry.net.trafficmanager.net. 37 IN	CNAME www-bing-com.dual-a-0001.a-msedge.net.
www-bing-com.dual-a-0001.a-msedge.net. 49 IN CNAME dual-a-0001.a-msedge.net.

;; AUTHORITY SECTION:
a-msedge.net.		231	IN	SOA	ns1.a-msedge.net. msnhst.microsoft.com. 2016092901 1800 900 2419200 240

;; Query time: 16 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Sun Jun 12 21:37:36 CEST 2022
;; MSG SIZE  rcvd: 214
8

Yes. A CNAME record (when it exists) is the proper answer to a type 65 query from what I understand.

I believe it’s akin to SRV records, but slightly different functionality.

Are you finding that pi-hole is returning that CNAME record back to the client? That is what I was trying to report.

If I point my client directly at an upstream resolver, then the client is getting the CNAME records returned in these type 65 queries.

I’m not expert enough in this newish protocol to know whether recursion is desired or not for these types. However, as your output above shows (and my tests concur), recursion isn’t expected. I believe the client merely wants to see the CNAME in the response.

9

Yes. My first example shows one query from a client. Pi-hole is at 10.0.1.5 and correctly returning the CNAME.

If you suspect Pi-hole

I would suggest a package capture directly from Pi-hole as shown above. You could directly compare the returning DNS package from upstream and the one Pi-hole returns to the client.

10

Ah, Ok. Thank you for investigating. I will work on that.

I may need to find a way to create a second instance, since our current installation handles thousands of queries per minute, so I can't quite enable packet captures easily without capturing a large number of unrelated queries.

11

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