Unbound suddenly not resolving www.startpage.com

Help Community Help
1

I assume this is unbound...
This just happened a few hours ago. It has been working perfectly up until now, nothing has been changed and suddenly www.startpage.com was unreachable.

dig @127.0.0.1 www.startpage.com

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @127.0.0.1 www.startpage.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55802
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.startpage.com.             IN      A

;; ANSWER SECTION:
www.startpage.com.      856     IN      CNAME   startpage.com.
startpage.com.          1773    IN      A       67.63.58.135

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Dec 07 01:33:27 CET 2024
;; MSG SIZE  rcvd: 89

And using Domain to IP Lookup - Find IP Address of the Domain/Website/Server it tells me it should be:

A
Type
Domain Name
TTL
Address
A www.startpage.com 3600
67.63.61.135 Check IP Blacklist

Owner: Surfboard Holding BV [United States of America] WHOIS AS200184

67.63.58.135 vs 67.63.61.135

$ ping -c 3 67.63.58.135

PING 67.63.58.135 (67.63.58.135) 56(84) bytes of data.

--- 67.63.58.135 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2044ms


$ ping -c 3 67.63.61.135
PING 67.63.61.135 (67.63.61.135) 56(84) bytes of data.
64 bytes from 67.63.61.135: icmp_seq=1 ttl=46 time=161 ms
64 bytes from 67.63.61.135: icmp_seq=2 ttl=46 time=160 ms
64 bytes from 67.63.61.135: icmp_seq=3 ttl=46 time=160 ms

--- 67.63.61.135 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 160.238/160.424/160.698/0.197 ms

$ traceroute www.startpage.com

traceroute to www.startpage.com (67.63.58.135), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.99.1)  1.091 ms  1.016 ms  5.694 ms
 2  * * *
 3  83.255.251.110 (83.255.251.110)  6.697 ms  6.762 ms  6.817 ms
 4  vag-bbr-1-be100.net.comhem.se (213.200.167.42)  13.900 ms vag-bbr-2-be100.net.comhem.se (213.200.167.40)  18.621 ms  18.769 ms
 5  ch-kt-cagg-1-be23.net.comhem.se (213.200.163.72)  14.472 ms ch-vrr-cagg-1-be24.net.comhem.se (213.200.163.2)  10.632 ms  10.788 ms
 6  bck3-core-1.bundle-ether8.tele2.net (91.129.12.110)  18.625 ms bck3-core-1.bundle-ether9.tele2.net (91.129.12.76)  6.969 ms  6.994 ms
 7  brn-core-1.bundle-ether2.tele2.net (91.129.12.45)  14.980 ms  14.451 ms lim-core-2.bundle-ether1.tele2.net (91.129.12.19)  10.806 ms
 8  lm1-peer-2.ae1-unit0.tele2.net (91.129.14.124)  10.855 ms lm1-peer-2.ae2-unit0.tele2.net (91.129.14.126)  11.134 ms  14.033 ms
 9  * * *
10  be3090.rcr21.cph01.atlas.cogentco.com (154.54.74.45)  12.214 ms  15.574 ms  15.549 ms
11  be2504.ccr42.ham01.atlas.cogentco.com (154.54.61.229)  13.362 ms  13.285 ms  17.031 ms
12  be5748.ccr41.fra05.atlas.cogentco.com (130.117.48.129)  25.280 ms be5749.ccr41.fra05.atlas.cogentco.com (130.117.48.157)  25.424 ms be5748.ccr41.fra05.atlas.cogentco.com (130.117.48.129)  25.202 ms
13  be3763.agr31.fra05.atlas.cogentco.com (154.54.76.210)  25.289 ms  28.995 ms  25.272 ms
14  francetelecom.fra03.atlas.cogentco.com (130.117.14.226)  25.234 ms  21.492 ms  25.459 ms
15  * * *
16  * * *
17  * * *
18  Be3.bbna03.ah2.routit.net (37.0.80.112)  26.200 ms  26.582 ms be4.iar03.asd2.routit.net (37.0.80.114)  29.517 ms
19  be1.bbna02.kpn-asd2.routit.net (37.0.80.36)  26.276 ms be2.bbna02.dc2.routit.net (84.246.25.30)  33.340 ms  33.647 ms
20  be42.core4-a.tc2.routit.net (84.246.25.58)  26.461 ms  30.188 ms  30.687 ms
21  Te1-2.las02.tc2.routit.net (37.0.80.193)  30.389 ms  34.224 ms  34.609 ms
22  rt151bb44-46-110.routit.net (46.44.151.110)  31.238 ms  35.201 ms  31.449 ms
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

I am using cloudflare with tls (ipv4 only)
Added content in /etc/unbound/unbound.conf.d/pi-hole.conf:

   # TLS settings
#    tls-upstream: yes
    tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"

