Bug 216260
| Summary: | dns/djbdns: loop detection false positives. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | tjd-freebsd | ||||
| Component: | Individual Port(s) | Assignee: | David Thiel <lx> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | bdrewery, w.schwarzenfeld | ||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(lx) |
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Maintainer feedback? A commit references this bug: Author: lx Date: Tue Jan 16 19:54:19 UTC 2018 New revision: 459204 URL: https://svnweb.freebsd.org/changeset/ports/459204 Log: Bump loop detection limit to 500 PR: 216260 Submitted by: tjd-freebsd@phlegethon.org Changes: head/dns/djbdns/Makefile head/dns/djbdns/files/patch-query.c Committed, while I despair at living in a world where 100 DNS queries isn't enough to resolve a name. (In reply to David Thiel from comment #3) > Committed, while I despair at living in a world where 100 DNS queries isn't > enough to resolve a name. 500 seems a bit absurd though... I mean, 100 seems absurd to me, but I guess I'm old. You're welcome to twiddle it to something else if you think need be. |
Created attachment 179072 [details] Patch to bump loop detection limit from 100 to 500. djbdns will give up resolving a name after 100 queries, to avoid following CNAME loops forever. But 'modern' CDNs use complex layers of DNS redirection that can hit this limit when resolving a valid query from a cold cache. I found that resolving the Let's Encrypt OCSP responder (ocsp.int-x3.letsencrypt.org.) through dnscache would fail and time out. The attached patch bumps the limit from 100 to 500, and makes that particular name resolve again on my system (10.3-RELEASE-p11 amd64, djbdns-ipv6-1.05.b23_21,1 with IP6 config enabled). I searched a bit and it looks like this is a known issue, WONTFIX'd upstream.