İnternet ve Politika

İnternet, bir mücadele alanıdır ve mücadele içinde sürekli yeniden üretilir. Şirketler, internetteki ilişkilerin metalaşmasını arzulamaktadır. Kendileri bu yönde sınırsız hareket ederken internet kullanıcılarının hareketlerinin sınırlanması için lobi faaliyetleri yürütürler. Hükümetler, diğer iletişim araçlarında olduğu gibi tamamen kontrol edebilecekleri bir internet için uğraşmaktadır. Ayrıca ABD, internetteki hegemonyasını devam ettirmek isterken diğer ülkeler buna son vermek için çeşitli girişimlerde bulunmakta ve ABD kökenli şirketlere karşı kendi şirketlerini desteklemektedir. Bireylerin geliştirdiği uygulamalar (vikiler, portal yazılımları, sosyal ağlar, bitcoin vb) internette yeni ufuklar açmıştır. Hükümet dışı uluslararası örgütler ve sivil toplum örgütleri internete yönelik düzenlemelerde kamuoyu oluşturarak internetin yeniden üretiminde belirleyici olabilmektedir.

Bunun yanında toplumun farklı kesimlerinin internet hakkındaki düşünceleri de çelişmektedir. İyimserler, onun toplumu demokratikleştireceğini, yeni “bahar”ların önünü açacağını düşünmektedir. İnternete şüpheyle yaklaşanlar ise internetin hükümetlerin ve şirketlerin gözetim aygıtı haline geldiğini savunmaktadır. Bir taraf internetin kontrol edilemez ve adem-i merkeziyetçi yapısına diğer taraf da artan kontrol mekanizmalarına işaret etmektedir. Aslında merkezi kontrol, internetin ilk günlerinden beri vardır. Fakat bu kontrol, hükümetler ya da şirketler tarafından değil internetin oluşumunda yer almış kişiler ve örgütler tarafından gerçekleştirilmektedir. Yazının devamında da tartışılacağı gibi eşgüdüm için merkezi kontrolün gerekli olduğu durumlar olabilmektedir. Sorun, kontrolün varlığı değil, kimin ve nasıl kontrol ettiğidir. Günümüzde bu kontrolü, hükümetler ve şirketler lehine artırma girişimleri vardır. Bu girişimler, uluslararası yasalarla yapıldığında sürece müdahale her zaman kolay olmamasına karşın daha geniş kesimlerce anlaşılabilmekte ve tartışılabilmektedir. Söz konusu teknolojik düzenlemeler olduğunda ise tartışma tekniğin nesnel örtüsünün altında saklanmaktadır. İddia bir politikacıdan geldiğinde, örneğin Cumhurbaşkanı Erdoğan “4G ile vakit kaybetmeden 5G’ye geçmeliyiz” dediğinde bunun ağırlıklı olarak (ya da tamamen) politik bir tercih olduğu hemen fark edilir. Ama mühendislerin ve bilim insanlarının teknoloji hakkında yaptıkları açıklamalar ve toplumu belirli bir teknolojiye ikna etme çabaları nesnel ve tarafsız değerlendirmelerin bir sonucu olarak algılanır; bir teknoloji “bilimsel olarak öyle olması gerektiği için öyle olmuştur.”

Ancak teknoloji tarafsız değildir. Onu tasarlayanların ve tasarımına etkide bulunanların niyetlerini ve değerlerini içerir. İnternet gibi henüz sınırları tam olarak kalın çizgilerle çizilmemiş teknolojiler gelişime ve müdahaleye daha açıktır. Bu nedenle, internetin yapısı hakkında bir değerlendirme yaparken onun sürekli değiştiğini dikkate almak gerekir. Kritik noktalarda atılacak adımlar veya tasarımda öne çıkan tercihler interneti şimdikinden çok farklı bir yere sürükleyebilir. İnternetin mimarisindeki bir değişim internetteki güç dengelerini de altüst edecektir.

İnternetin mimarisi üzerindeki mücadele başlıca üç alanda gerçekleşmektedir. Birinci alan, internetteki teknik standartların oluşturulmasıdır. Bilgisayarlar arasında bilgi belirli standartlara göre akar ya da sınırlanır. “Enformasyon, özgür olmak ister” diye söylense de enformasyon standartların izin verdiği ölçüde özgür olabilir. Mahremiyet, fikri mülkiyet ve ifade özgürlüğü kabul edilen standartlar çerçevesinde farklılaşabilir. İkinci alan ise kaynakların nasıl paylaştırılıp yönetileceğidir. Yeni teknolojiler, geliştirilen teknolojiden türeyen kaynaklar yaratırlar. Örneğin, elektronik haberleşme hizmeti sunabilmek için adınıza tahsis edilmiş bir frekans bandına gerek vardır. İnternette var olabilmek için de özel bir (IP) adresimiz (ör. 159.253.42.233), sitemize web tarayıcıdan rahatça erişilebilsin diye bir alan adımız (ör. bilimvegelecek.com.tr) olmalıdır. 1998 yılında kurulan ICANN ( Internet Corporation for Assigned Names and Numbers – İnternet Tahsisli Sayılar ve İsimler Kurumu) “internet alan adları sisteminin teknik yönetimini, IP adres alanlarının tahsisini, protokol parametrelerinin belirlenmesini ve internet ana servis sağlayıcı (root server) sisteminin idaresini koordine etmekle görevlendirilmiş” ABD’li bir kuruluştur. Sınırlı sayıda olan IP adreslerinin adil ve eşgüdüm içinde dağıtılması gerekmektedir. Üçüncü alan ise internete dair politikaların belirlenmesi, uygulanması ve anlaşmazlıkların çözümüdür. Örneğin, internetin güvenlik politikaların oluşturulmasında (özellikle 11 Eylül sonrasında) hükümetler kadar interneti daha güvenli ve cazip bir alışveriş merkezi haline getirmek isteyen şirketlerin de payı vardır. Güvenlik için atılan adımlar ifade özgürlüğü ve mahremiyet açısından bir tehdit oluşturabilmektedir.

Şirketlerin ve hükümetlerin keskin hamleler yaptığı bu oyunda bizim için en doğru adım, oyuna dahil olabilmemiz için açık standartların savunulması olacaktır. Standart, iletişimin tarafların kabul ettiği belirli kurallar çerçevesinde gerçekleşmesini sağlar. Bu durumda, kuralları kimin koyduğunun ve bunu nasıl yaptığının sorgulanması gerekir. Bir standardı açık olarak nitelendirebilmek için en başta standart oluşum süreçleri şeffaf olmalıdır :

