Panic when CNAME points to external domains

[Renerick]

When CNAME record in the custom zone file points to external domains, blocky panics and returns no respone

Custom DNS config (it is provisioned by a script, so formatting is not "human")

customDNS:
  customTTL: 30m
  rewrite:
    [REDACTED]: internal
  zone: '$ORIGIN internal.

    a 3600 A 1.1.1.1

    c 3600 CNAME example.com.


    '

Testing

$ dig a.internal @10.10.10.10

; <<>> DiG 9.18.39 <<>> a.internal @10.10.10.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7011
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;a.internal.                    IN      A

;; ANSWER SECTION:
a.internal.             3600    IN      A       1.1.1.1

;; Query time: 1 msec
;; SERVER: 10.10.10.10#53(10.10.10.10) (UDP)
;; WHEN: Tue Sep 16 01:55:54 +04 2025
;; MSG SIZE  rcvd: 44

$ dig c.internal @10.10.10.10

; <<>> DiG 9.18.39 <<>> c.internal @10.10.10.10
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 573
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;c.internal.                    IN      A

;; Query time: 1 msec
;; SERVER: 10.10.10.10#53(10.10.10.10) (UDP)
;; WHEN: Tue Sep 16 01:55:57 +04 2025
;; MSG SIZE  rcvd: 28

Logs:

Sep 15 21:55:54 dns-1 blocky[3760]: [2025-09-15 21:55:54] TRACE new incoming request client_id= client_ip=10.10.0.1 client_request_id=7011 protocol=UDP question=A (a.internal.) req_id=09894299-7520-4f9c-9fd2-f01c87012c99
Sep 15 21:55:54 dns-1 blocky[3760]: [2025-09-15 21:55:54] TRACE query_logging.rewrite: go to inner resolver client_ip=10.10.0.1 client_names=10.10.0.1 question=A (a.internal.) req_id=09894299-7520-4f9c-9fd2-f01c87012c99 resolver=custom_dns
Sep 15 21:55:54 dns-1 blocky[3760]: [2025-09-15 21:55:54] DEBUG query_logging.rewrite.custom_dns: returning custom dns entry answer=A (1.1.1.1) client_ip=10.10.0.1 client_names=10.10.0.1 domain=a.internal question=A (a.internal.) req_id=09894299-7520-4f9c-9fd2-f01c87012c99
Sep 15 21:55:54 dns-1 blocky[3760]: [2025-09-15 21:55:54]  INFO queryLog: query resolved answer=A (1.1.1.1) client_ip=10.10.0.1 client_names=10.10.0.1 instance=dns-1 question_name=a.internal. question_type=A response_code=NOERROR response_reason=CUSTOM DNS response_type=CUSTOMDNS
Sep 15 21:55:57 dns-1 blocky[3760]: [2025-09-15 21:55:57] TRACE new incoming request client_id= client_ip=10.10.0.1 client_request_id=573 protocol=UDP question=A (c.internal.) req_id=c49e209b-626a-4c70-ba22-53fb93ac2979
Sep 15 21:55:57 dns-1 blocky[3760]: [2025-09-15 21:55:57] TRACE query_logging.rewrite: go to inner resolver client_ip=10.10.0.1 client_names=10.10.0.1 question=A (c.internal.) req_id=c49e209b-626a-4c70-ba22-53fb93ac2979 resolver=custom_dns
Sep 15 21:55:57 dns-1 blocky[3760]: [2025-09-15 21:55:57] TRACE query_logging.rewrite.custom_dns: go to next resolver client_ip=10.10.0.1 client_names=10.10.0.1 next_resolver=noop question=A (c.internal.) req_id=c49e209b-626a-4c70-ba22-53fb93ac2979
Sep 15 21:55:57 dns-1 blocky[3760]: [2025-09-15 21:55:57] ERROR error on processing request:panic occurred: runtime error: invalid memory address or nil pointer dereference client_ip=10.10.0.1 question=A (c.internal.) req_id=c49e209b-626a-4c70-ba22-53fb93ac2979

I have looked through the code, it seems the culprit is

blocky/resolver/custom_dns_resolver.go

Lines 278 to 284 in a2cfb0b

	// resolve the target recursively
	targetResp, err := r.processRequest(ctx, logger, targetRequest, cnames)
	if err != nil {
	return nil, err
	}
	result = append(result, targetResp.Res.Answer...)

which calls to this (because external domain is not specified in the zone file)

blocky/resolver/custom_dns_resolver.go

Line 162 in a2cfb0b

logger.WithField("next_resolver", Name(r.next)).Trace("go to next resolver")

but next is noop, as initialized in here

blocky/server/server.go

Line 325 in a2cfb0b

resolver.NewRewriterResolver(cfg.CustomDNS.RewriterConfig, resolver.NewCustomDNSResolver(cfg.CustomDNS)),

blocky/resolver/rewriter_resolver.go

Lines 28 to 46 in a2cfb0b

	func NewRewriterResolver(cfg config.RewriterConfig, inner ChainedResolver) ChainedResolver {
	if len(cfg.Rewrite) == 0 {
	return inner
	}
	// ensures that the rewrites map contains all rewrites in lower case
	for k, v := range cfg.Rewrite {
	cfg.Rewrite[strings.ToLower(k)] = strings.ToLower(v)
	}
	inner.Next(NewNoOpResolver())
	return &RewriterResolver{
	configurable: withConfig(&cfg),
	typed: withType("rewrite"),
	inner: inner,
	}
	}

which returns nil in the response somewhere I think, so when CNAME handler tries to access it and append it to result slice, it panics.

I'm not sure what behavior was intended here, so I'm couldn't make a PR to fix it myself. I stumbled upon this bug when trying to implement CNAMES to my router DNS, populated from DHCP. I was hoping the CNAME resolution would go through my conditional config, which points unqualified DNS requests to the router and so I would have DHCP+DNS service discovery, which would allow me to setup something like

