The #NTP Pool project has published details about a #GeoDNS server that was tampered with by a volunteer host who still had access to the system. #DNS weights were manipulated to steer more #IPv6 traffic toward servers under that person’s control, and source IP data from DNS queries was collected.
https://community.ntppool.org/t/dns-configuration-tampering-on-one-of-our-geodns-servers/4300

Analyzing FreeBSD’s Package Mirror GeoDNS

https://antranigv.am/posts/2025/06/analyzing-freebsds-package-mirror-geodns/

One of the things that makes FreeBSD an amazing operating system is its package manager, pkg(8). Many people will keep arguing with me saying that apt or pacman is better, but pkg has some of the best features out there. Don’t even get me started on number of packages. A friend was telling me “but how can I use FreeBSD when you have 1/3rd number of packages that Debian has?”. Again, this is a lie. While Debian has 80K packages, each software is divided into -doc and -dev, while on FreeBSD a simple pkg install will install everything that a package needs.

But let’s not talk about how awesome FreeBSD’s pkg is, let’s talk about it’s issues.

Couple of years ago, I noticed that downloading from FreeBSD package mirror was veeeeeery slow. Turns out that based on GeoDNS Armenia was connecting to the South African package mirror pkg0.jinx.FreeBSD.org by default.

Lucky for me, there was a package to help you figure out which one is fastest for you, named fastest_pkg. I ran it and I learned that the Frankfurt package mirror was the fastest for me.

Initially, I changed the config in FreeBSD.conf as recommended by fastest_pkg, but I’m not a single server guy, I have dozens of hosts with hundreds of jails.

Solution? I asked the Cluster Admins to set Armenia’s GeoDNS to pkg0.fra.FreeBSD.org.

But servers come and go, and the Frankfurt server got decommissioned a while back. Luckily the project now has a server in… Sweden!

But my download speed is slow. Somehow Armenia defaulted back to South Africa.

Is this an issue for me, or is this an issue for everybody?

(Sidenote: turns out fastest_pkg has been broken for a while, ever since pkg moved to a new package format, so we also made a patch and submitted a PR)

During today’s FreeBSD “Ask the experts: AMA” we used RIPE Atlas to measure the speeds from all around the world, to all package mirror hosts.

All of the measurements can be found here.

So, here’s the goal

  • Measure from around the world to all of the package mirror hosts (done).
  • Measure from around the world to pkg.FreeBSD.org to get the default GeoDNS host for each area/country/network (in progress, recurring every 6 hours for the next 6 days)
  • Find mis-configurations between “fastest” and “default” (TODO).

While the big measurements is still running I tried to use my eyes to see if there’s anything GREEN (aka fast connection) in direct package mirror host measurements whilst being YELLOW/RED (aka bad connection) when connecting to pkg.FreeBSD.org.

Unsurprisingly, we found one! It was in Mombasa, Kenya.

Here’s what it looks like while connecting directly:

{ "fw": 5080, "mver": "2.6.2", "lts": 25, "dst_name": "pkg0.jinx.freebsd.org", "ttr": 10639.830509, "af": 4, "dst_addr": "196.10.53.168", "src_addr": "160.119.216.205", "proto": "ICMP", "ttl": 59, "size": 1000, "result": [ { "rtt": 47.434297 }, { "rtt": 47.39957 }, { "rtt": 47.412379 }, { "rtt": 47.369089 }, { "rtt": 47.851894 } ], "dup": 0, "rcvd": 5, "sent": 5, "min": 47.369089, "max": 47.851894, "avg": 47.493445799999996, "msm_id": 110487154, "prb_id": 22215, "timestamp": 1750269643, "msm_name": "Ping", "from": "160.119.216.205", "type": "ping", "group_id": 110487154, "step": null, "stored_timestamp": 1750269644}

And here it is via GeoDNS’s defaults:

{ "fw": 5080, "mver": "2.6.2", "lts": 10, "dst_name": "pkg.freebsd.org", "ttr": 10465.87807, "af": 4, "dst_addr": "173.228.147.98", "src_addr": "160.119.216.205", "proto": "ICMP", "ttl": 52, "size": 1000, "result": [ { "rtt": 240.19025 }, { "rtt": 244.967071 }, { "rtt": 236.466414 }, { "rtt": 238.189775 }, { "rtt": 233.570938 } ], "dup": 0, "rcvd": 5, "sent": 5, "min": 233.570938, "max": 244.967071, "avg": 238.6768896, "msm_id": 110489920, "prb_id": 22215, "timestamp": 1750270943, "msm_name": "Ping", "from": "160.119.216.205", "type": "ping", "group_id": 110489920, "step": null, "stored_timestamp": 1750270944}