1. Sürece katılanların kimlikleri bilinmelidir.
2. Dışarıdan alınan fonlar varsa açıklanmalıdır.
3. Süreçte yer alanlar, üye oldukları örgütleri ya da çalıştıkları şirketleri saklamamalıdır.
4. Standart seçiminin nasıl yapıldığı (oy birliği, oy çokluğu veya başka bir yöntem) paylaşılmalıdır.
5. Standart fikri mülkiyet içeriyorsa bu durum belirtilmelidir.
6. Toplantılardan çıkan sonuçlar kamuoyuyla paylaşılmalıdır.

Ayrıca standart oluşum sürecine isteyen herkese katkıda bulunabilmeli ve süreci takip edebilmelidir. Standart açık olduğunda, toplumun farklı kesimlerinin standarda kendi değerleri ve çıkarları doğrultusunda müdahale edebilmesinin önü açılmaktadır.
Bu bağlamda, IP (İnternet Protokolü) tartışmaları, internetteki mücadeleyi, mücadelenin taraflarını ve internetin yapısına etkisini göstermesi açısından son derece öğreticidir. Sadece teknik olarak görünen bir olgu altında politik mücadeleleri barındırmaktadır.

IP Nedir?

IP (İnternet Protokolü), bilişim teknolojilerinde yer alan binlerce standarttan biridir. Ancak alternatifinin olmaması nedeniyle kritik bir standarttır. IP bilgisayarlar arası iletişimde paketi parçalar ve hedef bilgisayara gönderir. Bu iletişimde yer alan bilgisayarların bir IP adresinin olması gerekmektedir. İnternette aynı anda, aynı IP adresine sahip iki bilgisayar olamaz. IP adresi, 32 bitten oluşur ve 8 bitten oluşan 4 parçaya bölünür (ör: 10011111 11111101 00101010 11101001). IP adresini okurken (ya da yazarken) her 8 biti ondalık sisteme çeviririz (ör: 159.253.42.233). Teorik olarak bir IP adresi 4294967296 farklı değer alabilmesine rağmen bu adreslerin bir kısmı özel ağlar ve çoklu gönderim için ayrıldığından kullanılabilir IP adresi sayısı daha azdır.

Hala yaygın olarak kullanmakta olduğumuz IP’nin dördüncü sürümüdür ve IPv4 olarak gösterilir. Aslında IP’nin öncesinde başka bir sürümü yoktur. Daha önce TCP’ye (Transmission Control Protocol) bağlı bir protokol olması ve TCP’nin de üç eski sürümü olması nedeniyle IPv4 olarak adlandırılmıştır.

IPv4 adresleri kıt bir kaynaktır ve kullanılan protokolün tasarlandığı yıllarda internetin bu kadar hızlı yaygınlaşacağı öngörülememiştir. 1981’de internete bağlı bilgisayar sayısı sadece 213’ken 1989’da 159000 olmuş ve bu beklenmedik artış 1990’larda “IP kıtlığı” tartışmasını başlatmıştır:

Yıl Bilgisayar Sayısı
1981 213
1982 235
1983 562
1984 1024
1985 1961
1986 5089
1987 28174
1988 56000
1989 159000

Sorun sadece artan bilgisayar sayısından kaynaklanmamaktadır. IPV4’te kullanılan sınıflandırma sistemi de IP adreslerinin adaletsiz dağılımına neden olmuştur. Ülkelerdeki adres sisteminin (il, ilçe, semt, sokak, bina numarası, ev numarası) postaların dağıtımında sağladığı kolaylık dikkate alınarak aynı yöntemin internette de uygulanabileceği ve bir kuruluşun IP adreslerini aynı blok içinde kümeleyerek iletişimin daha verimli düzenlenebileceği hesaplanmıştır.

Bir IP adresini dört bölüm halinde düşünürsek A sınıfı IP adreslerinde adresin birinci kısmı 1 ile 126 arasında bir değer alabilir. Örneğin, bir kuruluşun A sınıfı bir adresi varsa ve değeri 9 ise, kullanabileceği IP adresleri 9.x.y.z gibi değerler alabilecektir. Bir diğer deyişle, A sınıfı adres blokuna sahip olan bir kuruluş yaklaşık 17 milyon (224) potansiyel adrese sahiptir.

B sınıfı adres bloklarında ise IP adresinin iki kısmı kullanılır. IP adresinin ilk bölümü 128 ile 192 arasında bir sayı alabilir. Bir şirketin B sınıfı adresi varsa ve değeri 130.45 ise kullanabileceği IP adreslerinin sayısı (130.45.x.y) 65000’den (216) fazladır.

C sınıfı adres bloklarının ilk bölümü 193 ile 223 arasındadır. Bir kuruluşun C sınıfı adresi varsa ve değeri 200.45.34 (200.45.34.x) ise kullanabileceği IP adreslerinin sayısı sadece 256’dır (28).

