Re: Updating Ports on 15.0-RELEASE-p5

On 2026-04-22 15:44:05 (+0800), Washington Odhiambo wrote:
> On Wed, Apr 22, 2026 at 10:17 AM Philip Paeps <philip@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 <philip@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.
>>>
>>> [...]
>>>  4  * * 41.215.131.9 (41.215.131.9)  3.135 ms
>>
>> This hop is in Nairobi and our GeoDNS would send you to somewhere
>> nearby.  Are you perhaps using a DNS server far away, or one that 
>> strips
>> ECS information?  E.g. 9.9.9.9 will do this - 9.9.9.11 will work much
>> better.
>>
>> See https://quad9.net/service/service-addresses-and-features/#ecssec
>>
>> Or is your origin network (masked by the NAT hops) in another 
>> netblock
>> that isn't geolocated to Kenya?
>>
>> What does this tell you?
>>
>> % curl http://ip.wtf
>>
>>> 18  pkg0.nyi.freebsd.org (96.47.72.71)  251.058 ms  251.621 ms
>>> 246.661 ms
>>> root@gw:/home/wash #
>>> root@gw:/home/wash # pkg update
>>> Updating FreeBSD-ports repository catalogue...
>>> pkg: Failed to fetch
>>> https://pkg.FreeBSD.org/FreeBSD:15:amd64/latest/meta.conf: Timeout 
>>> was
>>> reached
>>> pkg: Failed to fetch
>>
>> pkg should be robust with high latency but there are a lot of hops on
>> the path.  And who knows what those first couple of hops are doing. 
>> :)
>>
>> For what it's worth, from WaveX in Nairobi I get sent to Fastly in 
>> Cape
>> Town.
>
> 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