forward-zone:
    name: "."
    # Cloudflare
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    # forward-addr: 2606:4700:4700::1111@853
    # forward-addr: 2606:4700:4700::1001@853
    forward-ssl-upstream: yes
Entire file 
$ cat /etc/unbound/unbound.conf.d/pi-hole.conf

server:
    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    #root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

   # TLS settings
#    tls-upstream: yes
    tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"

forward-zone:
    name: "."
    # Cloudflare
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    # forward-addr: 2606:4700:4700::1111@853
    # forward-addr: 2606:4700:4700::1001@853
    forward-ssl-upstream: yes

If I add for example the "default" cloudflair dns:s in the pihole dns settings on top of my custom 127.0.0.1#5335 it still does not work.
BUT if I add 1.1.1.1 to my network interface (on my computer, not the pihole) I can reach www.startpage.com.

There might be other pages not working that I have not found, but all other web traffic seems to work just fine, it is only startpage that returns a timeout.

Any tips out there for a noob like me?

2

The fact the you got a response back from unbound says its working. This would likely be something with a server at startpage. I have to problem pinging that particular IP ( 67.63.58.135 ) at the moment. If you do a whois 67.63.58.135 |grep -A2 -i inetnum you can see IP ranges for Startpage in the EU.

If it does persist you could try and flush the dns cache in pihole and see if you get a different server.

3

Thank you for responding.

Oh!
So the return of that whois is the entire ip range that can be used?

whois 67.63.58.135 | grep -A2 -i inetnum
inetnum:        67.63.56.0 - 67.63.63.255
netname:        STARTPAGE
country:        EU

I guess I'll just use ddg and wait until tomorrow.
I did a quick search but could not find how to flush the cache in pihole, only the logs and network table...
Or do you mean the cache on the device pihole is running on, or unbound cache?
I'm a little out of depth here...

4

This should get you what you need to do that.

1 Like
5

LMAO, ddg does does not work as good as startpage would, I'm sorry about that.
Thank you for spoon feeding me the link! :heart:

But running

pihole restartdns

will flush the cache and allow a newly-blacklisted (or whitelisted) domain to be answered correctly (see below).

I have rebooted the device so it should be the same right?
I'll just wait until tomorrow, restart the dns if still not working and come back with a report, it might be something on the startpage server side as you mentioned.

Thank you!

6

Unbound suddenly not resolving www.startpage.com

Your output shows that unbound correctly resolved the domain. That's all unbound can do.

If a client cannot subsequently connect after resolving the domain name, that would point to a client problem.

1 Like
7

starpage randomly started working again without the need to do anything.

Marking a solution.

8

In this case the IP that Unbound answered with was 67.63.58.135 and Bedna was unable to ping that IP while being able to ping the IP that Cloudflare provided. Would that not point to a server issue?

1 Like
9

That was exactly my point, and why I included that ping.

Not sure how it can be a client error when the ip address unbound delivered was unreachable, even after restarting the entire device running pihole and unbound.

But I also do not want to start drama and "it fixed itself" so...
Edit
But now it stopped working again and I don't feel like asking again after being told "I am the problem" from a moderator... Only startpage.com, all else works.
End edit

Thank you for the help @CallMeCurious even though the problem is back today.

Edit
In case someone else finds this thread.
It shows a timeout error specifically now, not necessarily "unreachable".

The connection has timed out

An error occurred during a connection to www.startpage.com.

The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer’s network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.

And not:

Hmm. We’re having trouble finding that site.

We can’t connect to the server at asdadasdfsdfsdfsdfsfdsd.com.

If you entered the right address, you can:

Try again later
Check your network connection
Check that Firefox has permission to access the web (you might be connected but behind a firewall)
10

pings are not guaranteed, if the server is blocking ICMP packets then pings will fail. A better approach to debugging connectivity issues is to tracert|traceroute to the target and see if there is any activity outside of the LAN segment. Or mtr is a good tool for that as well.

11

That usually indicates that the client has been able to send an initial request to the server but there is no traffic from the server.

The other error "can't connect" means that no TCP session could be initiated. That's more difficult to debug because there are a number of things that can go wrong and cause this response.

12

In the original post buddy.

If you actually want to help me out I would appreciate it. Let me know what exact commands you want me to run, because I can't have it like this.
Startpage works for an hour or so, then stops, then starts working again and I have no idea where to even begin to look for problems.

Maybe it IS their servers, I don't know. But the fact that it comes and goes, and that it is ONLY startpage is very strange to me.

On top of it being strange that unbound uses 1.1.1.1, and if I set my desktop interface to connect to that instead of my local unbound for dns, startpage works.

Edit
I saw some stack overflow thread mentioning increasing edns-packet-max=1232 to something higher, like 4096, but I have read on other places that there is a reason for the size being 1232 so...
Suggestions welcome...

13

I'm not your buddy. Giving me attitude isn't your best move here.

14