İlk gelenler (tahmin edilebileceği gibi ABD’li şirketler, üniversiteler ve askeri birimler) A ve B sınıfı adresleri kapmışlardır. Böylece IP adresleri dünyada asimetrik şekilde dağılmıştır (bkz. https://en.wikipedia.org/wiki/List_of_countries_by_IPv4_address_allocation). Kıtlığın nedenlerinden biri de bu adaletsiz dağılımdır. Fakat dağılım ne kadar adil olursa olsun sınırlı sayıda olan IP adreslerinin sonunda tükenmesi kaçınılmazdır.

1990’lı yıllarda, sorunu aşmak için çeşitli çözümler tartışılmıştır.

IPv6’ya Doğru

Tartışılan çözümlerden bazıları IP adresi kıtlığını aşamasa da acı sonu geciktirecek ve zaman kazandıracak biçimdedir. İlk akla gelen çözüm, IP zengini kuruluşların kullanmadıkları adreslerden feragat etmeleridir. Ama Stanford Üniversitesi gibi istisnalar dışında, IP zenginleri ellerindekini paylaşmaya yanaşmaz. B sınıfı adres blokları yerine birden fazla C sınıfı adres bloku verilmesi ya da CIDR adlı yöntemle (classless interdomain routing – sınıfsız alanlar arası yönlendirme) C sınıfı adres bloklarının birleştirilmesi önerileri vardır.

Ağ geçitleriyle interneti alanlara ayırma ve böylece aynı IP adresinin başka alanlarda kullanımına izin verme önerisi ise internetin halihazırdaki mimarisine aykırı ve istenmeyen bir durumdur. Bilgisayarların birbirleriyle doğrudan bağlantısı yerini parçalanmış bir mimariye bıraktığında ağdaki otoriter, kısıtlayıcı eğilimler güçlenecektir.

IPv4’ün yeni bir protokolle değiştirilmesi önerisi daha akla yatkındır. O güne kadar internetin gelişimine yön veren ve internette kullanılacak protokolleri geliştiren ve standartlaştıran ABD’li bir örgüt olan IETF’dir (Internet Engineering Task Force – Internet Mühendisliği Görev Gücü). IETF’ye katılım, bir ülkeyi ya da şirketi temsilen değil, bireysel temeldedir. Fakat çoğu üye ya bir kurumun ücretli çalışanıdır ya da katılımı bir kurum tarafından finanse edilmektedir. IETF’de anlaşmazlıkların çözümü ve standartların takibi için iyi tanımlanmış prosedürler vardır. IETF’nin resmi bir statüsü olmamasına karşın standartların belirlenme sürecindeki şeffaflık ve katılıma açıklık IETF’nin konumunu meşrulaştırmaktadır. Açıklık, aşağıdan yukarı karar süreçleri ve oy çokluğu yerine topluluğun genel düşüncesine (rough consensus) göre hareket edilmesi IETF’yi standartlaştırma çalışması yapan diğer kurumlardan ayırmaktadır. Ancak tüm katılımcı yaklaşımına rağmen maddi (para, erişim, bilgi, dil vb) eşitsizliklerin potansiyel katılımcılar açısından ciddi bir engel oluşturduğu da göz ardı edilmemelidir.

Yeni IP protokolü tartışmalarında IETF’nin karşısında güçlü bir rakip, ISO (International Organization for Standardization – Uluslararası Standartlar Örgütü) vardır. ISO’nun 162 üyesi vardır. Üyeler, ülkelerin standart belirleme örgütlerinden oluşmaktadır ve üyelik ücretlidir. Örneğin Türkiye ISO’da TSE (Türk Standartları Enstitüsü) tarafından temsil edilmektedir. IETF’den farklı olarak standart çalışmaları kurum içi doküman olarak değerlendirilmekte ve kurum dışına erişime kapatılmaktadır. Standart oluşturma sürecinin sonlanmasından sonra da standartlar ücret karşılığında satılmaktadır.

IP sorunu tartışmaları, teknik bir tartışmanın ötesinde bu iki kültürün çatışması olmuştur. Nitekim yeni IP sürümü önerisi kabul edilen taraf, internetin bundan sonraki gelişimini de belirleyecektir. IETF, IP sorunu hakkındaki çözüm önerilerini değerlendirmek üzere, Allison Mankin ve Scott Bradner yönetiminde bilişim teknolojileri hakkında farklı deneyimlere sahip 15 mühendisi içeren bir çalışma grubu kurar. Farklı deneyim, grubu zenginleştirmektedir. Ama grup üyelerinin çoğunluğu ABD’li büyük yazılım şirketleri ve servis sağlayıcıları ile ilişkilidir. Herhangi bir hükümetin temsilcisi ya da bağımsız bir birey yoktur. Söz konusu şirketler, kabul edilecek protokolü kendi işlerine uyarlayacaklarından yeni protokolle ekonomik olarak da ilgilidirler. Farklı seçeneklerin değerlendirilmesinin ardından geriye üç öneri kalır: SIPP (Simple Internet Protocol Plus), CATNIP (Common Architecture for the Internet), ve TUBA (TCP and UDP with Bigger Addresses). Tüm öneriler, IP adresi kıtlığını aşmaya yönelmiştir ve farklı teknik özellikleri vardır. Ama temel farklılıkları teknik değil, politiktir. Yeni protokolü kimin kontrol edeceği ve IP’nin korunup korunamayacağı sorularına verdikleri yanıtlar ayırt edici özellikleridir. SIPP’in arkasında IETF vardır ve adından da anlaşılabileceği gibi IP’nin bir devamıdır. CATNIP, IP, OSI protokolleri ve Novell ürünlerini içeren tamamen yeni bir protokoldür. TUBA ise IPv4’ü ISO’nun CLNP (Connectionless-mode Network Protocol) adlı protokolü ile değiştirmek istemektedir. CATNIP, yetersiz görülerek elenir. E-Posta listelerinde iki protokol, SIPP ve TUBA, arasında bir rekabet başlar.

SIPP ve TUBA arasındaki yarış gerçekte IETF ve ISO arasındadır. IETF, ISO’nun TUBA konusundaki ısrarını politik olarak değerlendirirken kendi pozisyonunu teknik gerekçelerle ifade eder. Ama e-posta listelerindeki tartışmanın odağı yeni protokolde kimin söz sahibi olacağıdır. ISO, TUBA’nın kontrolünü IETF’ye verse IETF, SIPP ısrarından da vazgeçebilecektir. Ama ISO, kendisinin uluslararası standartlar konusunda yetkili tek örgüt olduğunda ısrar ettiğinden buna imkan yoktur.

Yarışı kazanan IETF olur. Yeni protokol, IPv5i daha önce başka bir yerde kullanıldığından IPv6 olarak adlandırılır. Yarışı IETF’nin kazanmasının üç önemli sonucu vardır. Birincisi, IETF, internet mimarisi üzerindeki konumunu ve internete yaklaşımını pekiştirir. IETF’nin önemli isimlerinden David Clark ISO’ya karşı olan mücadeleyi şöyle ifade etmektedir: “Kralları, başkanları ve oylamayı reddediyoruz. Genel görüşe (rough consensus) ve çalışan koda inanıyoruz.” Diğer bir deyişle, mücadele IETF’nin aşağıdan yukarı oluşturduğu standartlar ile ISO’nun yukarıdan aşağı dikte ettiği standartlar arasında gerçekleşmiştir ve kazanan IETF’nin değerleri olmuştur. İkincisi, TCP/IP ile ISO’nun desteklediği OSI arasındaki yarışta TCP/IP, OSI karşısındaki konumunu daha da güçlendirmiştir. Üçüncüsü, ISO kapalı olmasına rağmen uluslararası bir örgüttür. Batılı hükümetlerin ve şirketlerin ISO’yu destekleme nedenlerinden biri de internetteki ABD hegemonyasını zayıflatabilmektir. Bunda başarılı olamazlar.

Özetle, yeni IP tercihinde farklı çıkarlar ve değerler belirleyici olmuştur. Özellikle açık standartlar konusunda yapılan bu tercih, IPv6’nın geliştirilme aşamasında da belirleyici bir parametre olacaktır. IPv6’nın geliştirme sürecindeki önerilerden biri ağ bağlantısında kullanılan ethernet kartlarındaki özel numaraların (MAC adresi) internet iletişiminde kullanılmasıdır. Bilgisayarın ağa sabit bir numarayla bağlanması ağın teknik olarak daha verimli yönetilebilmesini sağlayacaktır. Eğer sabit bir IP adresi almadıysak her yeni internet bağlantısı, farklı bir IP adresi kullanır. İnternet Servis Sağlayıcı dışında başkaları kullanıcıyı IP adresiyle ilişkilendiremez. Örneğin, internete bağlanırken her seferinde farklı bir IP adresi alındığından bir web sitesi sahibi “X kullanıcısı günde 5 kere benim sitemi ziyaret ediyor.” diyemez. IPv6’ya sabit olan bir bilginin eklenmesi kullanıcıların mahremiyeti için tehdit edici bir durumdur. Tartışmalar ve tepkiler sonucunda bu özellik yeniden düzenlenmiştir. Protokolün, IETF tarafından açık bir biçimde geliştiriliyor olması kamuoyunun gelişmelerden haberdar olmasını ve tepkisini ifade etmesini sağlamıştır. IPv6, ISO içinde geliştirilmiş olsa, çalışmada yer alan mühendislerin mahremiyet kaygısı yoksa kullanıcılar kendileri aleyhinde bir protokolle karşı karşıya kalacaklardır. IETF’de ise mühendislerin mahremiyet kaygısı olmasa bile çalışmalar izlenebildiğinden, protokole son hali verilmeden dışarıdan müdahale etmek mümkündür. Nitekim IETF’deki tartışmalardan haberdar olan aktivistlerin tepkileri, mühendislerin kararını pekiştirmiştir.

Dolayısıyla geliştirilen standartlara dışarıdan müdahale yolları da kritik önemdedir. Bu müdahale, hükümetler, halk ya da aktivist grupları gibi farklı özneler tarafından gerçekleştirilebilir. Hükümetlerin doğrudan müdahalesi bürokrasiyi artırmasının yanında uluslararası ilişkilerde beklenmedik sonuçlar doğurabilmektedir. Bu nedenle internetin yönetiminde aşağıdan yukarı ve hükümetlerin doğrudan müdahil olmadığı yaklaşımlar tercih edilmektedir. Kamu çıkarlarının geliştirilen standartlara yansıtılması önemlidir. Ama halkın standart geliştirme süreçlerine doğrudan katılımının önünde bilgi, zaman, para ve farkındalık gibi engeller vardır. Böyle durumlarda, aktivist grupların çalışmaları önem kazanmaktadır. Aktivist gruplar, standartların tasarım ve iyileştirme çalışmalarına doğrudan katılarak, standardı hazırlayan kurumları kamu yararı konusunda bilgilendiren raporlar hazırlayarak ya da onları dışarıdan izleyerek standardı hazırlayan kurumlarla halk arasında bir köprü olabilirler. Katılımın sınırları standart geliştirme süreçlerinin buna ne kadar izin verdiği ile ilgilidir.

Standart seçim süreci kadar onun benimsenmesi (adoption) de ekonomi ve politikayla yakından ilişkilidir. IPv6’ya geçiş oldukça yavaş ilerlemektedir. Buna rağmen bazı ülkelerin IPv6’yı uygulama konusunda son derece istekli adımlar attığı da görülmektedir. Örneğin Japon Hükümeti, IPv6’ya bir an önce geçerek ABD’den IPv4’ün rövanşını almak istemektedir. IPv6’yı destekleyen cihazları ve servisleri ABD’li şirketlerden önce piyasaya sürme planları yapmaktadır. Ana hedef, IP adreslerinin tükenmesine karşı önlem alınması değil, ekonomik çıkarlar gereği ABD şirketleriyle rekabet olmuştur. Fakat Japon hükümetinin 2001 yılında uygulamaya koyduğu bu strateji başarılı olamamıştır. Benzer hedef ve sonuçsuzluk, Çin, Kore, Hindistan ve Avrupa Komisyonu’nda da yaşanmıştır.

Başarısızlığın birinci nedeni, IPv6’nın IPv4’ün devamı olmasına rağmen farklı dille (protokolle) konuşan iki bilgisayarın doğrudan anlaşamamasıdır. IPv6 kullanan bir bilgisayar ara çözümler olmadan IPv4 kullanan bir sunucuya erişemez. İkincisi, piyasaların ve IP zengini ülkelerin bu yönde bir talebinin olmayışıdır. Çünkü geçiş birçok şirket için ek maliyet anlamına gelmektedir. Kamu yararı ve kendi çıkarları karşı karşıya geldiğinde IPv6’ya geçiş öncelikli görünmemektedir. Üçüncü neden de internetin adem-i merkeziyetçi mimarisidir. Merkezi bir otorite olmadığından IPv6’ya geçiş ağın sakinlerinin kendi tercihi olmaktadır.

2014 yılına kadar internet trafiğinin %99’u hala IPv4 üzerinden gerçekleşmektedir. Ama ilk kez 20 Temmuz 2015’de Google’a erişen IPv6’lı bilgisayarların sayısı %8’i geçmiştir. Ülkelerin IPv6’yı benimseme oranları http://6lab.cisco.com/stats/search.php adresinden izlenebilir.

IPv6’nın daha güvenli olduğunu savunan görüşler henüz istenen etkiyi yapmamıştır. IPv6’nın benimsenmesi için belirgin bir motivasyon ya da yalnız IPv6 üzerinde çalışan bir uygulama olmadıkça IPv4’ün yerini tamamen IPv6’ya devretmesi için daha uzun bir zaman var. Muhtemelen de bu motivasyona ya da uygulamaya IPv6’dan çıkarı olan politik aktörler öncülük edecek.

IPv6, internetin yeniden üretildiği en önemli savaş alanlarından biri. Ama sadece biri…

i https://tr.wikipedia.org/wiki/%C4%B0nternet_Ak%C4%B1%C5%9F_Protokol%C3%BC(IPv5)
ii http://www.google.com/intl/en/ipv6/statistics.html

Kaynaklar

DeNardis, L. (2009). Protocol politics: The globalization of Internet governance. Mit Press.

26 Eylül 2015

Posted In: Açık Standartlar, IPv4, IPv4 Kıtlığı, IPv6, Özgür yazılım

BIND, IPv6 ve DNSSEC

Bir onceki yazida DNSSEC’e giris yapmis ve PowerDNS’i arkada MySQL kullanacak sekilde yapilandirdiktan sonra sundugumuz DNS alanina DNSSEC destegi kazandirmistik. Bu yazida ayni islemin BIND ile nasil yapilabilecegine bakacagiz. Diger yazidan farkli olarak bu yazida temel kayitlarin aciklamalari yerine kayitlarin imzalanmasi, alan transferi (axfr) gibi diger alanlara da deginecegiz. Bu seferki ornegimiz .net TLD’sine sahip olacagindan farkli bir guvenlik zincirine kayit eklememiz gerekmeyecek. (DLV)

Problem su ki kendi DNS alanimizi kendimiz sunsak dahi DS kaydini alan adimizi kaydettigimiz yere vermemiz gerekiyor ki bizi icinde barindiran alana bu kayit iletilebilsin. Boyle olunca da yine destek veren ve destek vermeyen alan adi kaydedicilerden bahsetmek gerekiyor. Ben normalde Hover[1] kullaniyorum fakat ne yazik ki Hover henuz DS kaydi eklenmesine izin vermiyor. Bu isleme olanak taniyan alan adi kaydedicilerin ICANN tarafindan tutulan bir listesine suradan[2] ulasilabilir. Gozuken o ki kala kala yine SOPA destekcisi GoDaddy’ye kaliyoruz.

dnssecenabled.net adresi icin, Ubuntu 12.04 ve CentOS 6.4 uzerinde BIND ile IPv6 ve DNSSEC destegi veren 2 ana isim sunucu (authoritative nameserver) kuracagiz. Bu DNS sunuculardan biri ana (master Ubuntu) digeri ise ikincil(slave CentOS epel ve remi tanimli) olarak gorev yapacak ve ikincil isim sunucu ana isim sunucudan kayitlari alacak. DigitalOcean’da olusturdugum bu sunucular IPv6’e sahip degiller o yuzden HE’nin (Hurricane Electric) tunnelbroker.net hizmetini kullanip IPv6 adreslerini IPv4 uzerinden tunelleyerek ise baslayacagiz.

Tunnelbroker’da hesap actiktan sonra “Create regular tunnel” diyoruz ve IPv4 adresimizi ve kullanmak istedigimiz tunel sunucuyu secip “Create tunnel” tusuna bastigimizda tunnelbroker bizim icin gereke ayarlari
ekrana basiyor. Gelen pencerede “Example Configuration” altinda kullandiginiz isletim sistemini secerseniz hangi dosyada ne degisiklikleri yapmaniz gerektigini size gosterecektir. Ornegin Ubuntu sunucu icin /etc/network/interfaces dosyasina asagidaki satirlari eklememi soyluyor.

auto he-ipv6  
iface he-ipv6 inet6 v4tunnel  
        address 2001:470:1f04:9cb::2
        netmask 64
        endpoint 72.52.104.74
        local 198.199.111.195
        ttl 255
        gateway 2001:470:1f04:9cb::1

CentOS seceneklerde bulunmadigindan onu su sekilde elle ekliyorum. Tabii bu ve yukaridaki degerleri kendinize gore degistirmeyi unutmayin.

ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 198.211.120.12 ttl 255  
ip link set he-ipv6 up  
ip addr add 2001:470:1f14:efa::2/64 dev he-ipv6  
ip route add ::/0 dev he-ipv6  
ip -f inet6 addr  

Ardindan /etc/sysconfig/network dosyasini acip su uc satiri ekliyoruz.

NETWORKING_IPV6=yes  
IPV6_DEFAULTDEV=he-ipv6  
IPV6_DEFAULTGW=2001:470:1f14:efa::1  

Son adimda ise /etc/sysconfig/network-scripts/ifcfg-he diye bir dosya olusturup icine su degerleri yazdiktan sonra network servisini yeniden baslatiyoruz.

DEVICE=he-ipv6  
TYPE=sit  
BOOTPROTO=none  
ONBOOT=yes  
IPV6INIT=yes  
IPV6TUNNELIPV4=216.66.84.46  
IPV6ADDR=2001:470:1f14:efa::2  

Lutfen degerleri kendinize gore degistirmeyi unutmayin. Bu asamayi da tamamlayinca ping6 ve traceroute6 ile IPv6 yapilandirmasinin calisip calismadigini kontrol edebilirsiniz. Geldigimiz kademede elimizdeki bilgiler su sekilde;

ns1.dnssecenabled.net Ubuntu BIND 9.8.1 Master 198.199.111.195 2001:470:1f04:9cb::2

ns2.dnssecenabled.net CentOS BIND 9.8.2 Slave 198.211.120.12 2001:470:1f14:efa::2  

Simdi alan adimizi kaydettigimiz GoDaddy’ye gidip Glue Record’lari (bunun Turkce’ye nasil cevirilmesi gerektigini bilen varsa lutfen benimle iletisime gecsin) ekleyecegiz. Bir DNS terimi olan glue record’un yaptigi is basitce soyle. dnssecenabled.net’in kayitlarini ns1.dnssecenabled.net ve ns2.dnssecenabled.net uzerinden sunmak istiyoruz. www.dnssecenabled.net’e ulasmak istedigimizde once ns1.dnssecenabled.net’e adresine www.dnssecenabled.net’i nerede bulacagimizi sormamiz gerekiyor ama ns1.dnssecenabled.net zaten dnssecenabled.net alaninda. Iste bunun gibi dongusel bir bagimlilik durumunda alan adini kaydettirdigimiz yere bak bunlar isim sunucularin IP adresleri ona gore diyerek verdigimiz kayitlara glue records deniyor.

GoDaddy’de bu kayitlari ekledigimiz alan “domain control panel”‘de sol alttaki “Host Summary” bolumunde bulunuyor. “Add” tusu ile ns1 ve ona ait IPv4 ve IPv6 adreslerini ekledikten sonra sayfayi yenileyip ayni islemi ns2 icin de yapiyoruz. Boylelikle glue records da eklenmis oluyor. Ardindan yine “domain control panel”‘de “Nameserver” bolumundeki “Set Nameservers” tusuna tiklayip dnssecenabled.net alan adimiz icin glue record’lari az once eklemis oldugumuz ve isim sunuculari barindiracagimiz ns1.dnssecenabled.net ve ns2.dnssecenabled.net adreslerini giriyoruz. Artik geriye iki sunucudaki BIND’i yapilandirmak ve DNSSEC isleri bittiginde GoDaddy’ye donup DS kaydini eklemek kaliyor. Isim sunucularin internette yayilmasi zaman alacagindan su asamada az once ekledigimiz kayitlari goremezsek cok endiselenmemekte fayda var. Fakat kontrol icin bir root isim sunucuyu sorgulayabiliriz.

dig @a.gtld-servers.net dnssecenabled.net NS

Eger asagidakine benzer bir cevap aliyorsak, yapilandirmamizda bir sorun yok demektir.

; > DiG 9.9.2-P1 > @a.gtld-servers.net dnssecenabled.net NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:  
 ; EDNS: version: 0, flags:; udp: 4096  
 ;; QUESTION SECTION:  
 ;dnssecenabled.net. IN NS

;; AUTHORITY SECTION:  
 dnssecenabled.net. 172800 IN NS ns1.dnssecenabled.net.  
 dnssecenabled.net. 172800 IN NS ns2.dnssecenabled.net.

;; ADDITIONAL SECTION:  
 ns1.dnssecenabled.net. 172800 IN A 198.199.111.195  
 ns1.dnssecenabled.net. 172800 IN AAAA 2001:470:1f04:9cb::2  
 ns2.dnssecenabled.net. 172800 IN A 198.211.120.12  
 ns2.dnssecenabled.net. 172800 IN AAAA 2001:470:1f14:efa::2

;; Query time: 234 msec  
 ;; SERVER: 192.5.6.30#53(192.5.6.30)  
 ;; WHEN: Thu May 23 16:28:09 2013  
 ;; MSG SIZE rcvd: 170

Gelelim BIND kurulumu ve yapilandirmasina. Yazinin basinda da bahsettigim uzere Ubuntu sunucu master, CentOS sunucu ise slave olarak gorev yapacak. Bu ornekte su kayitlari tanimlayacagim.

www.dnssecenabled.net A 198.199.111.195  
www2.dnssecenabled.net A 198.199.111.195  
www3.dnssecenabled.net A 198.199.111.195  
www4.dnssecenabled.net A 198.211.120.12  
www5.dnssecenabled.net A 198.211.120.12  
mail.dnssecenabled.net A 198.199.111.195

www.dnssecenabled.net AAAA 2001:470:1f04:9cb::2  
www2.dnssecenabled.net AAAA 2001:470:1f04:9cb::2  
www3.dnssecenabled.net AAAA 2001:470:1f04:9cb::2  
www4.dnssecenabled.net AAAA 2001:470:1f14:efa::2  
www5.dnssecenabled.net AAAA 2001:470:1f14:efa::2  
mail.dnssecenabled.net AAAA 2001:470:1f04:9cb::2

dnssecenabled.net MX mail.dnssecenabled.net  
alt1.dnssecenabled.net CNAME www.dnssecenabled.net  
alt2.dnssecenabled.net CNAME www4.dnssecenabled.net  

Ubuntu icin ise basliyoruz.

sudo apt-get install bind9

Kurulum bittikten sonra /etc/bind/named.conf.options dosyamizda IP ve port ayarlarini yapiyoruz. Daha sonra /etc/bind/named.conf.local dosyasini acip su satirlari giriyoruz ki dnssecenabled.net alanini sunucagimiz isim sunucuya soylemis olalim.

zone "dnssecenabled.net"  
    type master;
    file "/etc/bind/db.dnssecenabled.net"
    allow-transfer { 2001:470:1f14:efa::2;
                     198.211.120.12;};
};

