DNS’i öğrenmek neden hâlâ zor?

 (jvns.ca)
3 puan yazan GN⁺ 2023-07-29 | 1 yorum | WhatsApp'ta paylaş
  • DNS, 1980’lerden bu yana 35 yılı aşkın süredir kullanılıyor ve yapısı da istikrarlı; ancak birçok programcının temel sorunları kendinden emin şekilde debug edebilmesi uzun zaman alıyor
  • Zorluk, DNS’in kendi karmaşıklığından çok resolver cache’i, yerel DNS kütüphanesi, authoritative nameserver’larla yapılan konuşmalar gibi görünmeyen bileşenlerin çok olmasından kaynaklanıyor
  • dig güçlüdür, ancak çıktı yapısı ve terimleri yabancı gelebilir; +norecurse gibi özellikler faydalı olsa da sonuçları yorumlamak sezgisel değildir
  • negative caching, musl’ın geçmişte TCP DNS desteklememesi, TTL’i yok sayan resolver’lar, nginx’in kalıcı cache’lemesi, Kubernetes ndots gibi yaygın tuzakları biri anlatana kadar öğrenmek zordur
  • DNS ile nadiren uğraşanlar için cheat sheet’ler yardımcı olur; deneme yapmanın riskli geldiği sorunlar ise Mess With DNS gibi güvenli deney ortamlarıyla hafifletilebilir

Eski bir teknoloji olmasına rağmen zor olan DNS

  • DNS, RFC 1034 döneminden beri 35 yılı aşkın süredir kullanılıyor; internetteki tüm web sitelerinde yer alıyor ve birçok açıdan 30 yıl öncekiyle benzer şekilde çalışıyor
  • Buna rağmen “alan adını doğru ayarladım ama çözümlenmiyor” veya “dig ile tarayıcının DNS sonuçları farklı” gibi temel sorunları debug etmek uzun sürebilir
  • DNS’i zor bulan kişiler genellikle şu noktalarda takılır
    • Bir web sitesinde basit bir DNS değişikliğini bile rahatça yapamazlar
    • DNS kayıtlarının push edilmediğini, pull edildiğini karıştırırlar
    • Temel kavramları bilseler bile negative caching, dig ile tarayıcının DNS sorguları arasındaki fark gibi ayrıntılı davranışlarda kafa karışıklığı yaşarlar

Görünmeyen resolver’lar ve nameserver’lar

  • Bilgisayardan DNS isteği gönderirken temel akış basit görünür
    • Bilgisayar, resolver adlı bir sunucuya istek yapar
    • Resolver cache’i kontrol eder ve gerekirse authoritative nameserver’a yeniden istekte bulunur
  • Gerçek debug sürecinde önemli olan birçok unsur varsayılan olarak görünmez
    • Resolver’ın cache’inde ne olduğunu bilmek zordur
    • Yerelde hangi DNS kütüphanesinin isteği işlediği net değildir
      • libc getaddrinfo, glibc, musl, Apple implementasyonu, tarayıcının kendi DNS kodu, ayrı özel implementasyonlar vb. olabilir
      • Her implementasyonun ayarları, cache’leme biçimi ve özellik desteği biraz farklıdır
      • musl DNS, 2023 başına kadar TCP desteklemiyordu
    • Resolver ile authoritative nameserver arasındaki konuşma görünmez
      • Hangi authoritative nameserver’a sorgu yapıldığını ve onun yanıtını takip edebilmek, birçok DNS sorununu daha kolay anlamayı sağlar

Gizli sistemleri görünür kılan yaklaşım

  • Gizli bileşenlerin neler olduğunu göstermek bile öğrenmeye büyük katkı sağlar
    • Tek bir bilgisayarda bile duruma göre birden fazla DNS kütüphanesinin kullanılabileceğini bilmezseniz uzun süre kafa karışıklığı yaşayabilirsiniz
  • Mess With DNS, normalde görünmeyen kısımları gösteren fishbowl tarzı bir deney yaklaşımı dener
    • Resolver ile authoritative nameserver arasındaki konuşmanın bir kısmını görmeyi sağlar
  • DNS yanıtlarına debug bilgisi ekleme yöntemi de vardır
    • Zaten Extended DNS Errors veya EDE adlı bir özellik mevcut
    • Araçlar EDE desteğini yavaş yavaş ekliyor