I don't see any post that would say so.
Could you point me to it?

What you've shared so far demonstrates that DNS has succeeded, but subsequent connects to the target IP do fail. That would indicate a networking issue rather than a DNS or Pi-hole one, so tinkering with DNS configuration options like edns-packet-max won't help here (and it also means your topic title is misleading, as you've demonstrated unbound to be operational).

Also, I can ping either IP you've shared just fine, but I notice that even your successful pings are quite slow at ~160ms vs. my ~30ms.

How are you connected to the Internet?
Are you perhaps using a VPN service?

16

No vpn, only unbound tls with the configs I shared in the original post.
Pihole is NOT dhcp if that matters in this situation.

Probably because you did it at a time when it was working.
There is another user earlier in the thread confirming not either being able to ping the ip at the time of trying.

So the question for me is, why does unbound not update the way 1.1.1.1 does?
Again, when it does not work, I can correctly connect to the 1.1.1.1 cloudflair DNS directly in my network interface on my desktop (rather than using 192.168.bla bla where my pihole/unbound is) and it immediately starts working.
That to me, unless I completely misunderstand how networking works, indicates that there is no problem with 1.1.1.1 or my network.

There is no network slowdown, other webpages responds just as they normally do, no long delays or anything.
This is ONLY startpage.com

Edit
Now the site is completely unreachable but when I started typing this message, it was working.

Hmm. We’re having trouble finding that site.

We can’t connect to the server at www.startpage.com.

If you entered the right address, you can:

Try again later
Check your network connection
Check that Firefox has permission to access the web (you might be connected but behind a firewall)

An my internet clearly works, because I am posting this.. xD

17

I actually missed this post before posting the last one.

Wtf is wrong with you?!?
Srsly? I clarified that what was suggested was ALL in the original post, and this is your reaction?
I feel very unwelcome in the community I have donated to over the years.

Maybe above?
I honestly lost all interest in this forum.

18

You may note that I was not responding to you in my ping vs trace response.

Donations are always appreciated but they are not a license to treat Pi-hole team members with disrespect. Moderators included. No moderator told you that you were the problem, that chip you planted firmly on your own shoulder.

Your tone is very demanding in this post and in your questioning of what domains we use for Discourse.

I think you may need to move on from this forum.

20

At the time you did post that accusation against a moderator, the only moderator post in this topic was by jfb, and jfb did just state that DNS is working, which could hint at client-specific issues, so I don't know where you got that idea that you are the problem.

It seems unfair to me that you are turning your own words against us, and I can't help noting a tendency of yours to read comments negatively, even if they are not directed at you.

Your title makes it clear that you suspect DNS to fail, and you seem to be reluctant to accept that DNS is not the issue, despite your original post already demonstrating successful DNS resolution.

It would not be unexpected that DNS replies may differ over time or by requestor, and there are several reasons for this.

It is common that DNS may hold several IPs for the same domain, and authoritative DNS servers may shuffle them in their answers to distribute load, or to pick only the one they'd deem topologically closest to the requestor.

Also, as a recursive resolver, unbound would be talking to authoritative DNS servers, whereas a public DNS server may serve answers from its cache.

And DNS records may be updated by authoritative DNS server's maintainers at times, in which case public DNS servers may lag behind authoritative ones for as long as the previous record's TTL.

But even as returned A records can differ, DNS has successfully completed.

If your machine cannot connect to an IP in time or not at all because the servers are under heavy load or down, then that's not a DNS issue.

Primarily, it indicates that there is no issue with DNS in general, be it Pi-hole, unbound or public resolvers.
Your issue is connectivity to startpage.com servers.

As noted before, contrary to your title, you've demonstrated that unbound has no trouble resolving www.startpage.com at all.

If other users can confirm startpage connectivity issues, you should probably seek information and advice on startpage outages.

After all, this is the Pi-hole forum.
We can help you analyse and fix DNS issues, and probably tune your home network a bit, but a public IP being unresponsive or inaccessible is simply beyond us.

21

Hey Buddy!

I've noticed the same problem with www.startpage.com since about the 5th of Dec maybe? Tools like "isitdownorjustme.net" showed it as up, but certainly not accessible from Sweden.

  • Tried some public DNS servers in Sweden with IPv4, all resolved it to 67.63.58.135, and there's nothing at that address.
  • Just like you I tried some other public DNS, like Cloudflare and Cisco and got the response 37.0.81.241, where Startpage works like a charm.

I don't know what has happened (anybody's guess), and to me it's currently not worth spending more time on it to find out. For the time being I'll just use the working website. If I get around to it maybe an email to support@startpage.com in case they are unaware of it (doubt it though).

If anyone's toes got bruised by my blunt post, sorry, I'm just a lowly techie who haven't learned manors :slight_smile:

1 Like
22

Bedna

Have a look at this link for how I got round not being able to access www.gov.uk.