How to fix a "THROWAWAY" response

Unbound
1

Hi,

I have been trying to get a web site to work correctly with V1.18.0. I have
not reverted yet to a previous version of unbound but I have been trying to
access a part of this web site I have not tried before.

What I have found is that if Unbound has

do-ip6: yes

then the site does not work. If I set

do-ip6: no

Then it appears to work OK.

This maybe the first of many discovery steps. My system is able to do both
IPV6 and IPV4 so I don't think that setting:

do-nat64: no

to yes will make and difference and I am not 100% certain regarding nat64
anyway. This is all a bit trial and error on my part as I am certainly not a
DNS expert. I do not want to post publicly any of the verbose: 4 log file as
it is a banking web site.

Any suggestions would be welcome.

Thanks

When I start the access to the web site there are two records returning the
IPV4 (A) address and then we get multiple tries for the same name looking
for an IPV6 (AAAA or HTTPS) and it all ends up with SERVFAIL so I don't
thing the IPV4 address is ever returned hence the web site does not work.
Just my 2ps worth.

What I see is unbound trying all the upstream servers:

;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
<dns name>. IN AAAA

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 41
03/09/2023 15:48:06 C:\Program Files\Unbound\unbound.exe[5672:0] debug:
iter_handle processing q with state QUERY RESPONSE STATE
03/09/2023 15:48:06 C:\Program Files\Unbound\unbound.exe[5672:0] info: query
response was THROWAWAY

Or:

;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
<dns name>. IN HTTPS

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 41

03/09/2023 15:48:06 C:\Program Files\Unbound\unbound.exe[5672:0] debug:
iter_handle processing q with state QUERY RESPONSE STATE
03/09/2023 15:48:06 C:\Program Files\Unbound\unbound.exe[5672:0] info: query
response was THROWAWAY

2

Hi,

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

So until I can get some pointers as to what is happening I will stay with
V1.17.1

RayG

3

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

4

Wait. Why should this last one be needed? I know it it false for my
own domain aceecat.org, yet browsing www.aceecat.org (which *only*
has an AAAA record) works fine, as long as there is an IPv6 pipe
from the client of course.

5

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?

Wait. Why should this last one be needed? I know it it false for my
own domain aceecat.org, yet browsing www.aceecat.org (which *only*
has an AAAA record) works fine, as long as there is an IPv6 pipe
from the client of course.

I don't know for certain, but absent prior knowledge gathered by
unbound wrt. IPv6 reachability of name servers, resolving a
domain where the name servers have published AAAA records but
where unbound's IPv6 connectivity is present but hampered or
broken might cause resolution of the target domain to take longer
than the client is willing to wait.

Since the exact failure mode has only been vaguely described I
thought it pertinent to also mention this as a potential source
of issues.

Regards,

- Håvard

6

Hi,

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.

7

Hi,

OK it is all resolved.

I think a recent update to the browser must have made some changes. So back
on 1.18.0 and there are no issues at the moment.

Thanks

RayG