Sira geldi db.dnssecenabled.net dosyasini olusturmaya. Benim dosyamin icerigi yukaridaki kayitlar goz onunde bulunduruldugunda su sekilde gozukuyor.

;
; BIND data file for dnssecenabled.net
;
$TTL    300
@    IN  SOA dnssecenabled.net. root.dnssecenabled.net.(
                  3     ; Serial
                300     ; Refresh
                300     ; Retry
                300     ; Expire
                300)    ; Negative Cache TTL

dnssecenabled.net. IN NS ns1.dnssecenabled.net.  
dnssecenabled.net. IN NS ns2.dnssecenabled.net.  
dnssecenabled.net. IN MX 10 mail.dnssecenabled.net.

ns1 IN A 198.199.111.195  
ns2 IN A 198.211.120.12  
ns1 IN AAAA 2001:470:1f04:9cb::2  
ns2 IN AAAA 2001:470:1f14:efa::2

mail IN A 198.199.111.195  
mail IN AAAA 2001:470:1f04:9cb::2

www IN A 198.199.111.195  
www2 IN A 198.199.111.195  
www3 IN A 198.199.111.195  
www4 IN A 198.211.120.12  
www5 IN A 198.211.120.12  
www IN AAAA 2001:470:1f04:9cb::2  
www2 IN AAAA 2001:470:1f04:9cb::2  
www3 IN AAAA 2001:470:1f04:9cb::2  
www4 IN AAAA 2001:470:1f14:efa::2  
www5 IN AAAA 2001:470:1f14:efa::2

