SVCB
/HTTPS
ขณะนี้ระเบียน DNS กำลังทำงานอยู่ (ดู https://github.com/MikeBishop/dns-alt-svc/blob/master/draft-ietf-dnsop-svcb-https.md สำหรับเอกสารการทำงานหรือ https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.txt ที่ IETF) แต่ยังไม่สิ้นสุด
สถานการณ์ที่ไม่ชัดเจนที่แปลกประหลาดในขณะนี้คือ IANA ได้ลงทะเบียนรหัสสำหรับรหัสเหล่านั้นแล้ว (ซึ่งเป็นสาเหตุที่รหัสเหล่านี้สามารถเกิดขึ้นได้อยู่แล้วในธรรมชาติและทำงานร่วมกันได้ด้วยวิธีการจัดการประเภทบันทึกทั่วไปของ RFC 3597) แม้ว่า RFC จะยังไม่พร้อมก็ตาม /เผยแพร่แล้ว และผู้ขายบางราย (Apple และ Cloudflare ดูด้านล่าง) กล่าวว่าพวกเขาติดตั้งและใช้งานได้แล้ว
ดู https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ ตัวอย่างเช่นสำหรับ Cloudflare ซึ่งจะให้ตัวอย่างว่าทำไมจึงใช้ ฉันแนะนำให้อ่านก่อนมาตรฐานทางเทคนิค เว้นแต่ว่าคุณเชี่ยวชาญ DNS และ TLS อยู่แล้ว
แนวคิดดังกล่าวเกิดขึ้นหลังจาก/ระหว่าง TLS 1.3 (และไคลเอ็นต์ที่เข้ารหัส Hello/ความต้องการ SNI ที่เข้ารหัส) และ HTTP/3 และ QUICเอกสารนี้มีจุดประสงค์เพื่อแก้ปัญหาหลายอย่างจริง ๆ ซึ่งปัญหาส่วนหนึ่งได้รับการแก้ไขแล้ว เอส.อาร์.วี
บันทึกว่าไม่มีเบราว์เซอร์ใดตัดสินใจนำมาใช้ในตอนนั้น
จากบทคัดย่อ:
SVCB
บันทึกอนุญาตให้ให้บริการจากหลายทางเลือก
จุดสิ้นสุด แต่ละจุดมีพารามิเตอร์ที่เกี่ยวข้อง (เช่น การขนส่ง
การกำหนดค่าโปรโตคอลและคีย์สำหรับเข้ารหัส TLS ClientHello)
พวกเขายังเปิดใช้งานนามแฝงของโดเมนเอเพ็กซ์ซึ่งไม่สามารถทำได้
CNAME HTTPS RR เป็นรูปแบบของ SVCB สำหรับ HTTPS และ HTTP
ต้นกำเนิด โดยแจ้งข้อมูลเพิ่มเติมให้กับลูกค้าทราบก่อนได้ค่ะ
พยายามสร้างการเชื่อมต่อ บันทึกเหล่านี้มีศักยภาพ
ให้ประโยชน์ทั้งในด้านประสิทธิภาพและความเป็นส่วนตัว
ตอนนี้ในประเด็นเฉพาะของคุณ:
ผม. type65 RR สามารถแทนที่ CNAME ได้หรือไม่ โดยเฉพาะอย่างยิ่งในกรณีที่เราไม่สามารถมี CNAME ที่ระดับบนสุดของโซน
ใช่, SVCB/HTTPS
ได้รับการออกแบบมาเพื่อช่วยในการจัดการกรณี "CNAME at apex"
ดู "10.3.2. Apex aliasing" ในแบบร่าง:
พิจารณาโซนที่ใช้นามแฝง CNAME:
$ORIGIN นามแฝง.example. ; โซนที่ใช้บริการโฮสติ้ง
; โดเมนย่อยที่ใช้แทนกลุ่มเซิร์ฟเวอร์ประสิทธิภาพสูง
www 7200 IN CNAME pool.svc.example.
; โดเมนเอเพ็กซ์บน IP แบบคงที่ เนื่องจากไม่อนุญาตให้ใช้ CNAME ที่เอเพ็กซ์
@ 300 ใน 192.0.2.1
ใน AAAA 2001:db8::1
ด้วย HTTPS RRs เจ้าของ aliased.example สามารถตั้งชื่อแทนเอเพ็กซ์ได้
เพิ่มบันทึกเพิ่มเติมหนึ่งรายการ:
@ 7200 ใน HTTPS 0 pool.svc.example
ii. ฉันจะสั่งให้เบราว์เซอร์ถามหา type65 แทน A หรือ AAAA สำหรับโดเมนของฉันได้อย่างไร เพื่อให้ฉันมี abc.com โดยตรงผ่าน CDN
คุณจะต้องรอให้เบราว์เซอร์รองรับ :-)
เข้าไปดูกระทู้ได้ที่ https://mailarchive.ietf.org/arch/msg/dnsop/eeP4H9fli712JPWnEMvDg1sLEfg/ ; มีการสนับสนุนใน iOS 14 และ Safari ในรูปแบบทดลองบางอย่าง
บทความบล็อกที่ Cloudflare ให้ลิงก์สองลิงก์ในตอนท้ายเพื่อติดตามสถานะของฟีเจอร์ใน Firefox และ Chrome:
โดยวิธีการที่ยินดีอย่าทำให้สับสนไม่ดี ใช้ ตัวอย่าง.คอม
ในเอกสาร ดู RFC2606
สาม. การผูกเวอร์ชันใดที่รองรับ SVCB (ประเภท 65) RR
ยังไม่มีการจัดส่ง
นี้ติดตามได้ใน https://gitlab.isc.org/isc-projects/bind9/-/issues/1132
มันถูกรวมเข้าด้วยกัน 6 วันที่ผ่านมา :-)
ดังนั้นเวอร์ชันถัดไปอาจจัดส่งตามสิ่งที่อยู่ในตั๋วสำหรับเหตุการณ์สำคัญ:
"กันยายน 2021 (9.11.36, 9.11.36-S1, 9.16.21, 9.16.21-S1, 9.17.18)"
อย่างไรก็ตาม ด้วย RFC 3597 คุณควรจะสามารถป้อนบันทึกโดยใช้ไวยากรณ์ทั่วไป TYPE65
ในไฟล์โซนและการผูกควรให้บริการ คุณสูญเสียการตรวจสอบไวยากรณ์และคุณสมบัติอื่น ๆ อย่างเห็นได้ชัด (คุณสามารถดูได้ที่ https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5332/diffs เพื่อดูว่า "การเพิ่มการสนับสนุน SVCB/HTTPS เพื่อผูก" นั้นหมายถึงอะไร ดู §4 ในร่าง IETF เพื่อดูว่าตัวแก้ไขที่มีสิทธิ์และตัวแก้ไขแบบเรียกซ้ำสนับสนุนเฉพาะใดบ้างที่จำเป็นสำหรับบันทึกเหล่านี้ จึงควรยอมรับการเปลี่ยนแปลงหากมีเหตุผลที่ดี เช่น ซอฟต์แวร์ยังไม่มีการสนับสนุนเต็มรูปแบบที่แท้จริง) แต่อย่างน้อยคุณก็สามารถให้บริการบันทึกได้
แต่อย่าลืมว่าไม่ได้มีแค่การผูกมัด:
คุณจึงสามารถทดลองการสนับสนุนเต็มรูปแบบกับซอฟต์แวร์อื่นๆ ได้