Extended DNS Errors’ın verdiği ipuçları

  • Extended DNS Errors, DNS sunucusunun yanıta ek debug bilgisi koymasını sağlayan yeni bir yöntemdir
  • Var olmayan xjwudh.com alan adı dig @8.8.8.8 xjwudh.com ile sorgulandığında aşağıdaki gibi ek bir hata gelebilir
; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)
  • Bu örnek DNSSEC ile ilgili bir öğe gibi görünüyor; önemli olan, yanıtın içinde ek bir debug mesajının da gelmesidir
  • Yukarıdaki örneği görmek için daha yeni bir dig sürümü gerekiyordu

Güçlü ama okunması zor dig

  • DNS’in iç durumunu kontrol etmek için dig faydalıdır
  • dig +norecurse kullanarak belirli bir DNS resolver’ın cache’inde hangi kayıtları tuttuğunu kontrol edebilirsiniz
    • 8.8.8.8, yanıt cache’te yoksa SERVFAIL döndürüyor gibi görünüyor
    • google.com cache’te olduğu için NOERROR ve A kaydı döndürüyor
    • homestarrunner.com cache’te olmadığı için SERVFAIL döndürüyor; ancak bu, DNS kaydının olmadığı anlamına gelmez
  • dig çıktısı alışık değilseniz okunması zordur
    • ->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION:, ANSWER SECTION: gibi başlıklar yabancı gelir
    • Bölümler arasındaki satır sonları ve boşluklar tutarlı hissettirmez
    • MSG SIZE rcvd: 47 içinde rcvd dışında başka alanlar olup olmadığını anlamak zordur
    • ADDITIONAL bölümünde 1 kayıt olduğu söylenirken aslında bu rolü OPT PSEUDOSECTION’ın üstlendiğini bilmek gerekir
  • dig çıktısı, baştan bilinçli olarak tasarlanmış bir format olmaktan çok zamanla organik şekilde büyümüş bir script gibi görünür

DNS araçlarını daha okunur hâle getirme yolları

  • dig çıktısının kendisini açıklayan dokümantasyon yardımcı olur
    • how to use dig, dig çıktı yapısını ve varsayılan çıktıyı kısaltma yollarını açıklar
  • Daha kullanıcı dostu araçlar da geliştirilebilir
    • dog, doggo, DNS lookup tool gibi alternatifler var
    • Ancak +norecurse gibi gelişmiş özellikler gerektiğinde işi tek başına dig ile yapmak daha iyi olabilir
    • dig’in geniş özellik kapsamını değiştirmek büyük bir iştir
  • dig çıktısına +human gibi bir seçenek ekleyerek aynı bilgiyi daha yapısal biçimde göstermek de mümkün
    • Header, sorgu, yanıt, ek bölümler, süre, sunucu, protokol ve yanıt boyutu net şekilde ayrılabilir
    • Bu, bilgi miktarını azaltmak değil, aynı bilgiyi daha okunur biçimde sunma yaklaşımıdır
  • Güncel dig sürümlerinde +yaml çıktı formatı bulunur
    • Daha anlaşılır gelebilir; ancak basit bir DNS yanıtı bile ekrana sığmayacak kadar uzun olabilir

Sık karşılaşılan ama öğrenmesi zor DNS tuzakları

  • DNS’te görece sık yaşanan, ancak biri söylemeden bilinmesi zor tuzaklar vardır

  • negative caching

    • Henüz DNS kaydı olmayan bir alan adını ziyaret ederseniz, o kaydın “yok” durumu cache’lenebilir
    • Bu durum birkaç saat cache’te kalırsa oldukça can sıkıcı olur

  • getaddrinfo implementasyon farkları

  • TTL’i yok sayan resolver

    • DNS kaydı TTL’ini 5 dakika olarak ayarlasanız bile bazı resolver’lar bunu yok sayıp 24 saat gibi daha uzun süre cache’leyebilir

  • nginx yapılandırma sorunu

    • nginx’i yanlış yapılandırırsanız DNS kayıtlarını sonsuza kadar cache’leyebilir

  • Kubernetes ndots

    • ndots, Kubernetes DNS’ini yavaşlatabilir

