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. # # MyForwardZones @ 2021-07-04 16:07:46 # forward-zone: # MyForwardZones.conf name: "." forward-first: no forward-addr: 1.1.1.1 forward-addr: 1.0.0.1 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 correctly. So what has changed in V1.18.0 that causes this to happen? RayG -----Original Message----- From: Havard Eidnes <h...@uninett.no> Sent: Wednesday, September 6, 2023 8:42 PM To: rgs...@btinternet.com Cc: unbound-users@lists.nlnetlabs.nl 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