** Description changed:

  [Impact]
  
  The current unbound version 1.13.1 in Ubuntu 22.04 has a hardcoded limit
  of 8 CNAME chain redirections (set by MAX_RESTART_COUNT), causing DNS
  resolution failures for legitimate domains that use longer CNAME chains.
  This particularly affects Microsoft services like entra.microsoft.com
  and portal.azure.com which uses more than 8 CNAME redirections.
  
  Users experience DNS resolution failures (SERVFAIL responses) when
  accessing these domains, making them inaccessible through unbound. While
  long CNAME chains are generally discouraged, major service providers
  like Microsoft still use them legitimately.
  
  The fix increases the hardcoded limit from 8 to 11, which upstream
  unbound implemented in version 1.13.2. This resolves the immediate issue
  affecting legitimate domains while doing minimal changes to the
  codebase.
  
  [Test Plan]
  
  To verify that the changes fixed the reported issue, unbound's DNS
  resolution should be tested against several domains with long CNAME
  chains, verifying that they resolve succesfully with the final IP
  address returned. Additionally, debug logs should also be checked to
  ensure that there are no error messages related to exceeding the restart
  limits.
  
  To verify that no regressions occur, the following should be tested:
-  - Standard DNS queries to ensure basic functionality remains intact
-  - Test domains with shorter CNAME chains to verify normal operation
-  - Verify that performance hasn't degraded significantly for typical queries.
+  - Standard DNS queries to ensure basic functionality remains intact
+  - Test domains with shorter CNAME chains to verify normal operation
+  - Verify that performance hasn't degraded significantly for typical queries.
  
  [Where problems could occur]
  
  Allowing unbound to follow longer CNAME chains requires additional DNS
  queries, potentially increasing resource usage and resolution time.
  However, the incraase from 8 to 11 is minimal and is unlikely to cause
  noticiable performance impact on modern systems.
  
  [Other Info]
  
  There are two upstream solutions available to solve this problem:
-  - Version 1.13.2 increased the hardcoded limit to 11
-  - Version 1.17.1 made the limit configurable via the max-restart-count 
parameter
+  - Version 1.13.2 increased the hardcoded limit to 11
+  - Version 1.17.1 made the limit configurable via the max-restart-count 
parameter
  
  To reduce the risk of this SRU, we decided to backport the 1.13.2 fix,
  which ensures minimal changes are made without introducing new
  configuration complexity, while fixing the immediate issue.
  
  -----
  
  [Original Description]
  
  $ lsb_release -rd
  Description:  Ubuntu 22.04.4 LTS
  Release:      22.04
  
  $ apt-cache policy unbound
  unbound:
    Installed: 1.13.1-1ubuntu5.11
    Candidate: 1.13.1-1ubuntu5.11
    Version table:
   *** 1.13.1-1ubuntu5.11 500
-         500 https://apt.teslamotors.com/mirror/security.ubuntu.com/ubuntu 
jammy-security/universe amd64 Packages
-         500 https://apt.teslamotors.com/mirror/archive.ubuntu.com/ubuntu 
jammy-updates/universe amd64 Packages
-         100 /var/lib/dpkg/status
-      1.13.1-1ubuntu5 500
-         500 https://apt.teslamotors.com/mirror/archive.ubuntu.com/ubuntu 
jammy/universe amd64 Packages
  
- Expectation: Unbound max_restart_count hardcoded default limit set to 11
- so long cname chaining records will resolve as expected.
+ 
+ Expectation: Unbound max_restart_count hardcoded default limit set to 11 so 
long cname chaining records will resolve as expected.
  
  What happened: Unbound 1.13.1 provides SERVFAIL for records that have more 
than 8 CNAME chains.
  Details:
  
  Unbound 1.13.1 has hardcoded limit of number of CNAME chains it will follow 
for a given query. This is set to 8.
  
https://github.com/NLnetLabs/unbound/blob/6cd77933a3f113ea2bef7e4943f6dda6a26a39cb/iterator/iterator.h#L64
  
  While long cname chaining is bad practise there are providers like Microsoft 
that does provide dns responses with long cname chains unfortunately.
  example:
  
  entra.microsoft.com. 3066 IN CNAME portal.azure.com.
  portal.azure.com. 3042 IN CNAME portal.azure.com.trafficmanager.net.
  portal.azure.com.trafficmanager.net. 24 IN CNAME azureportal.z01.azurefd.net.
  azureportal.z01.azurefd.net. 8 IN CNAME azurefd-p-prod.trafficmanager.net.
  azurefd-p-prod.trafficmanager.net. 8 IN CNAME 
shed.s-part-0049.p-0010.p-msedge.net.
  shed.s-part-0049.p-0010.p-msedge.net. 9 IN CNAME 
azurefd-p-fb-prod.trafficmanager.net.
  azurefd-p-fb-prod.trafficmanager.net. 8 IN CNAME 
shed.s-part-0049.p-0010.p-dc-msedge.net.
  shed.s-part-0049.p-0010.p-dc-msedge.net. 8 IN CNAME 
global-entry-fb-afdthirdparty-unicast.trafficmanager.net.
  global-entry-fb-afdthirdparty-unicast.trafficmanager.net. 14 IN CNAME 
lon21r9c.msedge.net.
  lon21r9c.msedge.net. 3554 IN A 40.90.65.189
  
  unbound 1.13.1 does not resolve this and in the debug logs you will see
  something like:
  
  error: SERVFAIL <entra.microsoft.com. A IN>: request has exceeded the
  maximum number restarts (eg. indirections) stop at stor9a.msedge.net.
  
  In version 1.13.2 unbound increased this hardcode limit to 11.
  
https://github.com/NLnetLabs/unbound/commit/8878680898b23671d31857930891f65affe639c8#diff-c0ce1df6dfe0d23ee8da2faf5ce0bbdd97264fb46eb356be176fe3f2b16fabd7R64
  
  In version 1.17.1 unbound allowed this to be a configurable parameter.
  
https://github.com/NLnetLabs/unbound/commit/df411b3f2833ecf668fb750623c9fccebc58c827
  
  Please check if its possible to backport either the fix in 1.13.2 or
  1.17.1 unbound to ubuntu 22.04 unbound 1.13.1 ?  ( I think bringing the
  fix from 1.13.2 maybe easier )

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2122609

Title:
  Hardcoded MAX_RESTART_COUNT in unbound 1.13.1 blocks dns resolution of
  long cname chains

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/2122609/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to