หลักเกณฑ์ของ EDNS Client Subnet (ECS)

บทนำ

RFC 7871 – ไคลเอ็นต์ไคลเอ็นต์ในการค้นหา DNS – จะกําหนดกลไกสําหรับรีโซลเวอร์ที่เกิดซ้ํา เช่น DNS สาธารณะของ Google เพื่อส่งข้อมูลที่อยู่ IP ของไคลเอ็นต์บางส่วนไปยังเซิร์ฟเวอร์เนมเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ เครือข่ายนําส่งข้อมูล (CDN) และบริการที่มีความละเอียดอ่อนต่อเวลาในการตอบสนองจะใช้การดําเนินการนี้เพื่อแสดงการตอบสนองตามตําแหน่งทางภูมิศาสตร์ที่ถูกต้องเมื่อตอบสนองการค้นหาชื่อที่มาจากรีโซลเวอร์ DNS สาธารณะ

RFC จะอธิบายถึงฟีเจอร์ ECS ที่เนมเซิร์ฟเวอร์ที่เชื่อถือได้ต้องนํามาใช้ แต่ผู้ที่นําไปปฏิบัติจะไม่ปฏิบัติตามข้อกําหนดเหล่านั้นเสมอไป นอกจากนี้ ยังมีปัญหาด้านการดําเนินการและการทําให้ใช้งานได้ของ ECS ที่ RFC ไม่ช่วยแก้ไขปัญหาซึ่งอาจก่อให้เกิดปัญหา เช่น รีโซลเวอร์สาธารณะของ Google ที่ตรวจจับการรองรับ ECS ในเนมเซิร์ฟเวอร์ที่เชื่อถือได้โดยอัตโนมัติ และรีโซลเวอร์ที่ต้องมีการอนุญาต ECS ในรายการที่อนุญาตพิเศษเช่น OpenDNS

หลักเกณฑ์เหล่านี้มีไว้เพื่อช่วยติดตั้งใช้งานและโอเปอเรเตอร์ DNS ที่เชื่อถือได้ เพื่อหลีกเลี่ยงข้อผิดพลาดทั่วไปหลายอย่างที่อาจก่อให้เกิดปัญหาต่อ ECS

คําจํากัดความของข้อกําหนด

เราใช้คําอธิบายเกี่ยวกับการดําเนินการ ECS ดังต่อไปนี้

  • เนมเซิร์ฟเวอร์จะนําไปใช้ (หรือรองรับ) ECS หากตอบกลับคําขอ ECS ที่มีการตอบกลับ ECS ที่มีตัวเลือก ECS ที่ตรงกัน (แม้ว่าตัวเลือก ECS จะมีความยาวของคํานําหน้าทั่วโลกที่ /0 เสมอ)

  • โซน จะทํางานเป็น ECS-เปิดใช้ ถ้าการค้นหา ECS ไปยังเซิร์ฟเวอร์ชื่อที่ส่งมาด้วย ค่านําหน้าแหล่งที่มาซึ่งไม่เป็นศูนย์ จะได้รับการตอบกลับ ECS ด้วยขอบเขตที่ไม่ใช่ 0

