On 2026-04-22 15:44:05 (+0800), Washington Odhiambo wrote:
> On Wed, Apr 22, 2026 at 10:17 AM Philip Paeps <
phi...@freebsd.org>
> wrote:
>> On 2026-04-22 14:45:25 (+0800), Washington Odhiambo wrote:
>>> On Wed, Apr 22, 2026 at 8:58 AM Philip Paeps <
phi...@freebsd.org>
>>> wrote:
>>>> I just noticed this message from a couple of weeks ago. The
>>>> problem
>>>> might have been transient but ...
>>>>
>>>> On 2026-04-04 19:50:48 (+0800), Washington Odhiambo wrote:
>>>>> What's going on here?
>>>>
>>>> It looks like you're getting timeouts because you're talking to a
>>>>
pkg.FreeBSD.org mirror very far from where you are.
>>>>
>>>>> pkg: Failed to fetch
>>>>>
https://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.conf: Timeout
>>>>> was reached
>>>>>
>>>>> [...]
>>>>
>>>> It's very odd to see you being sent all the way to New Jersey. Our
>>>> GeoDNS should be sending you to Fastly infrastructure in Cape Town
>>>> or
>>>> our mirror in Johannesburg. Both are still a long way away but
>>>> 70ms
>>>> is a lot better than 250ms!
>>>>
>>>> Could you tell me your source IP address please? I can optimise
>>>> the
>>>> routing.
>>>
>>> [...]
> root@gw:/home/wash # nslookup
>>
pkg.freebsd.org
> Server: 127.0.0.1
> Address: 127.0.0.1#53
>
> Non-authoritative answer:
>
pkg.freebsd.org canonical name =
pkgmir.geo.freebsd.org.
> Name:
pkgmir.geo.freebsd.org
> Address: 96.47.72.71
> Name:
pkgmir.geo.freebsd.org
> Address: 2610:1c1:1:606c::50:1
>>
> root@gw:/home/wash # lsof -i -P -n | grep :53
> unbound 46811 unbound 3u IPv4 0xfffff800063af540 0 UDP
> 127.0.0.1:53->*:*
> unbound 46811 unbound 4u IPv4 0xfffff80006dff540 0 TCP
> 127.0.0.1:53->*:* (LISTEN)
> root@gw:/home/wash # cat /var/unbound/forward.conf
> forward-zone:
> name: .
> forward-tls-upstream: yes
> forward-first: no
> forward-addr: 1.0.0.1@53 #cloudflare
>
This is your problem. Cloudflare does not send the EDNS Client Subnet
(ECS) to our authoritative servers so we have no way of determining
where your query comes from. In the absence of a geographic origin, we
point you at our site of last resort: New Jersey.
One option is to configure a stub-zone for
geo.FreeBSD.org, e.g.:
stub-zone:
name:
geo.FreeBSD.org
stub-host:
gns1.FreeBSD.org
stub-host:
gns2.FreeBSD.org
stub-first: yes
The "stub-first: yes" will ensure you can still resolve
geo.FreeBSD.org
if we ever decide to rename our servers something else and save you some
debugging. (Note that we don't plan to rename these servers but, if
ever the operational need arises, we might.)
Note that this will send us queries without TLS (we don't do
DNS-over-TLS) but your ISP already sees your traffic to FreeBSD.org -
sending us a couple of DNS queries won't give them much more
information.
You could also work around this with another forward-zone block for
geo.FreeBSD.org that points to a DNS server that sends us client
information, e.g.:
forward-zone:
name: .
forward-tls-upstream: yes
forward-first: yes
forward-addr: 9.9.9.11@53 #quad9 with ECS
The "forward-first: yes" will make Unbound fall back to regular
resolving from the root, which is a good idea for robustness. If you
feel strongly about TLS, you might want to turn this off. In that case,
it'll break if you can't reach 9.9.9.11.
Before you embark on this adventure though, please do a quick test with
e.g. nameserver 9.9.9.11 (or your ISP's DNS servers) in /etc/resolv.conf
(i.e. bypass your local-unbound for testing). If that also sends you to
New Jersey, I might be talking out of my hat and we can try something
else. :) (I don't think I'm talking out of my hat though.)
> PS: I am using Jamii Telecommunications in Nairobi.
I checked all of the prefixes being announced by JTL/AS36866 and they're
all being sent to Fastly (probably Cape Town) with a fallback to Europe
(Sweden).
Isn't DNS fun?! ;)
Philip