alt1 IN CNAME www.dnssecenabled.net.  
alt2 IN CNAME www4.dnssecenabled.net.  

BIND servisini yeniden baslattigimizda master sunucumuz hazir olacak.

service bind9 restart

Isim sunucumuz aslinda dnssecenabled.net'i barindiran sunucu da oldugundan ters DNS kayitlarini yapmayacagim. Bunun icin baska kaynaklara bakilabilir. Zaten cok zor da degil ayarlamasi. Sira geldi CentOS sunucuya BIND kurulup bu ayarladigimiz sunucunun ikincil sunucusu olarak hizmet vermesini saglamaya.

sudo yum install bind bind-utils

Komutuyla gerekli paketleri kuruyorum. bind-utils aslinda gerekli degil fakat test ve hata giderme amacli kurulmasi iyi olacaktir.

CentOS'ta BIND'in kullandigi dizin yapisi biraz daha degisik. Ilk olarak yapmamiz gereken /etc/named.conf dosyasina gecip IP ve port ayarlarini duzenledikten sonra recursion'i kapatmak. named servisini yeniden baslatmadan once su komutu calistiriyoruz. Aslinda servisi ilk yeniden baslattigimizda kendisi bu anahtari olusturmasi gerekiyor fakat islemleri SSH uzerinden yaptigimizdan yeterli entropi olmayinca anahtar uretmesi uzun zaman aliyor, belki de hic uretemiyor hic o kadar uzun beklemedim :). O yuzden elle olusturuyoruz anahtarimizi.

