How to fix a "THROWAWAY" response

RayG rgsub1 at
Fri Sep 8 14:51:42 UTC 2023


The recursive unbound service is running on my PC and is providing lookup
services to access resources on the internet for my home network.

There is no relationship between the PC and the target web site.

The site in question doers not look to have any IPV6 presence i.e. when dig
is used to lookup the DNS name there is one CNAME and one A record returned

My PC has IPV6 capability and the resolvers also have the same capability.

# MyForwardZones @ 2021-07-04 16:07:46
forward-zone: # MyForwardZones.conf
     name: "."
     forward-first: no
     forward-addr: 2606:4700:4700::1111
     forward-addr: 2606:4700:4700::1001

To take things further, the web site works as expected, but it provides a
CHAT service which is the one thing that does not work when IPV6 is enabled
in unbound v1.18.0

The CHAT service DOES work as expected with unbound v1.17.1 with both IPV4 &
6 enabled.

My conclusion is the unbound v1.18.0 is doing something very different which
is breaking this particular site. I have not (so far) found another with the
issue, but then until I returned to v1.18.0 that is unlikely as 1.17.1 works

So what has changed in V1.18.0 that causes this to happen?


-----Original Message-----
From: Havard Eidnes <he at> 
Sent: Wednesday, September 6, 2023 8:42 PM
To: rgsub1 at
Cc: unbound-users at
Subject: Re: How to fix a "THROWAWAY" response

> To answer my own question,
> I went back to unbound V1.17.1 and I do not have the problem I 
> described below.
> So I am at a loss to say why this is happening.
> The only difference to make the web site work with V1.18.0 is to turn 
> off ipv6

In my opinion you didn't adequatly describe the relationship between your
unbound resolver and the (unnamed) web site.  Is unbound performing resolver
duties for the host running the web site?  Or are they really unrelated?  Is
unbound only serving the web client host(s)?  Also, you were also very
unspecific about what with the web site is not working.  The devil is often
lurking in the details.  Is unbound unable to look up the address info for
the web site?  Or are your clients unable to connect to the web site in
question using IPv6?

You say that turning off "do-ipv6" works around the issue.  Does the web
site in question serve contents over IPv6?  Does it have an AAAA record in
the DNS (if "yes" to the former question it should be a "yes" to the
latter)?  Does the name servers for the zone where the web site address is
registered have AAAA records registered?  Does your unbound host have IPv6
reachability issues related to those name servers?

Of course, if you have broken or severely hampered IPv6 connectivity, trying
to use IPv6 for either name resolution or for actual content transfer is
going to cause problems.  For content transfer it's of course your web
client's IPv6 connectivity which matters, and not (primarily) your unbound
name server.

It would probably bring you closer to figuring out what the actual
underlying problem is (or was) if you figured out the answers to a few of
the above questions.

Best regards,

- Håvard

More information about the Unbound-users mailing list