panic: runtime error: index out of range [0] with length 0 about unbound HOT 12 CLOSED

Can the fix be applied in this repo since the upstream fix has stalled before being merged? It has been over a year, so I assume it won't be.

from unbound.

Per stack trace, unbound is trying to write an invalid response without the question in it.
Looks like an unbound problem.

from unbound.

#25 Seems related

from unbound.

#25 Seems related

It's the same mode of failure. unbound.Unbound.Resolve() is returning a result with an AnswerPacket that does not contain a Question section.

Probably best to figure out why that happens in the first place in github.com/miekg/unbound, but a hacky-fix here would be to add the section if it's missing. E.g. something along the lines of ...

if len(res.AnswerPacket.Question) == 0 {
   res.AnswerPacket.Question = r.Question
}

Although it would be a safer hack to SERVFAIL when len(res.AnswerPacket.Question) == 0. It's likely that in these cases that it's not just the Question that is missing (e.g. default msg struct), and the response is not valid even with the question hacked back in. e.g. lines 121-123:

if err != nil || len(res.AnswerPacket.Question) == 0 { 
 	return dns.RcodeServerFailure, err 
 } 

from unbound.

Will you make a PR? I'm not good with golang.

from unbound.

do you have a test case? I think I can paper over it in miekg/unbound, but not sure if that is the best approach

from unbound.

I think I can paper over it in miekg/unbound, but not sure if that is the best approach

A papered over solution probably better to live here in the plugin - e.g. to return SERVFAIL if the AnswerPacket is missing a Question.

from unbound.

proper fix upstream with miekg/unbound#18. Thanks miekg!

from unbound.

I think my issue might be related to this one since I'm getting same error message "[ERROR] Recovered from panic in server: "dns://:53" runtime error: index out of range [0] with length 0" with unbound plugin when I try to resolve IBM Cloud Kafka broker instance - broker-5-48d5s71514qnmqz3.kafka.svc11.us-south.eventstreams.cloud.ibm.com. Seems like it might be related to trying to resolve long sub-domains, but again not sure.

When I was testing this 9/10 times it throws error message above and only once time it resolves and returns CNAME.

from unbound.

I echo the need for miekg/unbound#18 to be patched in this repo since upstream has stalled on merging in the fix. For others that are looking for a quick not ideal workaround you can manually patch the three line change with the following:

Grab the patch from the PR:

curl -sL -o pr18.patch https://patch-diff.githubusercontent.com/raw/miekg/unbound/pull/18.patch

If you are using a container to build a custom CoreDNS binary with this plugin you can apply it with the following:

RUN go mod download
COPY plugin.cfg $GOPATH/src/github.com/coredns/coredns
RUN make gen
COPY pr18.patch /root/go/pkg/mod/github.com/miekg/unbound\@v0.0.0-20210309082708-dbeefb4cdb29
WORKDIR /root/go/pkg/mod/github.com/miekg/unbound\@v0.0.0-20210309082708-dbeefb4cdb29
RUN patch -p1 < pr18.patch
WORKDIR $GOPATH/src/github.com/coredns/coredns

I have tested this with the latest CoreDNS 1.11.3 pre-release and it works as expected:

$ podman exec coredns drill A 2.0.0.127.zen.spamhaus.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 51610
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; 2.0.0.127.zen.spamhaus.org.	IN	A

;; ANSWER SECTION:
2.0.0.127.zen.spamhaus.org.	60	IN	A	127.0.0.4
2.0.0.127.zen.spamhaus.org.	60	IN	A	127.0.0.2
2.0.0.127.zen.spamhaus.org.	60	IN	A	127.0.0.10

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 392 msec
;; SERVER: 127.0.0.1
;; WHEN: Mon Jun 10 18:09:10 2024
;; MSG SIZE  rcvd: 170

from unbound.

I clicked a button

from unbound.

@miekg you are the best! Thanks dude!

from unbound.