หลักเกณฑ์สําหรับเนมเซิร์ฟเวอร์ที่เชื่อถือได้

  1. เนมเซิร์ฟเวอร์ที่เชื่อถือได้ทั้งหมดสําหรับโซนที่เปิดใช้ ECS ต้องเปิดใช้ ECS สําหรับโซนนั้น

    • แม้ว่าจะมีเพียงเนมเซิร์ฟเวอร์เดียวที่ไม่ได้ใช้ ECS หรือเปิดใช้โซนนั้นสําหรับโซน แต่เซิร์ฟเวอร์จะกลายเป็นแหล่งที่มาของข้อมูลที่แคชไว้ส่วนใหญ่ได้อย่างรวดเร็ว เนื่องจากคําตอบมีขอบเขตรวมที่ใช้ (จนกว่า TTL จะหมดอายุ) เป็นการตอบสนองต่อคําค้นหาทั้งหมดที่มีชื่อเดียวกัน (โดยไม่คํานึงถึงซับเน็ตของไคลเอ็นต์) คําตอบจากเซิร์ฟเวอร์ที่ทําการใช้งาน ECS และเปิดใช้สําหรับคําค้นหาจากลูกค้าในขอบเขตที่เจาะจงเท่านั้น การตอบกลับจึงมีแนวโน้มที่จะใช้น้อยกว่าการตอบสนองในขอบเขตทั้งหมดมาก

  2. เนมเซิร์ฟเวอร์ที่เชื่อถือได้ที่ใช้งาน ECS MUST2 จะส่งการตอบกลับ ECS ไปยังการค้นหา ECS สําหรับโซน all ที่แสดงจากที่อยู่ IP หรือชื่อโฮสต์ NS รวมถึงสําหรับโซนที่ไม่ได้เปิดใช้ ECS

    • Google Public DNS จะตรวจหาการสนับสนุน ECS ตามที่อยู่ IP โดยอัตโนมัติ แทนที่จะระบุชื่อโฮสต์หรือโซน DNS ของเซิร์ฟเวอร์ เนื่องจากจํานวนที่อยู่น้อยกว่าจํานวนชื่อโฮสต์ของเนมเซิร์ฟเวอร์และมีจํานวนน้อยกว่าโซน DNS มาก หากเนมเซิร์ฟเวอร์ที่เชื่อถือได้ไม่ได้ส่งคําตอบ ECS ไปยังคําค้นหา ECS ทุกครั้ง (แม้ว่าจะเป็นโซนที่ไม่ได้เปิดใช้ ECS ก็ตาม) DNS สาธารณะของ Google อาจหยุดส่งคําค้นหา ECS

  3. เนมเซิร์ฟเวอร์ที่เชื่อถือได้ที่ใช้งาน ECS ต้องตอบสนองต่อคําค้นหา ECS ทั้งหมดที่มีการตอบสนอง ECS ซึ่งรวมถึงการตอบกลับในเชิงลบและการอ้างอิง

    • ปัญหาเดียวกันเกี่ยวกับการตรวจหาการรองรับ ECS โดยอัตโนมัติจะมีผลด้วยเช่นกัน

    • การตอบสนองเชิงลบ (NXDOMAIN และ NODATA) ควร3 ใช้ขอบเขต /0 ทั่วโลกเพื่อแคชและความเข้ากันได้กับ RFC 7871 ได้ดียิ่งขึ้น

    • นอกจาก NXDOMAIN และ NODATA (NOERROR ที่มีส่วนคําตอบที่ว่างเปล่า) การตอบสนองต่อข้อผิดพลาด ECS อื่นๆ (โดยเฉพาะ SERVFAIL และ REFused) ควรรวมตัวเลือก ECS ที่ตรงกันซึ่งมีขอบเขตส่วนกลาง /0

      • หากเนมเซิร์ฟเวอร์ที่เชื่อถือได้พยายามโหลดจากการโจมตี DoS ระบบจะแสดงเซิร์ฟเวอร์ SERVFAIL ที่ไม่มีข้อมูล ECS เนื่องจากการดําเนินการนี้จะทําให้ DNS สาธารณะของ Google หยุดส่งคําค้นหาด้วย ECS ซ้ํา (ซึ่งอาจลดจํานวนคําค้นหาที่ถูกต้องซึ่งส่ง แต่จะไม่มีผลต่อการค้นหาการบุกรุกโดเมนย่อยแบบสุ่ม) การลดปริมาณคําค้นหาที่ถูกต้องในระหว่างการโจมตี DoS อาจทําให้หรือไม่สามารถปรับปรุงอัตราความสําเร็จของคําค้นหาที่ถูกต้อง (แม้ว่าการตอบสนองอาจแสดงจากแคชสําหรับไคลเอ็นต์ทั้งหมด)

        วิธีลดภาระงานที่มีประสิทธิภาพมากกว่าคือการส่งการตอบกลับทั้งหมดที่มีขอบเขตส่วนกลาง /0 เพื่อให้ DNS สาธารณะของ Google ยังคงส่งคําค้นหา ECS ต่อไป วิธีนี้ช่วยให้ DNS สาธารณะของ Google แสดงการตอบสนองตามตําแหน่งทางภูมิศาสตร์ได้มากหลังจากการโจมตีหยุดลงเพราะไม่จําเป็นต้องตรวจหาการรองรับ ECS อีกครั้ง เมื่อค้นหาอีกครั้งเมื่อ TTL ของขอบเขตส่วนกลางหมดอายุ

    • การตอบกลับการอ้างอิง (การมอบสิทธิ์) ต้องมีข้อมูล ECS ที่ตรงกันด้วย และควร4ใช้ขอบเขต /0 ส่วนกลาง โปรดทราบว่า อีเมลที่ได้รับมอบสิทธิ์จะไม่ส่งต่อไปยังไคลเอ็นต์ที่มีที่อยู่ ปรากฏในข้อมูล ECS ดังนั้น ที่อยู่ IP ของไคลเอ็นต์ sreolver's ควรเลือกตําแหน่งทางภูมิศาสตร์ ไม่ใช่ข้อมูล ECS

  4. เนมเซิร์ฟเวอร์ที่เชื่อถือได้ที่ใช้งาน ECS ต้องมีตัวเลือก ECS ที่ตรงกันในการตอบกลับคําถามทั้งหมดที่ได้รับพร้อมกับตัวเลือก ECS การค้นหาที่อยู่ IPv4 (A) ที่มีข้อมูล ECS ยังดีไม่พอ การตอบสนองต่อ A, AAAA, PTR, MX หรือประเภทคําค้นหาอื่นๆ ต้องมีข้อมูล ECS หรือรีโซลเวอร์ที่ตรงกันซึ่งอาจเป็นการตอบสนองที่อาจปลอมแปลงได้ และ DNS สาธารณะของ Google อาจหยุดส่งการค้นหาที่มีข้อมูล ECS

    โดยเฉพาะอย่างยิ่งการตอบกลับ ECS สําหรับคําค้นหา SOA, NS และ DS ควรใช้ขอบเขตส่วนกลาง /0 เสมอเพื่อให้การแคชมีประสิทธิภาพมากขึ้นและมีมุมมองที่สอดคล้องกันในการมอบสิทธิ์ (การตอบสนองตามตําแหน่งทางภูมิศาสตร์ของการค้นหา A/AAAA สําหรับชื่อโฮสต์เนมเซิร์ฟเวอร์จะไม่มีปัญหา) การตอบกลับทุกประเภท (เช่น TXT, PTR ฯลฯ) ซึ่งไม่มีการเปลี่ยนแปลงตามข้อมูล ECS ไม่ควรใช้ขอบเขตที่เท่ากับความยาวคํานําหน้าแหล่งที่มา แต่ควรใช้ขอบเขตส่วนกลาง /0 สําหรับการแคชที่ดีขึ้นและการโหลดการค้นหาที่ลดลง

  5. เนมเซิร์ฟเวอร์ที่เชื่อถือได้ซึ่งส่งคําตอบจาก CNAME ที่เปิดใช้ ECS ควร5 รวมเฉพาะ CNAME แรกในเชน และเป้าหมายสุดท้ายของเชน CNAME ควรเปิดใช้งาน ECS ที่มีความยาวของขอบเขตเท่ากัน เนื่องจากความกํากวมในข้อมูลจําเพาะของ ECS รีโซลเวอร์ที่เกิดซ้ําบางรายการ ((โดยเฉพาะยกเลิกการเชื่อมโยง6) อาจแสดงผลกลับมาในขอบเขตของโดเมนที่ไม่ใช่ CNAME สุดท้าย (/0 หากไม่ได้เปิดใช้ ECS)

  6. ข้อมูล ECS อาจมีที่อยู่ IPv6 แม้ว่าจะเป็นเนมเซิร์ฟเวอร์ IPv4 เท่านั้น (และในทางกลับกัน แม้ว่าจะมีเพียงเนมเซิร์ฟเวอร์ IPv6 ก็ตาม)

    • เนมเซิร์ฟเวอร์จะต้องตอบกลับด้วยข้อมูลตัวเลือก ECS ที่ถูกต้อง (ขอบเขต 0 คือใช้ได้ แต่ที่อยู่ต้นทางและความยาวของคํานําหน้าต้องตรงกัน)

    • คุณจะเปิดใช้ ECS สําหรับโซนแยกต่างหากสําหรับที่อยู่ IPv4 และ IPv6 ได้

  7. เนมเซิร์ฟเวอร์ที่เชื่อถือได้ซึ่งแสดงผลคําตอบที่เปิดใช้ ECS ต้องไม่ใช่7 ที่นําหน้าขอบเขตคําตอบซ้อนทับกัน ตัวอย่างของคํานําหน้าขอบเขตที่ทับซ้อนกัน ได้แก่

    • การค้นหาที่มีคํานําหน้าแหล่งที่มา 198.18.0.0/15: การตอบกลับ A ที่มีขอบเขตขอบเขต 198.0.0.0/8

    • การค้นหาที่มีคํานําหน้าแหล่งที่มา 198.51.100/24: การตอบกลับ B ที่มีคํานําหน้าขอบเขต 198.51.0.0/16

    หากลูกค้าค้นหารีโซลเวอร์ที่เรียกใช้ ECS ซ้ําตามลําดับข้างต้น คําค้นหาทั้ง 2 รายการอาจได้รับการตอบกลับ ก เนื่องจากขอบเขตของการตอบกลับที่แคชไว้ ก มีขอบเขตคํานําหน้าของคําค้นหาที่ 2 แม้ว่าคําค้นหาของไคลเอ็นต์จะจัดเรียงตามลําดับตรงกันข้าม และคําค้นหาทั้ง 2 รายการจะส่งต่อไปยังเนมเซิร์ฟเวอร์ที่เชื่อถือได้ แต่การตอบสนองที่แคชไว้อาจหมดอายุในเวลาที่ต่างกัน โดยการค้นหาในภายหลังไปยังรีโซลเวอร์ที่เกิดซ้ําในคํานําหน้าที่ทับซ้อนกัน 198.51.100/24 อาจได้รับการตอบกลับ A หรือ B

  8. เมื่อใช้การรองรับ ECS เป็นครั้งแรกในเนมเซิร์ฟเวอร์ ให้ใช้ที่อยู่ IP ใหม่สําหรับเนมเซิร์ฟเวอร์ที่แสดงโซนที่เปิดใช้ ECS

    • เมื่อเนมเซิร์ฟเวอร์ที่เชื่อถือได้ซึ่งใช้งาน ECS แต่แสดงผลลัพธ์ขอบเขตส่วนกลางจะเป็นการเริ่มแสดงคําตอบที่เปิดใช้ ECS ในโซน

    • การตรวจหา DNS สาธารณะโดยอัตโนมัติของ Google โดยใช้การสนับสนุน ECS แทบจะไม่พยายามค้นหา ECS สําหรับที่อยู่ IP (หรือชื่อโฮสต์ของเซิร์ฟเวอร์ชื่อ) เมื่อระบบตรวจพบการไม่รองรับ ECS โดยอัตโนมัติ (หมดเวลา ส่งคืน FORMERR, BADVERS หรือส่งการตอบกลับที่ไม่ใช่ ECS) การติดตั้งใช้งาน ECS ใหม่ในที่อยู่ IP เหล่านั้น (หรือชื่อโฮสต์ NS) จะตรวจพบโดยอัตโนมัติอย่างช้าๆ หรือไม่พบเลย

  9. ตรวจสอบว่าการเชื่อมต่อเครือข่ายเชื่อถือได้และมีการจํากัดอัตราการตอบกลับให้สูงเพียงพอที่เนมเซิร์ฟเวอร์จะไม่ทิ้งการค้นหา (หรือแย่กว่านั้น ให้ตอบกลับโดยมีข้อผิดพลาดที่ไม่มีตัวเลือก ECS ที่ตรงกัน)

    • สําหรับเนมเซิร์ฟเวอร์ที่ใช้อัตราการตอบกลับที่จํากัดในการค้นหา ECS คําตอบที่ดีที่สุดคือ NODATA ที่มีการตั้งค่าแฟล็กการตัด (TC) โดยมีเฉพาะส่วนคําถามที่ตรงกันและตัวเลือก ECS ที่ตรงกัน

  10. ส่งคําตอบให้กับทุกคําถามอย่างทันท่วงที (หากเป็นไปได้ภายใน 1 วินาที)

    • การใช้บริการค้นหา Geo-IP ออนไลน์สําหรับคําค้นหา ECS จะทํางานได้อย่างไม่เสถียร เนื่องจากเวลาในการตอบสนองสะสมของคําขอ DNS และบริการ Geo-IP ออนไลน์ไม่น่าจะอยู่ภายใน 1 วินาที การตรวจพบการสนับสนุน ECS ของ DNS สาธารณะโดยอัตโนมัติของ Google จะถือว่าการตอบสนองล่าช้าซึ่งแสดงถึงการสนับสนุน ECS ที่ไม่สมบูรณ์หรือไม่ครบถ้วน และลดโอกาสที่จะมีการส่งคําค้นหาในอนาคตด้วย ECS หากการตอบสนองล่าช้าพอ ก็จะหยุดส่งคําค้นหา ECS

การอ้างอิง RFC 7871 และเชิงอรรถอื่นๆ

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-พฤษภาคม/003875.html

การใช้ขอบเขตของโดเมนสุดท้ายในห่วงโซ่ CNAME ไม่เป็นอันตรายใน Unbound เนื่องจากโดยปกติจะทําให้ใช้งานเป็นต้นขั้วในเครื่องหรือโปรแกรมแปลต่อ ซึ่งใช้ไคลเอ็นต์ทั้งหมดในซับเน็ตเดียวกันและจะได้รับการตอบกลับเดียวกัน

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.