EDNS İstemci Alt Ağı (ECS) Yönergeleri

Giriş

RFC 7871: DNS Sorgularında İstemci Alt Ağı: Google Açık DNS gibi yinelenen çözümleyicilerin yetkili DNS alan adı sunucularına kısmi istemci IP adresi bilgileri göndermelerini sağlayan bir mekanizma tanımlar. İçerik Yayınlama Ağları (CDN'ler) ve gecikmeye duyarlı hizmetler, genel DNS çözümleyiciler aracılığıyla gelen ad aramalarına yanıt verirken coğrafi olarak doğru yanıtlar vermek için bunu kullanır.

RFC, yetkili alan adı sunucularının uygulaması gereken ECS özelliklerini açıklar ancak uygulamalar her zaman bu şartlara uymaz. RFC'nin ele almadığı ECS operasyonel ve dağıtım sorunları da vardır. Bunlar, yetkili alan adı sunucularındaki ECS desteğini otomatik olarak algılayan Google Public DNS gibi çözümleyiciler ve OpenDNS gibi ECS beyaz listeye eklenmesi gereken çözümleyiciler için sorunlara yol açabilir.

Bu yönergeler, yetkili DNS uygulayıcılarının ve operatörlerin ECS için sorunlara neden olabilecek birçok yaygın hatadan kaçınmasına yardımcı olmayı amaçlamaktadır.

Terimlerin Tanımları

ECS işlemlerini tanımlamak için aşağıdaki terimleri kullanırız:

  • Bir ad sunucusu ECS sorgularına eşleşen ECS seçenekleri olan ECS yanıtlarına yanıt veriyorsa ECS'yi uygular (veya destekler). (ECS seçeneklerinin her zaman genel /0 kapsam ön eki uzunluğu olsa bile).

  • Alt bölge, ECS-etkinleştirilir sıfır olmayan bir kaynak ön ekiyle gönderilen alan adı sunucularına ECS sorguları sıfır olmayan bir kapsamda ECS yanıtları alıyorsa.

Yetkili Alan Adı Sunucuları için Kurallar

  1. ECS'nin etkin olduğu bir bölge için tüm yetkili alan adı sunucuları, alt bölge için ECS'yi etkinleştirmelidir.

    • Tek bir alan adı sunucusu ECS'yi uygulamaz veya alt bölge için etkinleştirmez olsa bile hızlıca önbelleğe alınan verilerin kaynağı haline gelir. Verdiği yanıtlar global kapsama sahip olduğundan (TTL'lerinin süresi dolana kadar) aynı adla ilgili tüm sorgulara yanıt olarak kullanılır (istemci alt ağına bakılmaksızın). ECS'yi uygulayan ve bu istemciyi etkinleştiren sunuculardan gelen yanıtlar, yalnızca belirli kapsamdaki istemcilerden gelen sorgular için kullanılır. Bu nedenle, global kapsam yanıtlarından çok daha az kullanılmaları mümkündür.

  2. ECS'yi uygulayan yetkili alan adı sunucuları, IP veya NS ana makine adından sunulan tüm alt bölgeler için ECS sorgularına ECS yanıtı gönderir. ECS'nin etkin olmadığı bölgelerde bile bu durum geçerlidir.

    • Google Açık DNS, ECS desteğini alan adı ana makine adı veya DNS alt bölgesi yerine IP adresine göre otomatik olarak algılar. Bunun nedeni, adres sayısının alan adı sunucusu ana makine adlarının sayısından küçük ve DNS bölgelerinin sayısından çok daha küçük olmasıdır. Yetkili bir alan adı sunucusu, ECS sorgularına ECS yanıtları her zaman göndermiyorsa Google Ortak DNS, ECS sorgularını göndermeyi durdurabilir.

  3. ECS'yi uygulayan yetkili alan adı sunucuları, negatif ve yönlendirme yanıtları dahil olmak üzere ECS yanıtları ile tüm ECS sorgularına yanıt vermelidir.

    • ECS desteğinin otomatik algılanmasıyla ilgili sorunlar burada da geçerlidir.

    • Olumsuz yanıtlar (NXDOMAIN ve NODATA) Önbelleğe Alınır3 durumunda, daha iyi önbelleğe alma ve RFC 7871 ile uyumluluk için genel /0 kapsamını kullanır.

    • NXDOMAIN ve NODATA (boş yanıt bölümü olan HATA DEĞİL) yanı sıra, ECS sorgularına (özellikle SERVFAIL ve REFUSE) ait diğer hata yanıtları, global /0 kapsamına sahip eşleşen bir ECS seçeneği içermelidir.

      • Yetkili bir alan adı sunucusu, DoS saldırısından yükü kaldırmaya çalışırsa ECS verileri olmadan bir SERVFAIL döndürebilir; bunu yapmak sürekli olarak Google Public DNS'nin ECS ile sorgu göndermeyi durdurmasına neden olur (bu, gönderdikleri meşru sorguların sayısını azaltabilir ancak rastgele alt alan adı saldırı sorgularını etkilemez). DoS saldırısı sırasında meşru sorgu yükünün azaltılması, meşru sorguların başarı oranını artırabilir veya artırmayabilir (ancak yanıtlar tüm istemciler için önbellekten sunulabilir).

        Daha etkili bir yükleme modu, Google Herkese Açık DNS'nin ECS sorguları göndermeye devam etmesi için global/0 değerine sahip tüm yanıtlar göndermektir. Bu, Google Genel DNS'nin saldırıyı durdurduktan sonra coğrafi olarak yerleştirilmiş yanıtları çok daha erken döndürmesine olanak tanır. Bunun nedeni, ECS desteğini tekrar algılamak olmamasıdır. Yalnızca global kapsam yanıtı TTL'lerinin süresi dolduktan sonra yeniden sorgulama yapmak gerekir.

    • Yönlendirme (yetki) yanıtlarının da eşleşen ECS verileri olmalıdır ve 4, global bir /0 kapsamı kullanmalıdır. Yetki yanıtlarının hiçbir zaman adresleri ECS verilerinde görünen müşterilere yönlendirilmediğini unutmayın. Bu nedenle, coğrafi olarak konumlandırılmış NS, A veya AAAA kayıtları, ECS verileri yerine çözümleyicinin IP adresi tarafından seçilmelidir.

  4. ECS'yi uygulayan yetkili alan adı sunucuları, ECS seçeneğiyle alınan tüm sorgu türlerine verilen yanıtlarda eşleşen bir ECS seçeneği içermelidir. IPv4 adresi (A) sorgularına ECS verileriyle yanıt vermek için yeterli değildir. A, AAAA, PTR, MX veya diğer sorgu türlerine verilen yanıtların eşleşen ECS verilerine sahip olması gerekir. Aksi halde, cevaplar muhtemelen sahte bir yanıt olarak kesilebilir ve Google Açık DNS, ECS verileriyle sorgu göndermeyi durdurabilir.

    Özellikle SOA, NS ve DS sorgularına ECS yanıtları, daha iyi önbelleğe alma ve tutarlı bir yetkilendirme görünümü için her zaman genel /0 kapsamını kullanmalıdır (alan adı sunucusu ana makine adları için A/AAAA sorgularına coğrafi olarak yerleştirilmiş yanıtlar kullanılabilir). ECS verilerine göre değişmeyen herhangi bir sorgu türüne (ör.TXT, PTR) verilen yanıtlar, kaynak ön eki uzunluğuna eşit bir kapsam kullanmamalıdır. Daha iyi önbelleğe alma ve sorgu yükünü azaltmak için global /0 kapsamı kullanmalıdır.

  5. ECS özellikli CNAME yanıtları döndüren yetkili alan adı sunucuları yalnızca ZORUNLU5 zincirde yalnızca ilk CNAME'i içermelidir. CNAME zincirinin son hedefi, aynı kapsam ön eki uzunluğuna kadar ECS etkin olmalıdır. ECS spesifikasyonundaki belirsizlik nedeniyle, bazı yinelenen çözümleyiciler (özellikle Sınırsız6), CNAME olmayan nihai alan kapsamında bir yanıt döndürebilir (ECS etkin değilse /0).

  6. ECS verileri, yalnızca IPv4 alan adı sunucuları için bile IPv6 adresleri içerebilir (ve yalnızca IPv6 alan adı sunucuları nadir olsa da).

    • Alan adı sunucularının geçerli ECS seçenek verileriyle yanıt vermesi gerekir (/0 kapsam kullanılabilir, ancak kaynak adresi ve ön ek uzunluğu eşleşmelidir).

    • Bir alt bölge için ECS, IPv4 ve IPv6 adresleri için ayrı olarak etkinleştirilebilir.

  7. ECS özellikli yanıtlar döndüren yetkili alan adı sunucuları, cevaplarında kapsam öneklerinin KAPILMAMASI7 gerekir. Çakışan kapsam ön eklerine örnek olarak şunlar verilebilir:

    • Kaynak ön eki 198.18.0.0/15 olan sorgu: 198.0.0.0/8 kapsam ön eki içeren A yanıtı

    • Kaynak ön eki 198.51.100/24 olan sorgu: 198.51.0.0/16 kapsam önekiyle B yanıtı

    Bir istemci, ECS özellikli bir yinelemeyi yukarıdaki sırayla sorgularsa önbelleğe alınan yanıtın kapsamı ikinci sorgunun ön ek kapsamını içerdiği için her iki sorgu da A yanıtını alabilir. İstemci sorguları ters sırada yapılsa ve her iki sorgu da yetkili alan adı sunucularına yönlendirilse bile, önbelleğe alınan yanıtların geçerliliği farklı zamanlarda sona erebilir. Çakışan önek için yinelenen çözümleyiciye gönderilecek sonraki sorgular 198.51.100/24, A veya B yanıtını alabilir.

  8. ECS desteğini ad sunucularında ilk kez uygularken bu ECS etkin bölgelerin sunulduğu alan adı sunucuları için yeni IP adreslerini kullanın.

    • ECS'yi uygulayan ancak küresel kapsam sonuçları döndüren yetkili alan adı sunucuları, bir alt bölge için ECS etkinleştirilen yanıtları döndürmeye başladığında Google Public DNS, önceki genel kapsam yanıtlarının TTL'leri dolduktan sonra sorgulara coğrafi konumlu yanıtlar döndürmeye başlar.

    • ECS desteğinin Google Açık DNS tarafından otomatik olarak algılanması, ECS desteğinin otomatik olarak algılanmadığı durumlarda IP adresi (veya alan adı sunucusu ana makine adı) için ECS sorgularını çok nadiren dener (zaman aşımı, FORMERR, BADVERS gönderme veya ECS olmayan yanıtlar gönderme). Bu IP adreslerindeki (veya NS ana makine adlarının) yeni ECS uygulamaları çok yavaş algılanır veya hiç algılanmaz.

  9. Ağ bağlantılarının güvenilir olduğundan ve yanıt hız sınırının, alan adı sunucularının sorguları bırakmaması için yeterince yüksek olduğundan (veya daha iyisi, eşleşen bir ECS seçeneği olmayan hatalarla yanıt verdiğinden) emin olun.

    • ECS sorgularında yanıt oranı sınırını uygulayan alan adı sunucuları için en iyi yanıt, yalnızca eşleşen bir soru bölümü ve eşleşen ECS seçeneği içeren kesme (TC) işareti ayarlanmış NODATA'dır.

  10. Tüm sorgulara zamanında yanıt göndermek (ideal olarak 1 saniye içinde).

    • ECS sorguları için online Geo-IP arama hizmetleri kullanmak, DNS sorgusunun ve online Geo-IP hizmetinin kümülatif gecikmesi bir saniye içinde olmayacağından güvenilir bir şekilde çalışmaz. ECS desteğinin Google Açık DNS'in otomatik olarak algılanması, gecikmiş yanıtların zayıf veya eksik ECS desteği olduğunun göstergesi olarak değerlendirilir ve gelecekteki sorguların ECS ile gönderilmesi olasılığını azaltır. Yeterli sayıda yanıt gecikirse ECS sorgusu göndermeyi durdurur.

RFC 7871 referansları ve diğer dipnotlar

1 https://tools.ietf.org/html/rfc7871#page-12

FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.

2 https://tools.ietf.org/html/rfc7871#section-7.2.1

An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer.

3 https://tools.ietf.org/html/rfc7871#section-7.4

It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.

4 https://tools.ietf.org/html/rfc7871#section-7.4

The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.

5 https://tools.ietf.org/html/rfc7871#page-12

For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway.

6 https://unbound.net/pipermail/unbound-users/2015-May/003875.html

Bir CNAME zincirinde nihai alanın kapsamını kullanmak, tüm cihazlarda aynı alt ağda bulunan ve aynı yanıtı alan yerel bir sap veya yönlendirme çözücü olarak dağıtıldığı için Sınırsız'da zararsızdır.

7 https://tools.ietf.org/html/rfc7871#page-13

Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.

When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:

  1. Deaggregate the shorter prefix response into multiple longer prefix responses, or

  2. Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.

...

When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.