Tuzakları paylaşma ve dokümante etme yöntemi

  • Garip tuzaklarla ilgili bilgi edinmek zordur; insanların aynı sorunu tekrar tekrar yeniden keşfetmek zorunda kalması verimsizdir
  • Bir konuyu anlatırken yaygın tuzaklara da değinmek çok yardımcı olur
    • DNS dışından bir örnek olarak, Josh Comeau’nun Flexbox tanıtımı minimum size gotcha konusunu açıklar
  • Topluluğun yaygın tuzakları bir araya getirmesi de faydalıdır
    • Bash için shellcheck, bash tuzakları derlemesi olarak çok yararlıdır
  • DNS tuzaklarını dokümante etmek, her kullanıcının karşılaştığı sorunlar farklı olduğu için de zordur
    • Üç yılda bir kişisel alan adının DNS’ini ayarlayan biri ile yüksek trafikli bir alan adının DNS’ini yöneten biri farklı tuzaklarla karşılaşabilir

Seyrek kullanım ve deney yapmanın zorluğu

  • Birçok kişi DNS ile çok nadiren uğraşır
    • DNS’e üç yılda bir dokunuyorsanız öğrenmenin zor olması doğaldır
    • “Nameserver değiştirme adımları” gibi cheat sheet’ler yardımcı olabilir
  • DNS, kendi alan adınızı bozma riski taşıdığı için deneme yapmaktan çekinilen bir teknolojidir

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-29
Hacker News görüşleri

  • Bu yazıya katılmıyorum. DNS’in gerçekte öğrenmesi zor olmadığını, sadece öğrenmek için zaman ayıran kişinin az olduğunu düşünüyorum
    DNS’in iyi yanı, bir sorgu karşısında sistemin kendi iç durumunu size söylemesidir. Bilinen bir zone için DNS sunucusunu inceleyip nasıl çalıştığını anlamak kolaydır; dig gibi ücretsiz araçlar da yaygın olarak kullanılabilir
    Kariyerim boyunca birlikte çalıştığım insanların DNS bilgimi en çok hatırlamasına hep şaşırmışımdır; çünkü gizemli ya da özel bir şey bildiğimi düşünmüyorum. DNS çok iyi standartlaştırılmıştır, yaygın sunucu ve istemci implementasyonları da standartlara sıkı biçimde uyar, ücretsiz araçlarla gözlemlemesi de kolaydır. Emek ve zaman ister, ama gerçekten zor değildir

    • Bu yazının yazarı olarak, DNS aslında zor değildir bakış açısı hakkında birkaç şey söylemek istiyorum. DNS sorunlarını tamamen rahat şekilde debug edebilmem yıllar aldı ve bu yazıyı bunun bana neden zor geldiğini açıklamak için yazdım
      Eskiden “Hayır, aslında kolay!” demenin “öğrenmesi zor” sözüne karşı bir cesaretlendirme olduğunu düşünürdüm. DNS’i seviyorum ve birçok açıdan şaşırtıcı derecede basit olduğunu da düşünüyorum. Örneğin https://implement-dns.wizardzines.com adresinde, basit Python koduyla sıfırdan oyuncak bir DNS resolver’ı nasıl implement edileceği gösteriliyor
      Ama zamanla “Hayır, öğrenmesi kolay!” sözünün çoğu zaman “Yapabilirsin!” diye cesaretlendirmekten çok “Zor değil, sen aptalsın” gibi algılandığını öğrendim. Yıllarca kafamı karıştıran bir konuda “Aslında kolay ama?” denmesini duymak pek yardımcı olmuyor
      Bu yüzden artık böyle söylemiyorum; insanların belirli bir şeyi neden zor bulduğunu anlamaya ve o engelleri azaltmaya çok çaba harcıyorum
    • DNS öğrenme araçları açısından bakınca öğrenmesinin zor olduğunu düşünüyorum
      BIND işini harika yapıyor ama yapılandırma dosyaları pek iyi değil; kılavuzu uzun, kuru ve bazen gereksiz yere karmaşık. dig güçlü, ama her şeyi 80 sütunluk terminal kullanılan dönemlerdeki gibi kısaltıyor. DNS sorunlarını debug ederken Wireshark’ın dig’den daha iyi bir araç olduğu zamanlar da oldu
      İnsanlara PowerDNS ya da başka modern DNS sunucuları kullandırsak, çalışan bir DNS sunucusu kurmalarının çok daha kolay olacağını düşünüyorum. İyi ve modern bir DNS istemcisini pek bilmiyorum; sonunda dig’e alıştım. ip komutunun --color bayrağını kullanan biri olarak, dig gibi araçların da daha modern bir çıktı vermesini isterdim. Komut satırı bayraklarını alias’larla toparlarım; yeter ki özelliği eklesinler
      Ciddi söylüyorum, MSG SIZE rcvd: 71’in kısaltılmasına gerek yoktu. flags: qr rd ra da açık yazılabilirdi. Satır başındaki noktalı virgüllerin ne anlatmaya çalıştığını da bilmiyorum; daha çok kafa karıştırıyor
      İnsanların kendilerine sunulan materyallerle DNS öğrenirken kafasının karışması garip değil
    • “Bu yazıya katılmıyorum” demişsiniz ama yazının argümanlarına neredeyse hiç yanıt vermemiş, yalnızca başlığa itiraz etmiş gibi görünüyorsunuz. Üstelik DNS zordur ile DNS öğrenmesi zordur konularını birbirine karıştırıyor gibisiniz
      “Biraz emek ve zaman gerekiyor” ise, ne kadar emek ve zaman gerekiyor? Bu başlıktaki birçok kişi sunucu implement ederek öğrendiğini söylüyor, anlamasının aylar sürdüğünü söyledikten sonra “bir kez anlayınca oldukça kolay” diye tekrar ediyor. O hâlde bu kadar yaygın ve kavramsal olarak basit bir şey için, pratikte öğrenmesinin zor olduğu konusunda uzlaşamaz mıyız?
    • Yazıyı okursanız neden öğrenmesinin zor olduğu anlatılıyor. Kavramlar kolay, ama kavramlar öğretilirken modern internetin ayrıntılarının tamamı dahil edilmiyor
      Örneğin bir tarayıcının DNS kayıtlarını cache’leme ve süresini doldurma kuralları nelerdir? Bu kurallar tarayıcılar arasında tutarlı mı?
    • DNS’in, kariyer boyunca oradan buradan parçalar hâlinde duyulup geçilebilen teknolojilerden biri olduğunu düşünüyorum. Pek çok kişi onu doğrudan ele almak zorunda kalsaydı, gerçekte olduğundan daha az karmaşık hissederdi; ama sektörde bu tür şeyler bir çeşit gizem havası kazanıyor

  • Yazının asıl noktayı iyi yakaladığını düşünüyorum. DNS’in kendisi zor değil, ama gerçek dünyadaki DNS’i öğrenmek zor. Çünkü bir sorguyu başlatıp beklediğiniz sonucu alana kadar aradaki pek çok şey gizlidir
    Eskiden temel internet bağlantısı bir arayüz, bir gateway ve bir DNS sunucusu sağlayıcısından ibaretti. Şimdi LTE ve WiFi gibi birden fazla WAN’a aynı anda bağlı olunabiliyor; kullanıcı da gerçekte hangi çözümleme yolunun kullanıldığını anlamakta zorlanıyor. Bunun tarayıcı mı, sistem C kütüphanesinin standart arayüzü mü, aradaki yerel resolver ya da recursive resolver mı olduğu; yerel cache bulunup bulunmadığı ve varsayılan olarak özel seçenekler eklenip eklenmediği bile belirsiz
    Her şey çalışsa bile, bir uygulamanın sorgu ve yanıtının başka bir uygulamayla aynı yolu kullandığına körü körüne güvenemezsiniz. Üç tarayıcı üç farklı yöntem kullanır, işletim sistemi de başka türlü davranır; buna mDNS de beşinci seçenek olarak eklenebilir

  • Bilgisayar bilimlerinde zor olan yalnızca üç problem vardır diye bir şaka vardır: cache invalidation ve isimlendirme
    DNS de nesnelerin adları için bir caching sistemidir
    https://reddit.com/comments/15c2ul2/comment/jtty9dy

    • Adil olmak gerekirse DNS, isimlendirmeyi doğru yapan örneklerden biridir
      Küresel ölçekte yönetilir (IANA), hiyerarşiktir, federatiftir ve değiştirmesi de kolaydır

  • DNS, göründüğü kolaylık ile pratikte ortaya çıkan zorluk arasında uyumsuzluk olan türden bir teknoloji
    DNS’i her gün kullanıyoruz ve çok kolay görünüyor. Günlük DNS dili alan adı, sorgu, IP adresi. Bu dil tarayıcıda doğrudan görünür oluyor ve bu görünürlük üzerinden nasıl çalıştığına dair zihinsel bir model kuruyoruz
    Ama içeride zone’lar, resolver’lar, devredilmiş yetkiler, üst seviye alan adının arkasındaki tuhaf nokta gibi bambaşka bir dil var

    • O tuhaf noktaya root denir. Nokta yoksa ad tam değildir; nokta varsa ad tamamen tanımlanmıştır. Yani bağlam her şeydir. Nokta yoksa resolver kendi alan adını ya da onun bir parçasını tekrar tekrar ekleyebilir
      Örneğin host.example.co.uk ifadesinin ne anlama geldiğini ikimiz de biliriz, ama sonunda nokta yoksa resolver host.example.co.uk.example.co.uk için sorgu yapmayı deneyebilir
      Windows varsayılan ayarlarında böyle bir durumda host.example.co.uk.example.co, host.example.co.uk.example, yeniden host.example.co.uk.example ve ardından host.example.co.uk. denenerek sonuç alınabilir. Ancak gerçekten ilk denemeyi yapan bir Windows görmedim; bu davranış, DNS’in birleşik bir canavar gibi Active Directory’ye sahip büyük kurumsal ortamları idare etmeye çalışması için tasarlanmış gibi görünüyor
      Günümüzde tarayıcıların, kullanıcı onayı olmadan usulca DNS over HTTPS(DoH) sunucularına gidip her tür şüpheli tarafla takılma ihtimali yüksek. DNS sorguları temel veridir; ISP’ler de kullanıcının nereye gittiğini görmeyi severdi. İşletim sistemi üreticisi de elbette “telemetri” gönderebilir. Google masaüstüne sahip değil ama tarayıcıya sahip; bu yüzden kullanıcıların ayarladığı DNS yerine “güvenli” DNS sunucularını kullandırmak onların işine gelir. Bu tür numaralar yüzünden IT sorun giderme eskisinden çok daha heyecanlı hale geldi
      Sondaki nokta için fazla endişelenmeye gerek yok. Zaten neredeyse kesin olarak kullandığınızı sandığınız DNS sunucusunu kullanmıyorsunuz. DoH’un neden yapıldığını anlıyorum ve bazı sıradan kullanıcılar için kullanma nedeni de var. Örneğin IT uzmanı olmayan biri kötü niyetli bir WiFi hotspot’u kullanıyorsa, tarayıcının güvenli biçimde ana merkeze dönüp DNS sorgusu yapması bir miktar koruma sağlar. Ama tarayıcı üreticisinin kullanıcının uç nokta güvenliği tercihlerini çiğnemeye hakkı olup olmadığı ayrı mesele
      DNS, yalnızca adres sorgulamaktan çok daha karmaşık. Bugün mesele para; aslında yaklaşık 2000’den beri hep öyleydi. Artık kullanıcı üzerinden kimin kâr edeceğine karar vermek isteyen çok inatçı dev şirketler var
    • Zor olanın dağıtık kısmı olduğunu düşünüyorum. Tekil düğümlerin atomik seviyesinin üzerinde muazzam bir kara büyü dönüyor; karmaşıklığın büyük kısmını ve opaklığın büyük kısmını da bu yaratıyor
      DNS’in kendisi kolay. Kuruluşa bağlı olmayan bilgi dağıtımı gerçekten çetrefilli

  • Birkaç yıl önce DNS’i sadece parça parça anladığımı fark ettim. dig(1), BIND ve özyinelemeli DNS çözümlemenin nasıl çalıştığına dair CS101 seviyesinde kavramları biliyordum; ama önemsiz olmayan bir sistemi tasarlayıp uygulamak ya da çalışmayan bir sistemi debug etmek için gereken pratik bilgi bende eksikti
    Bu yüzden “DNS and BIND”i neredeyse baştan sona okudum ve daha az önemli birkaç kişisel web sitesi için gerçek BIND sunucuları da kurdum. Zor değildi ama ciddi zaman yatırımı gerektirdi. BIND pek çok kullanım senaryosu için doğru cevap değil, fakat DNS’teki birçok kavram ve terim hâlâ BIND’den geldiği için çok değerliydi
    Böyle şeyleri öğrenmede kitapların değerinin hafife alındığını düşünüyorum. Web’de bulunan kaynaklar genelde özyinelemeli sorgu blok diyagramı gibi üst seviye teori; dig ile özyinelemeli sorgu yapma gibi görev odaklı materyaller; ya da yerel DNS istemcisinin yeniden deneme politikasını anlamak için kaynak kod okumak gibi düşük seviyeli materyaller oluyor. Her parçayı ve bunların nasıl birbirine uyduğunu, neyi başarmaya çalıştıklarını; cache’lerin nerede bulunduğu gibi uygulama ayrıntılarına kadar anlamak için kitaplarda sık görülen bütüncül yaklaşımın yerini alacak pek az şey var. Web’de hiç yok değil ama nadir

  • Tüm IT çalışanlarının DNS sorunlarını debug etme konusunda pratik bilgi sahibi olması iyi olur
    DNS tarihsel olarak önemli güvenlik açıklarının kanalı oldu ve muhtemelen böyle olmaya devam edecek. Bu açıklar SMTP gibi neredeyse tüm diğer protokoller için saldırı yollarına dönüşür. HTTPS’te kullanılan sertifika otoritesi sistemi bile temelde güvenli olmayan bir protokole büyük ölçüde dayanır. Bir banka OV yerine DV sertifikası alsa fark edebilir miyiz? Muhtemelen hayır
    Bu yüzden ilgisi az olan birine DNS’in öğrenmesi zor görünmesi ille de kötü değil. Çünkü bugün bile port randomizasyonu, cache zehirlenmesi, AXFR gibi şeylerin tarihini doğru dürüst anlamaya zaman ayırmadan DNS ile ilgili özellikler geliştiren insanlar görüyorum

    • Ağın herhangi bir katmanında routing kararlarını yayınlayan ya da iddia eden her şey dışarıdan göründüğünden basit görünse de potansiyel olarak tehlikeli geliyor

  • Utanç verici bir yan proje reklamı yapacak olursam, yazıda DNS çözümlemesi için bir “debug” modu olsa iyi olur denmişti; ComfyDNS web UI’ında bu özellik var :3
    https://comfydns.com/
    Üst tarafta TRACE google.com A IN yazan görsel o özellik
    ComfyDNS aynı zamanda kişisel bir kaşıntıyı kaşıma projesi. bind9 zone dosyalarını elle düzeltmekten yorulmuştum ve DNS’in nasıl çalıştığını da merak ediyordum. Yüzeysel kısmı biliyordum ama ayrıntıları bilmiyordum; bu yüzden RFC’yi “sıfırdan” uyguladım. netty kullandım ama DNS kütüphanesi kullanmadım. Oldukça eğlenceliydi
    Site trafiğe dayanamayıp düşerse kusura bakmayın. Oracle Cloud ücretsiz katmanında çalışan bir Rails uygulaması

  • Hep duyduğum şaka, DNS’in bilgisayar bilimindeki en zor iki problemi, yani isimlendirme ve cache geçersiz kılmayı birleştirdiğiydi

    • DNS’te saniye cinsinden bir geçerlilik sayacı var ve o saniyeleri sayarken epey gevşek davranılabiliyor
      Zor türden bir cache geçersiz kılma değil. Aslında “geçersiz kılma” yapmaya neredeyse hiç gerek yok
      Sunucu tarafında da eski sürüm ile yeni sürümü bir süre karışık göndermek tamamen kabul edilebilir
    • Şaka değil, doğru söz

  • Yine böyle bir yazı çıkmış hissi veriyor. 1990’larda internet daha küçüktü, bilgisayarlar çok daha yavaş ve düşük performanslıydı ama biz çok kolay öğreniyorduk
    O dönemde bir ISP için DNS, LDAP, SMTP, IMAP gibi şeyler en temel konulardı; insanlar gerçekten RFC gibi resmî belgelere bakardı. İnternette sunucu çalıştırmak istiyorsanız öğrenmek zorundaydınız ve biraz zaman yatırımıyla, yani iş yerinde aldığınız ücretli zamanı kullanarak öğrenilebiliyordu
    Günümüz geliştirici ve DevOps kuşağında sabır ya da inisiyatif yok; her şeyin önlerine hazır konmasını bekliyor, StackOverflow’dan ve düşük değerli bloglardan rastgele şeyleri kopyalayıp yapıştırıyorlar. İnternetin üzerine kurulduğu temeli öğrenmek yerine o haftanın en yeni moda wrapper aracını alıp kötü blog talimatlarını izliyorlar; her şey çöküp şirkete büyük para kaybettirdiklerinde de haksızlığa uğramış gibi davranıyorlar. Çünkü internette işlerin gerçekte nasıl yürüdüğüne dair temelleri öğrenmeye zaman ayırmamış oluyorlar
    Bunu sürekli görüyorum. Aslında o kadar zor değil. Ödevini yapmak yeterli

  • Zor değil. DNS, çok değişmemiş az sayıdaki teknolojiden biri ve işleyişi de oldukça sezgisel
    dig biraz kafa karıştırıcı olabilir. Eski nslookuptan daha fazla özelliği var ama daha az sezgisel. Bu arada nslookup hâlâ gayet iyi çalışıyor
    Sektördeki genç insanların DNS ve temel protokoller konusunda kafasının karışmasının nedenlerinden biri bence artık çok fazla şeyin “kendiliğinden çalışması”
    Örneğin günümüzde WiFi yönlendiriciler kutudan çıkar çıkmaz “kendiliğinden çalışıyor”. 2000’lerin başında böyle bir şeyi yapılandırmak için DNS, IP, Ethernet, RFC1918, gerçek yönlendirme protokolleri ve daha pek çok şeyi bilen bir ağ mühendisi gerekirdi; muhtemelen neden öyle yapılandırıldığını da gayet iyi bilirdi
    İstemci tarafından bakınca DNS kafa karıştırıcı geliyorsa BIND yapılandırmayı deneyin ;-)
    /yaşlı boyun sakallının yakınması

    • 14 yaşındayken DNS ya da DHCP’yi anlamadan, bir restoranın Active Directory ortamını; e-posta, web ve CIFS dâhil olacak şekilde derme çatma yönetiyordum
      WRT54G’nin DHCP sunucusunun, doğru ad çözümlemesi için etki alanı denetleyicisinin sabit IP’sini DNS sunucusu olarak dağıtmasını sağlamalıydım; ama bunun yerine IP adresleri ve hosts dosyası girdileriyle her şeyi çalışır hâle getirmiştim. Alan adının MX kaydını da yönlendiricinin WAN IP’sine ayarlamıştım, PTR kaydı yoktu. Geriye dönüp bakınca e-posta tesliminin bu kadar sorunsuz olması mucizeymiş
      Birkaç yıl sonra DNS’in gerçekte nasıl çalıştığını öğrendim ve 20’li yaşlarımın başında, tüm haricî şirket alan adı zoneleri için ad sunucusu olarak BIND kullanan bir şirket intranetini devraldım. Güvenilirliği artırmak için bu yapılandırmayı bir VPS’ye taşırken zone transferleri, SOA vb. hakkında gerçekten çok şey öğrendim. O deneyim için minnettarım ama günümüzde neredeyse her şey sizin yerinize halledildiği için düşük değerli bir faaliyet hâline geldi. İyi ya da kötü, “IT”, “yazılım mühendisliği” ile aynı şekilde değerlendirilmiyor
    • İşleyişinin nispeten sezgisel olduğu doğru, ama bu TTL’yi yok sayan sunucular gibi her türlü tuhaf davranış olasılığını göz ardı ettiğinizde geçerli
      Firefox’un DNS-over-HTTPS’i varsayılan olarak açan bir güncelleme yayımladığı zamanı unutamıyorum. DHCP ile iş istasyonlarına dahili DNS sunucularımızı dağıtıyorduk; bir anda “E-postalarım kayboldu! Her şey bozuldu!” şikâyetleri yağmaya başladı. Dahili webmail ve intranet web sunucusu sanki ortadan kaybolmuş gibi görünüyordu
      Ne olduğunu anlamak gereğinden çok daha uzun sürdü. Bunun bir nedeni de “Bu DNS, durduk yere neden bozulsun ki?” diye düşünmemizdi. Ama Mozilla’nın bu kolayca öngörülebilecek sorunu tahmin edemediği oldukça açıktı
    • Burada anlatılanlar DNS’in yalnızca küçük bir kısmı
      Örneğin thing.behind.cdn.it sorguladığımda ben bir yanıt alıyorum, başka biri aynı ad için farklı bir yanıt alıyor. Bu tek başına oldukça açık; ama biri makul biçimde “thing.behind.cdn.it için güvenlik duvarında bir delik açabilir misiniz?” diye sorduğunda işler karmaşıklaşıyor
      Bazı sunucular istekleri iletir, bazıları yetki devreder; bazı sunucular sizin yerinize sorgu yapar, bazıları yapmaz. İstemcinin arama alan adı sihri de var; istemcinin ya da dahili resolver kütüphanesinin TTL’ye uyup uymayacağı da belirsiz
      Kayıt türleri sayısız ve bazen sunucu UDP yerine TCP ile yeniden bağlanmanızı da söyleyebilir
      Bu yüzden DNS epey karmaşık. Çok iyi çalıştığı ve zor kısımların çoğu “genelde kendiliğinden çalışan” şeylerin arkasına soyutlandığı için basitmiş gibi bir yanılsama yaratıyor
    • Eski protokolleri bilmekle ilgili olarak, son birkaç haftadır Networking for System Administrators kitabını okuyup çok sayıda Anki kart notu oluşturdum ve tekrar ettim
      DNS’ten onun altındaki ethtool, Ethernet frame’leri gibi şeylere kadar ağ teknolojilerini üst düzeyde anlama konusunda özgüvenimin çok artması şaşırtıcı
      Konuları en temelden bilmeyi sevdiğim için üniversitede bilgisayar bilimi yerine elektrik mühendisliğini seçmiştim; belki de bu o kadar şaşırtıcı değildir
    • Evet, BIND yapılandırması zor. Unbound/nsd ile uğraşmak çok daha kolay. Yine de doğru dokümantasyonu bulma sürecinin kendisi sinir bozucu bir alıştırma
      DNS’in ilkelerini, özyinelemeli olduğunu anladığınızda o kadar zor değil. Ama güvenliği dikkate alarak yapılandırmak, doğru altyapıya sahip olmak ve son ayrıntıya kadar her şeyi doğru yapmak için öğrenilecek çok şey var. BIND’i hariç tutarsak o kadar da zor değil