- DynIP, homelab, edge router ve altyapı ekipleri için bir dinamik DNS hizmetidir; 60 saniyelik güncellemeler ve ücretsiz katman sunar
- RFC 2136 TSIG, REST API ve UDP/53 güncellemelerini destekler; FortiGate, OPNsense, OpenWRT ve MikroTik ile entegre olur
- IPv6 desteğini IPv4 ile birlikte sunarak A ve AAAA kayıtlarını yan yana günceller; hem dual-stack hem de yalnızca IPv6 olan zone'ları kapsar
- DNSSEC, imzalama anahtarı oluşturmayı, üst zone'a yayımlamayı ve kayıt imzalamayı otomatikleştirir; Let’s Encrypt sertifikası vermek için gereklidir
- BYOD ile sahip olduğunuz alan adını bağlayıp dinamik alt alan adları oluşturabilirsiniz; ancak
ns1.dynip.dev ve ns2.dynip.dev için delegation gerekir
DynIP genel bakış
- DynIP, homelab, edge router ve altyapı ekipleri için bir dinamik DNS hizmetidir; 60 saniyelik güncellemeler, ücretsiz katman, RFC 2136 TSIG, özel alan adı kullanımı ve DNSSEC özelliklerini öne çıkarır
- Router güncelleme gönderdiğinde, ana makine adının dünya genelinde yaklaşık 60 saniye içinde doğru şekilde çözümlenmesi için tasarlanmıştır
- 60 saniye TTL, NOTIFY tabanlı yayılım ve çok bölgeli nameserver sunar
- Ücretsiz kayıt ve dokümantasyon sağlar
DNS standartları ve router entegrasyonu
- RFC 2136 TSIG desteği sayesinde FortiGate, OPNsense, OpenWRT ve DNS UPDATE destekleyen router'larda kullanılabilir
- MikroTik kullanıcıları yerel HTTP API entegrasyonunu kullanabilir
- Desteklenen yöntemler arasında RFC 2136 TSIG, REST API ve UDP/53 yerel güncellemeleri bulunur
- Ayar snippet ekranında cihaz türü, hedef IP adresi, alan adı ve TSIG anahtarına göre bir yapılandırma bloğu üretilip kopyalanabilir
- Yeni bir zone nameserver'lara yayılırken FortiGate'in RFC 2136/TSIG güncellemeleri beklemede kalmalıdır
- cURL, PowerShell, Python ve MikroTik gibi HTTP API güncellemeleri ise anında çalışır
IPv6 ve DNSSEC
- IPv6, IPv4 ile birlikte desteklenir; böylece A ve AAAA kayıtları yan yana güncellenebilir
- Hem dual-stack yapılandırmalar hem de yalnızca IPv6 olan zone'lar desteklenir
- Let’s Encrypt sertifikası verebilmek için ilgili zone'da DNSSEC etkin olmalıdır
- DNSSEC açıldığında imzalama anahtarı oluşturma, üst zone'a yayımlama ve tüm DNS kayıtlarının imzalanması otomatik olarak yapılır
- DNSSEC kurulumu tek seferlik bir işlemdir; sonrasında ilgili zone imzalı olarak kalır
- Tahmini süre 30 saniye olarak gösterilir
Hızlı başlangıç ve zone yönetimi
- Hızlı başlangıç akışı; cihaz adı girme, varsayılan alan adını seçme ve Create Zone düğmesine tıklayarak zone oluşturma adımlarından oluşur
- Yeni alan adının yanındaki Snippets düğmesinden yapılandırmayı alıp cihaz türünü seçtikten sonra oluşturulan yapılandırma bloğunu router CLI'ına kopyalayabilirsiniz
- IPv4 ve IPv6, gelen bağlantılara göre otomatik olarak algılanır ve güncellenir
- Zone listesi; alan adı ve araçları, mevcut IP, TSIG Secret, DNSSEC ve SSL sertifikası durumunu gösterir
- Her zone için kilit durumu, snippet'ler, silme, bildirimler, senkronizasyon zamanı, DNSSEC açma-kapama ve SSL sertifikası indirme-yenileme-verme işlemleri yönetilebilir
Kendi alan adınızı kullanma
- Custom Namespaces (BYOD) özelliğiyle sahip olduğunuz alan adını DynIP'ye bağlayıp bu namespace altında dinamik alt alan adları oluşturabilirsiniz
- Namespace'i etkinleştirmek için alan adı kayıt şirketinizde iki NS kaydının da oluşturulması gerekir
- Tek bir NS delegation kabul edilmez
- Gerekli NS kayıtları
ns1.dynip.dev ve ns2.dynip.dev'dir
- Kurulum doğrulaması, delegation'ın etkin olduğunu ya da kayıt şirketinde gerekli işlemin yapılması gerektiğini kontrol eden bir akış sunar
Hızlı senkronizasyon ve otomasyon
- Quick Sync, seçilen zone'u mevcut cihazın harici IP adresiyle anında eşitleyen bir özelliktir
- Algılanan ağ IP'sini gösterir ve kullanıcının seçtiği zone'ları tek seferde güncelleyebilir
- Oturum token'ı ile
/register endpoint'ine POST isteği göndererek yeni bir zone programatik olarak kaydedilebilir
curl -X POST "{{ backendUrl }}/register?subdomain=my-new-router&base_domain={{ baseDomains[0] }}" \
-H "Authorization: Bearer {{ token }}"
- Oturum token'ı çıkış yapıldığında sona erer; bu yüzden uzun süreli otomasyon için API token'ı kullanılmalıdır
- API tokens, Pro ve üzeri bir özelliktir; izleme script'leri, CI pipeline'ları ve MSP entegrasyonları gibi otomasyonlarda kullanılabilir
- API token'ları çıkış yapsanız da sona ermez; salt okunur veya tam erişim kapsamıyla sınırlandırılabilir ve istenildiğinde iptal edilebilir
- Yeni API token'ı yalnızca oluşturulurken bir kez gösterilir; bu nedenle bir parola yöneticisinde veya secret store'da saklanmalıdır
Fiyatlandırma ve hesap güvenliği
- Fiyatlandırma ekranı; abonelik katmanını, durumu, yenileme tarihini veya erişimin biteceği tarihi, ödeme döngüsünü ve kullanılan zone sayısıyla azami alan adı sayısını gösterir
- Plan düşürüldüğünde yalnızca izin verilen en eski sayıdaki zone etkin kalır; geri kalan zone'lar kilitlenir ve IP güncellemesi alamaz
- Ödeme başarısız olduğunda erişimin sürmesi için ödeme yönteminin güncellenmesi gerekir
- Hesap güvenliği e-posta ile 2FA ve TOTP desteği sunar; TOTP etkinleştirildiğinde e-posta 2FA'nın yerini alır
- TOTP kurulumu, Google Authenticator, Authy veya tercih edilen 2FA uygulamasında QR kodunu tarama ve kodu doğrulama adımlarından oluşur
İlgili bağlantılar
1 yorum
Hacker News görüşleri
İsveçli bir ağ mühendisi olan Daniel, mevcut DDNS hizmetlerinin 2010’lar tarzı ağlarda takılı kaldığını düşündüğü için DynIP’yi geliştirmiş
Tescilli, yalnızca HTTP kullanan güncelleme protokolleri, zayıf IPv6 desteği, DNSSEC eksikliği ve modern ekipman desteğinin yetersizliği sürekli tekrarlandığı için DynIP, RFC 2136 / TSIG güncellemelerini birinci sınıf yol olarak ele alıyor
FortiGate generic DDNS ve MikroTik
/tool dns-update, ayrı bir istemci olmadan çalışıyor; diğer kullanım senaryoları için de bir HTTP API sunuluyorYetkili DNS sunucularına IPv6 üzerinden erişilebiliyor, üst
.devzonunda AAAA glue yayımlanmış durumda ve müşteri zonları A/AAAA yayımlarken yalnızca IPv6 kullanan istemciler de destekleniyorSeçili zonlarda DNSSEC tek bir anahtarla açılabiliyor ve alt alan adı yetkilendirmesiyle kendi alan adınızı getirebiliyorsunuz
Mimari, herkese açık trafik almayan gizli bir primary ile, İsveç ve İsviçre’de coğrafi olarak dağıtılmış iki secondary’nin TSIG’i yerelde doğrulayıp ardından primary’ye iletmesi şeklinde kurulmuş
RFC 1918 ve CGNAT adreslerine de kayıtlarda izin veriliyor; böylece private APN kullanan hücresel filo sistemleri, dahili IP’leri işaret eden kararlı herkese açık DNS ana makine adları kullanabiliyor
ghcr.io/33k-org/dynip-updateradında küçük bir Docker konteyneri de var; yığın PowerDNS 4.8 authoritative, FastAPI, Postgres, Postfix, Cloudflare ve Paddle’dan oluşuyor, hizmetdynip.devüzerinde çalışıyor ve ücretsiz bir katman da mevcutIPv6, DNSSEC ve kendi alan adını kullanma gibi özellikler sunuyor; ayrıca açık kaynak bir proje ve kararlı bir ücretsiz hosting hizmeti de işletiyor
Belgelerde gözden kaçırmış olabilirim ama burada IPv6 prefix delegation desteği de var; yani ISP’nin yönlendiriciye atadığı IPv6 prefix değiştiğinde, herhangi bir alan adının yalnızca ağ prefix’ini güncelleyebiliyorsunuz
Avrupa’da bu prefix genelde sabit değil ve ISP yeniden bağlandığında değişiyor; bu yüzden host kısmını koruyup yalnızca ağ kısmını otomatik güncelleyen özellik kullanışlı oluyor
Örnek:
/update?myipv6:nas.home.mydomain.tld=2003:e6:bee:affe::/56E-posta doğrulama bağlantısına tıklayınca hiçbir onay tamamlama ya da durum göstergesi görünmediği için oldukça kafa karıştırıcıydı
Giriş yapılmış durumdayken bağlantı kontrol paneli ana sayfasına yönlendiriyor; dolayısıyla normal bir kullanıcı parola değiştirme düğmesine bastıktan hemen sonra e-postayı aldığı için önce çıkış yapması gerekiyor
E-postaya “önce çıkış yapın” ifadesini eklemek ya da bağlantının mevcut oturumu kapatıp ardından sıfırlama sayfasını göstermesi daha akıcı olabilir
Bunun güvenlik açısından kaçınılan bir şey olduğuna dair belirsiz bir anım var
Fikir oldukça iyi görünüyor ama şu anda hemen deneyecek vaktim yok
Yine de buradaki yorumlardaki açıklamayı okumamış olsaydım açılış sayfasında sekmeyi hemen kapatırdım
Fazla doğrudan olduğum için kusura bakmayın ama sayfa, sıradan bir AI havası taşıyan seri üretim açılış sayfası gibi görünüyor; gerçekten öyle demek istemiyorum ama açıklamalar iyi olduğu için biraz daha karakter katıp farklılaştırmak iyi olabilir
Ayrıca projeye özel bir Hacker News hesabı oluşturmamak daha iyi olur
“Kullanıcı adınızı şirketinizin ya da projenizin adı yapmayın. Bu, HN’yi tanıtım amaçlı kullandığınız izlenimini yaratır ve bir insan olarak katılmıyormuşsunuz gibi görünür. Gerçek adınızı kullanmanız gerekmez ama bir marka değil insan olarak orada olduğunuzu gösteren bir işaret olmalı. Kullanıcı adınızı değiştirmek isterseniz hn@ycombinator.com adresine e-posta gönderin.”
https://news.ycombinator.com/item?id=22336638
https://news.ycombinator.com/showhn.html bağlantısına da bakabilirsiniz
Şu an, neyi bildiğimle neyi bilmediğimin, umutların ve hayallerin, ayrıca oldukça büyük bir teknik bilgi birikiminin bulunduğu bir aşamadayım; tasarım tarafında güçlü değilim ama şimdilik bunun sorun olmadığını düşünüyorum
Pangram’a göre %100 ve açıkçası böyle bir araç olmasa bile anlaşılabilecek kadar belirgin; burada da bunu ayırt edemeyen insanların az olmaması oldukça karamsar bir tablo
Bu alana rekabet gelmesi sevindirici
Ancak kararlılık veya kullanım kolaylığı konusunda çok kaygılanmadan kendi kendine barındırmak istiyorsanız bind9 da RFC 2136 DNS UPDATE ve DNSSEC destekliyor
Benim kurulumumda ev yönlendiricim DNS UPDATE konuşamadığı için HTTP isteklerini dönüştüren küçük bir Go çalıştırılabilir dosyası da kendim yazdım
FortiGate üzerinde birkaç test senaryosu oluşturdum ve DynIP de ilk başta dahili DNS’in üstünde FortiGate’e özel basit bir kopyala-yapıştır çözümü olarak başladı
Windows veya Linux’taki çeşitli ana makinelerde dahili kullanım için kod örnekleri var; homelab’inizde IoT cihazları varsa Arduino örnekleri de mevcut
Go ile bir çalıştırılabilir dosya oluşturmak da iyi bir yaklaşım; bu yüzden
/docsaltındaki güncellemeleri takip edebilirsinizRFC 2136 desteği bonus puanı hak ediyor ve external-dns ile kolayca çalışıyor
Birkaç yıldır şirket içi Kubernetes ve external-dns’i, herkese açık host için en düşük yapılandırmalı, self-hosted bir BIND sunucusuyla birlikte kullanıyorum
Zaten fleet işletimi için bir rehber var; Kubernetes deseni de bunun doğal bir uzantısı olduğu için bir rehber yazmak gerekiyor gibi görünüyor
Eskiden OpenWrt DDNS betiklerini kendim yazıp AWS Route 53 veya Cloudflare DNS’i güncelliyordum ve bu yeterli oluyordu
Sonrasında Tailscale çıktıktan sonra DDNS ya da CGNAT konusunda artık kafa yormaz oldum
https://dynip.dev/guides/tailscale adresinde bunların nasıl ve neden birlikte var olabildiğini anlatan bir rehber yazdım
OpenWrt DDNS betikleri anahtarlar ve gizli değerler yüzünden biraz uğraştırıcı, ama snippet özelliği “bu nasıl çalışıyor?” diye tahmin yürütmek zorunda bırakmadığı için bundan oldukça memnunum
Herkese açık servisler için DynIP, sadece benim erişmem gereken şeyler içinse Tailscale kullanıyorum; böylece saldırı yüzeyi ciddi biçimde azalıyor
Neyse ki CGNAT’i dert etmeye gerek kalmıyor
Kayıt olmayı denedim ama doğrulama e-postası gelmiyor
Kayıttan hemen sonra posta sunucusu günlüklerinde de benzer bir iz yoktu; birkaç kez yeniden gönderim istedim ama 6–7 saat sonra bile gelen kutusunda hiçbir şey yok
Ücretsiz katmandaki kimlik doğrulama token’ının 24 saat sonra sona erip ermediğini merak ediyorum
JWT içindeki
expclaim’ine baktım ve geçiş için zaman harcamadan önce bunu bilmek istiyorumAsıl mesele ücretsiz katmanın sürdürülebilir olup olmadığı
Tüm zone’lar, tüm katmanlarda kendi TSIG anahtarlarını alır ve gerçek güncellemeleri bu anahtarlar yapar
Ücretsiz katmanda zone’lar panel üzerinden yönetilir; ücretli katmanlar ise programatik yönetim için ek API token’ları sunar
Dolayısıyla kimlik doğrulama token’ı API için bearer olarak kullanılır, TSIG ise alan adı silinmediği sürece geçerliliğini korur
Ücretsiz katman 5 zone’a izin verir ve her biri için ayrı TSIG anahtarı her zaman etkin kalır; yani yüzlerce zone oluşturup güncelleyen/silen bir kullanımınız yoksa ödeme yapmanız gerekmez
Harika yorumlar ve sorular için teşekkürler; birkaç saat kızımı yüzme dersine götürüp geldim, şimdi başlığı takip etmeye devam edeceğim
https://github.com/hickory-dns/hickory-dns gibi şeyleri de düşündünüz mü diye merak ediyorum
Elbette her şeyi Rust ile yapmak gerekmiyor
İlginç görünüyor; ev sunucumdan dış istemcilere birkaç servis sunmak için DDNS kullanıyorum
Şu anda NO-IP DDNS kullanıyorum; ücretsiz katmanı oldukça cömert ama Let’s Encrypt gibi şeyleri desteklememesi can sıkıcı
Cloudflare üzerinden bir alan adı almayı düşünüyorum ama DynIP’nin somut olarak farkının ne olduğunu merak ediyorum
2000’ler tarzı yalnızca HTTP(S) ile güncelleme de güzel
Sadece
curl/wget/fetchvarsa her yerde çalışır ve isterseniz yalnızca bir token eklersinizGörünüşe göre duckdns hâlâ bunu destekliyor; ayrı bir istemci gerektirmediği için neredeyse her yerde çalışıyor
curl/wget/fetchkısmı doğru; ayrıca/docsaltında bunun dışında yapabilecekleri özel şeylere de bakabilirsinizBurada yalnızca
curl/wget/fetchiçeren bir şey değil, daha geniş bir yetenek temeli sunmaya çalışıyorum