rndc-confgen -a -r /dev/urandom  
service named restart  

Yerelimizden dig @ns2.dnssecenabled.net google.com A ile recursion yapip yapmadigini kontrol edebiliriz CentOS'a az once kurdugumuz isim sunucumuzun. WARNING: recursion requested but not available diyorsa sorun yok demektir. Simdi master sunucunun slave'i olarak ayarlayacagiz. Bunun icin /etc/named.conf dosyasina su satirlari eklememiz yeterli olacaktir.

zone "dnssecenabled.net" IN {  
    type slave;
    file "slaves/db.dnssecenabled.net";
    masters { 2001:470:1f04:9cb::2;
            198.199.111.195; };
};

Yazinin sonuna firsat bulunca bu yazi icin olusturdugum ve duzenledigim tum ayar dosyalarini barindiran tar.bz2 arsivini koyacagim. Ayarlari oradan da kontrol edebilirsiniz.

Evet boylelikle temel DNS kurulumunu bitirmis olduk. Sira geldi DNSSEC islemlerine. Fakat ondan once iki ana sunucu arasindaki veri transferini nasil daha guvenli hale getirebiliriz ona bakalim. TSIG (transaction signatures) iste tam olarak bu ise yariyor. Alan transferi sirasinda iki sunucunun birbirleriyle konustuklarina emin olabilmelerine simetrik sifreleme yontemiyle imkan taniyor. Simetrik sifreleme kullanildigindan her ikincil(slave) sunucu icin yeni bir anahtar olusturulmasi tavsiye ediliyor. Bu sayede bir ikincil sunucunun ele gecirilmesi daha buyuk bir guvenlik tehdidi olusturmamis oluyor. TSIG aslinda DNSSEC'in bir parcasi degil fakat bunca zahmete girdigimize gore hazir elimiz degmisken TSIG islemini de yapmakta bir sakinca yok. Burada onemli bir hususu gozden kacirmamak gerekiyor. TSIG iki sunucu arasindaki veri transferinde veriyi sifrelemiyor, sadece sunucularin gercekten konusmak istedikleri sunucularla konustuklarini anlamalarina olanak taniyor. Eger transfer sirasinda veriyi sifreleme gereksinimi de duyuyorsaniz VPN ya da duruma gore SSH vs. cozumlerine bakmaniz gerekecek. Fakat onlar bu yazinin konusu degil zira blog degil de ansiklopedi yazmak gerekecek o kadar derine inmeye niyetlenirsek :).

