-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Labels
0. Needs triagePending check for reproducibility or if it fits our roadmapPending check for reproducibility or if it fits our roadmap29-feedbackbug
Description
⚠️ This issue respects the following points: ⚠️
- This is a bug, not a question or a configuration/webserver/proxy issue.
- This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
- Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- I agree to follow Nextcloud's Code of Conduct.
Bug description
I am looking at this code:
server/lib/private/Http/Client/DnsPinMiddleware.php
Lines 61 to 89 in 4281ce6
| $dnsTypes = \defined('AF_INET6') || @inet_pton('::1') | |
| ? [DNS_A, DNS_AAAA, DNS_CNAME] | |
| : [DNS_A, DNS_CNAME]; | |
| foreach ($dnsTypes as $dnsType) { | |
| if ($this->negativeDnsCache->isNegativeCached($target, $dnsType)) { | |
| continue; | |
| } | |
| $dnsResponses = $this->dnsGetRecord($target, $dnsType); | |
| $canHaveCnameRecord = true; | |
| if ($dnsResponses !== false && count($dnsResponses) > 0) { | |
| foreach ($dnsResponses as $dnsResponse) { | |
| if (isset($dnsResponse['ip'])) { | |
| $targetIps[] = $dnsResponse['ip']; | |
| $canHaveCnameRecord = false; | |
| } elseif (isset($dnsResponse['ipv6'])) { | |
| $targetIps[] = $dnsResponse['ipv6']; | |
| $canHaveCnameRecord = false; | |
| } elseif (isset($dnsResponse['target']) && $canHaveCnameRecord) { | |
| $targetIps = array_merge($targetIps, $this->dnsResolve($dnsResponse['target'], $recursionCount)); | |
| $canHaveCnameRecord = true; | |
| } | |
| } | |
| } elseif ($dnsNegativeTtl !== null) { | |
| $this->negativeDnsCache->setNegativeCacheForDnsType($target, $dnsType, $dnsNegativeTtl); | |
| } | |
| } | |
| return $targetIps; |
Important
I am by no means a PHP expert, please tell me if I am mistaken.
To me, the way the code is constructed would indicate that CNAME is always queried, even when A succeeded. This aligns with what I am observing in my DNS server logs:
[INFO] 10.10.0.38:42508 - 60413 "CNAME IN updates.nextcloud.com. udp 50 false 1200" NOERROR qr,rd,ra 116 0.039573751s
[INFO] 10.10.0.38:46316 - 26341 "CNAME IN updates.nextcloud.com.cloud.svc.cluster. udp 68 false 1200" NXDOMAIN qr,aa,rd,ra 132 0.000151319s
[INFO] 10.10.0.38:42074 - 34897 "CNAME IN updates.nextcloud.com.cluster. udp 58 false 1200" NXDOMAIN qr,aa,rd,ra 122 0.000110026s
[INFO] 10.10.0.38:54477 - 22629 "CNAME IN apps.nextcloud.com.cloud.svc.cluster. udp 65 false 1200" NXDOMAIN qr,aa,rd,ra 129 0.000151308s
[INFO] 10.10.0.38:49188 - 36978 "CNAME IN www.nextcloud.com.cloud.svc.cluster. udp 64 false 1200" NXDOMAIN qr,aa,rd,ra 128 0.000266391s
[INFO] 10.10.0.38:48706 - 44842 "CNAME IN www.nextcloud.com.cluster. udp 54 false 1200" NXDOMAIN qr,aa,rd,ra 118 0.000134442s
[INFO] 10.10.0.38:40937 - 47170 "CNAME IN nextcloud.com. udp 42 false 1200" NOERROR qr,rd,ra 108 0.040937649s
[INFO] 10.10.0.38:57557 - 28949 "CNAME IN nextcloud.com.svc.cluster. udp 54 false 1200" NXDOMAIN qr,aa,rd,ra 118 0.000163416sWouldn't it make more sense to skip CNAME when canHaveCnameRecord is false, and we should set canHaveCnameRecord outside the loop?
Steps to reproduce
- Run NC
- Look at DNS server logs
Expected behavior
When canHaveCnameRecord is false, we should not query for CNAME.
Nextcloud Server version
29
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.3
Web server
Apache (supported)
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
I will deliver upon request; I do not think the config is important for this issue.List of activated Apps
I will deliver upon request; I do not think the config is important for this issue.Nextcloud Signing status
I will deliver upon request; I do not think the config is important for this issue.Nextcloud Logs
I will deliver upon request; I do not think the config is important for this issue.Additional info
This is not a showstopper in any way; I just think the behavior is neither expected nor desirable.
Metadata
Metadata
Assignees
Labels
0. Needs triagePending check for reproducibility or if it fits our roadmapPending check for reproducibility or if it fits our roadmap29-feedbackbug