conditional:
  mapping:
    .: 10.0.0.1 # router with DNS enabled

application 3600 CNAME reverse-proxy. ;; this is the hostname of the proxy VM, registered by DHCP and resolvable by router's DNS

I'm more than willing to take upon fixing this, but I would like to hear maintainer's opinion on this case

Thank you for blocky btw, aside from this edge case it has been rock solid local DNS solution

[Renerick]

Interestingly enough, when I'm trying to write a test case for it, it runs just fine. Either main has this problem fixed, or there's something magical going on with the test setup

[Renerick]

I see, the problem is that this bug manifests itself when custom DNS resolver has rewrites configured. When there are no rewrites, the inner instance of custom DNS resolver is returned as is, so it's chained in the server properly

blocky/resolver/rewriter_resolver.go

Lines 28 to 31 in a2cfb0b

	func NewRewriterResolver(cfg config.RewriterConfig, inner ChainedResolver) ChainedResolver {
	if len(cfg.Rewrite) == 0 {
	return inner
	}

And when the rewrite is configured, it is then chained to Noop, and with that I was able to write a test case reproducing this panic

diff --git a/server/server_test.go b/server/server_test.go
--- a/server/server_test.go	(revision 55f3610eadaa52e0d3d5cacd8d3ddda5ea0c868f)
+++ b/server/server_test.go	(date 1758015196051)
@@ -105,10 +105,13 @@
 
 	cfg := &config.Config{
 		CustomDNS: config.CustomDNS{
-			CustomTTL: config.Duration(3600 * time.Second),
+			RewriterConfig: config.RewriterConfig{Rewrite: map[string]string{"foo": "bar"}},
+			CustomTTL:      config.Duration(3600 * time.Second),
 			Mapping: config.CustomDNSMapping{
-				"custom.lan": {&dns.A{A: net.ParseIP("192.168.178.55")}},
-				"lan.home":   {&dns.A{A: net.ParseIP("192.168.178.56")}},
+				"custom.lan":       {&dns.A{A: net.ParseIP("192.168.178.55")}},
+				"lan.home":         {&dns.A{A: net.ParseIP("192.168.178.56")}},
+				"custom.cname.lan": {&dns.CNAME{Target: "custom.lan."}},
+				"google.de.lan":    {&dns.CNAME{Target: "google.de."}},
 			},
 		},
 		Conditional: config.ConditionalUpstream{
@@ -222,6 +225,30 @@
 						SatisfyAll(
 							BeDNSRecord("host.lan.home.", A, "192.168.178.56"),
 							HaveTTL(BeNumerically("==", 3600)),
+						))
+			})
+		})
+		Context("Custom DNS CNAME entry to another entry", func() {
+			It("should return valid answer", func() {
+				Expect(
+					requestServer(util.NewMsgWithQuestion("custom.cname.lan", A))).
+					Should(
+						SatisfyAll(
+							BeDNSRecord("custom.cname.lan.", CNAME, "custom.lan."),
+							BeDNSRecord("custom.lan.", A, "192.168.178.55"),
+							HaveTTL(BeNumerically("==", 3600)),
+						))
+			})
+		})
+		Context("Custom DNS CNAME entry to external entry", func() {
+			It("should return valid answer", func() {
+				Expect(
+					requestServer(util.NewMsgWithQuestion("google.de.lan", A))).
+					Should(
+						SatisfyAll(
+							BeDNSRecord("google.de.lan.", CNAME, "google.de."),
+							BeDNSRecord("google.de.", A, "123.124.122.123"),
+							HaveTTL(BeNumerically("==", 3600)),
 						))
 			})
 		})

So it seems like rewriter resolver breaks the chain when rewrites are defined. One hand, it seems like the desired behavior, so that custom DNS rewrites don't propagate down the chain. On the other hand, it leads to the issue with CNAMES. Again, not sure what's the intended behavior was and what would be the approach for the fix

[Renerick]

Ok, I get it now. The issue is that "entrypoint" of custom DNS resolver and CNAME processing go through the same code path, which involves going through the chain. When rewrite is involved, it makes sense to short-circuit custom DNS resolver, so that the following chain elements are not affected by the rewrites, and rewriter resolver will handle passing unmodified query further instead of custom DNS. But CNAME requires essentially new DNS query which should be processed as such.

I suppose, custom DNS resolver could introduce CnameResolver field for such cases and have a separate codepath for cname processing entirely, but it would be redundant if there are no defined rewrites. But maybe it's still fine, since we get more control over how CNAME is resolved regardless of rewrites being defined or not

Alternatively, the logic of the rewriter resolver could be moved into custom dns resolver, so it will handle both rewrites and passing the correct domain to the chain

[Renerick]

I took the liberty to submit a draft PR with a possible fix. It's not the cleanest code in the world, but it does the right thing IMO - separate chains for CNAME resolution and continuation (even though technically it's the same chain)

I have deployed the fix onto my server - seems to work perfectly fine

[0xERR0R]

Thank you for your investigation! I could reproduce this bug with this config:

ports:
  dns: 55555
upstreams:
  groups:
    default:
      - 1.1.1.1
customDNS:
  customTTL: 30m
  rewrite:
    local: internal
  zone: |
    $ORIGIN internal.
    a 3600 A 1.1.1.1
    c 3600 CNAME example.com.

[0xERR0R]

I used different approach to solve it. I was not happy with branching resolver (rewriteResolver) and wanted to refactor it. With this bug, it was a good reason to do it. This creates a linear resolver chain where CNAME targets can be properly resolved through the entire chain

[Renerick]

Thank you for prompt fix!