TSIG anahtarini uretmek icin dnssec-keygen aracini kullanacagiz. Yine RFC'lere dalarak hangi algoritmalarin desteklendigini bulup cikarabiliriz fakat ben sizin icin isin buyuk kismini yapip, kabul edilebilir duzeyde degerleri olan komutlari buraya yazacagim. HMAC-SHA512 algoritmasi ile 512 bitlik anahtar uzunlugu seciyorum.

dnssec-keygen -r /dev/urandom -a HMAC-SHA512 -b 512 -n HOST ns1-to-ns2.

Sonda nokta var teamulen. Bu komutta degismesi gereken tek kisim sondaki ns1-to-ns2. kismi ki bu da anahtari tanimama yarayan anahtar adini ifade ediyor. Yani anahtari ns1 ile ns2 arasinda kullanacagim. Burada istediginiz isimi secmekte ozgursunuz. Anahtar uretimi -r /dev/urandom kullanmasaydik yine SSH uzerinde oldugumuzdan ve sistem yeterli entropi toplayamadigindan cok uzun zaman alabilirdi fakat etrafindan dolasmis olduk. Bu komutu verdigimiz dizinde .key ve .private ile biten iki dosya olusacak. Ikisinde de ayni anahtari gorecegiz. Simdi bu uretilen anahtari hem ana hem de ikincil sunucuda BIND'i yapilandirdigimiz dosyalara ekleyecegiz. Ekleyecegimiz satirlar suna benziyor. Tekrar dosya yollarini da yazmakta yarar var. Ubuntu icin /etc/bind/named.conf.options CentOS icin /etc/named.conf

key "ns1-to-ns2." {  
    algorithm hmac-sha512;
    secret "Uh8uk5kUR/whQYNGoq50Z80hA1ab706fdPccJq...";
};

server 198.211.120.12 {  
    keys { "ns1-to-ns2." ;} ;
};

Bunu iki sunucuda da IP adreslerini duzelterek yapiyorsunuz. Ardindan asil sunucu olan Ubuntu'da named.conf.local dosyasinda bulunan zone'umuzdaki allow-trasnfer alanina bu paylasilan anahtari girip iki sunucudaki servisleri de yeniden baslatiyoruz. Artik TSIG'in calisip calismadigini kontrol edebiliriz. Bu testi yapmanin en kolay yolu master sunucudaki alan dosyasinda bir degisiklik yapip DNS servisini yeniden baslatmak. Bir CNAME kaydi ekleyip bu islemi gerceklestiriyorum ve ikincil sunucudaki /var/log/messages dosyasina tail ile goz atiyorum.

client 198.199.111.195#39669: received notify for zone 'dnssecenabled.net': TSIG 'ns1-to-ns2'