Clearly, it’s set to pkg0.chi.freebsd.org (173.228.147.98) by default. That’s Chicago. That’s halfway around the world. It took it 238ms on average. While it took the same probe 47ms on average when connecting to pkg0.jinx.freebsd.org directly.

Clearly, I’m not the only one.

Hopefully after collecting data for 6 days, we can start analyzing and improving the GeoDNS setup that we have.

A good suggestion from crest was to have a pkg plugin that does the work of fastest_pkg on the fly. We’ll try that one day.

If anyone is interested in helping me out, feel free to contact me over email, IRC or Discord.

That’s all folks…

#DNS #FreeBSD #GeoDNS #pkg #RIPE #RIPEAtlas

Analyzing FreeBSD’s Package Mirror GeoDNS | Antranig Vartanian

Как сделать и настроить свой CDN

CDN (сеть доставки контента) представляет собой группу серверов, размещаемых в разных географических регионах с целью обеспечить быструю загрузку контента для пользователей из этих регионов. Чаще всего сети доставки контента используются для ускорения загрузки статических файлов: картинок, видео, скриптов, zip-архивов. Каждый из CDN серверов просто хранит одни и те же файлы, а пользователь получает их с ближайшего сервера. Хранение контента у большинства сетей доставки контента организовано так: CDN сервер, получив в первый раз от пользователя запрос на отдачу файла, загружает его с оригинального сервера к себе, кэширует и тут же отдает пользователю. Для всех последующих запросов файл уже выдается из кэша. Некоторые сервисы позволяют настраивать длительность хранения кэшируемых данных, а также их предварительную загрузку (прекэш). Иногда может понадобиться настроить собственную сеть доставки контента. Давайте рассмотрим, для чего это нужно и как это сделать. Это наша будущая CDN из 5 серверов, которая будет раздавать контент на весь мир

https://habr.com/ru/articles/810241/

#cdn #cdnсервис #geodns #nginx

Как сделать и настроить свой CDN

CDN (сеть доставки контента) представляет собой группу серверов, размещаемых в разных географических регионах с целью обеспечить быструю загрузку контента для пользователей из этих регионов. Чаще...

Хабр

问题解决,Arch 的 GeoDNS 服务商似乎不支持 ECS(使用 dig +subnet= 测试),导致实际上是按照 Google DNS 的 出口节点分配 CDN。
@felixonmars 关于 Arch CDN 的 GeoDNS 配置你有头猪吗?

#DNS #ECS #GeoDNS

Up and Down Like a Tart's Knickers

I'm sure we both know why this is happening, and no I'm not ok thanks.

https://blog.sus.fr/~/Tech/Up%20and%20Down%20Like%20a%20Tart's%20Knickers/

Up and Down Like a Tart's Knickers

I'm sure we both know why this is happening, and no I'm not ok thanks.

We host our own authoritative DNS servers rather than using a managed service. When you connect to https://grapheneos.org/, your DNS resolver service obtains an IP from our own DNS servers. We route traffic to the closest server via GeoDNS and have automatic failover on downtime.

#grapheneos #privacy #security #dns #nameserver #anycast #geodns #failover #powerdns #ovh #buyvm

GrapheneOS: the private and secure mobile OS

GrapheneOS is a security and privacy focused mobile OS with Android app compatibility.

GrapheneOS

I am considering running a small #CDN (5/6 pops) and the cost estimate is wild.

Anycast on ipv6 is essentially free (Hetzner gives away /64 for free with servers), ipv4 is a no go considering the price of a /24 block.

#GeoDNS providers vary greatly in pricing and reviews, so far I haven’t found the sweet spot of cost / trust.

If anyone got recommendations please send them my way. #dns

We've made significant improvements to our HTTPS-based network time update system for our next OS release.

https://github.com/GrapheneOS/platform_frameworks_base/commit/b0407ee4a553784a8b6af6e191f886eb021289ce

Should provide most users with around 3 to 15ms precision instead of more than 1000ms mainly from moving away from standard TLS/HTTPS timestamps.

#grapheneos #privacy #security #https #ntp #nts #geodns #time

improve HTTPS-based network time implementation · GrapheneOS/platform_frameworks_base@b0407ee

* use X-Time header for millisecond precision timestamp * establish HTTPS connection with another request in advance and then reuse it to improve accuracy * set clock offset field used by tests *...

GitHub

@ralf Yeah, if I have some #free resources lying around, I would definitely do #anycast as well!

I don't particularly like the inaccuracies of #GeoDNS and would avoid it if at all possible.

I guess it all comes down to cost vs desired outcomes 😀