benzeri bir cikti goruyorsak TSIG istedigimiz gibi yapilandirilmistir demektir. Tabii server tanimlarini IPv6 adreslerimiz icin eklemeyi de unutmayalim ki hem IPv4 hem de IPv6 transferleri TSIG kullansin.

Yazinin baslangicindan yaklasik 1500-2000 kelime sonra nihayet DNSSEC'e gelebildik. Onceki yazida da bahsettigim uzere ZSK ve KSK adi verilen anahtarlara ihtiyacimiz olacak. Bunlari bir suru algoritma kullanarak olusturabiliriz. RSA/SHA-256 (root alaninin da kullandigi algoritma) ile yolumuza devam edecegiz. 2048 bit uzunluk da su an icin gayet yeterli gozukuyor fakat 4096 secmekte de sakinca yok. TSIG'de oldugu gibi bu is icin de dnssec-keygen kullanacagiz.

dnssec-keygen -r /dev/urandom -f KSK -a 8 -b 4096 dnssecenabled.net

-r'i daha once kullanmistik. -f KSK bu anahtar ciftinin key signing key olarak gorev yapacagini soyluyor. -a 8 ise RSA/SHA-256 algoritmasi. -b bit uzunlugu ve son olarak alanimizin adi. .key ve .private uzantili iki dosya olusmus olmasi gerekiyor. ZSK de benzer komutla uretiliyor fakat bu sefer -f KSK'i komuttan cikartiyoruz.

dnssec-keygen -r /dev/urandom -a 8 -b 2048 dnssecenabled.net

Boylelikle 4 adet dosya olusturmus olduk. Izinlerini 640 olarak duzenlemek isteyebilirsiniz. Burada aslinda biraz da guvenlige deginsek iyi olacak. Normalde BIND'i chroot ederek calistirip, bu sunuculari bir firewall'in ya da hic olmadi duzgun iptables kurallarinin arkasina koymak gercekten onemli. Bu kisimi da umarim bir ileride bir iptables yazisiyla anlatmaya calisirim.

KSK ve ZSK'imizi olusturduktan sonra alan adimizi kaydettirdigimiz (bu ornekte GoDaddy) yere DS kaydimizi vermemiz gerekiyor. Urettigimiz KSK'den DS kaydimizi dnssec-dsfromkey komutu ile uretiyoruz.

dnssec-dsfromkey Kdnssecenabled.net.+008+01207

bu komutta Kdnssec... ile baslayan kisimi kendi KSK'iniz tuttugunuz dosya ile degistirmeniz gerekiyor. Dosya sonundaki .key veya .private uzantisini kullanmiyorsunuz. Komut suna benzer bir cikti verecektir.

dnssecenabled.net. IN DS 1207 8 1 597A5CB9F0...  
dnssecenabled.net. IN DS 1207 8 2 9030FF4BF3...  

Iste bu kayitlar alan adimizi kaydettirdigimiz yere verecegimiz DS kayitlaridir. Bir kenara not edelim. Kayitlari imzalamaya geciyoruz.

dnssec-signzone -a -o dnssecenabled.net -N increment -r /dev/urandom db.dnssecenabled.net Kdnssecenabled.net.+008+01207.private Kdnssecenabled.net.+008+19800.private

Aslinda BIND'in 9.9.x surumleri bu islemleri bizim icin yapabiliyor fakat depolarda 9.8.1 oldugunda elle imzalamak durumunda kaldik. Simdi NSEC'ten NSEC3'e cevirmek icin ne yapacagimiza bakalim. Ayni komuta -H 10 -3 d00dbaaf verdigimizde bizim icin NSEC'ten NSEC3'e cevirecek. -3'ten sonraki kisim hexadecimal olarak yazabileceginiz herhangi bir sey olabilir. Ben deadbeef'ten esinlenip bunu sectim. Simdi eski alani yedekleyip imzalanmasi(db.dnssecenabled.net.signed) uzerine yazalim ve servisi yeniden baslatalim. Su anda slave'e imzalanmis alanin gitmis olmasi gerekiyor. DS kayitlarini eklemenin vakti geldi. GoDaddy'nin kontrol paneline gidiyoruz ve "Add DS Records" altindan gerekli kayitlari ekliyoruz. Bu kayitlar DNS sisteminde yayildiginda dig'e +dnssec parametresi vererek alanimizi sorgulayanlar ad(authenticated data) bayragini donen cevap icerisinde gormeye baslayacaklardir. Iste DNSSEC bu kadar basit.

Alanimiza yeni bir kayit ekledigimizde imzalama ve servisi yeniden baslatma isini su an icin yeniden yapmamiz gerekiyor. Dolayisiyla .signed'i normal dosyanin uzerine yazmadan once yedegini almis olmakta fayda var. Yoksa her seferinde butun kayitlari yazmak iskence olacaktir. BIND 9.9.x surumleri itibariyle bu islemler otomatik yapilabiliyor olmasina ragmen ne Ubuntu 12.04 ne de CentOS 6.4 depolarinda o surum bulunmadigindan islemleri elle yaptik. Fakat BIND surumu yukseldikce isimiz biraz daha kolaylasacak.

Asagida yeni olusturdugumuz alan adinin DNSSEC testine ait goruntuyu paylasiyorum.

dnssecenabled.net-2013-05-23-15-11-05

Gordugunuz gibi bir onceki yazida baktigimiz test.name.tr gibi siyah kalin oklar bulunmuyor ve butun DNS kayitlari DNSSEC ile imzalanmis durumda.

DNSSEC ile ilgili bu ikinci yazida yine anahtar degisimi (key rollover), SSHFP kayitlari ve DANE(TLSA) konusunda yazmaya firsat olmadi fakat onlari da bir sonraki yazida ele alip DNSSEC defterini bir sureligine kapatmayi planliyorum. Ardindan "iptables: anneye anlatir gibi" projesine baslayacagim :).

Sunuculari iki hafta kadar kurcalamak isteyen olursa diye acik birakacagim. Eger olur da girip bir bakmak isterseniz haber etmeniz yeterli.

[1] www.hover.com

[2] http://www.icann.org/en/news/in-focus/dnssec/deployment

24 Mayıs 2013

Posted In: Authoritative, BIND, CentOS, dns, DNS Sunucu, dnssec, Gezegen, IPv6, Master, Slave, Sunucu, Tunnelbroker, ubuntu

WP Twitter Auto Publish Powered By : XYZScripts.com