การตรวจสอบความถูกต้องของเอนทิตีที่มีชื่อตาม DNS ( DANE ) เป็น โปรโตคอล ความปลอดภัยอินเทอร์เน็ตที่อนุญาตให้ใบรับรองดิจิทัลX.509 ซึ่งใช้กันทั่วไปสำหรับความปลอดภัยของเลเยอร์การขนส่ง (TLS) สามารถผูกกับชื่อโดเมนโดยใช้ส่วนขยายความปลอดภัยของระบบชื่อโดเมน ( DNSSEC ) ^{[ 1 ]}

RFC  6698เสนอให้ใช้ DANE เป็นวิธีการตรวจสอบความถูกต้องของเอนทิตีไคลเอ็นต์และเซิร์ฟเวอร์ TLS โดยไม่ต้องใช้หน่วยงานออกใบรับรอง ( CA ) และได้รับการปรับปรุงด้วยคำแนะนำด้านการปฏิบัติงานและการใช้งานในRFC 7671การใช้งาน DANE เฉพาะแอปพลิเคชันนั้นกำหนดไว้ในRFC 7672สำหรับ SMTP และRFC 7673 สำหรับ การ ใช้ DANE กับระเบียนบริการ (SRV)   

การเข้ารหัส TLS/SSL ในปัจจุบันใช้ใบรับรองที่ออกโดยหน่วยงานออกใบรับรอง (CA) เป็นหลัก ในช่วงไม่กี่ปีที่ผ่านมา ผู้ให้บริการ CA จำนวนมากประสบปัญหาการละเมิดความปลอดภัย อย่างร้ายแรง ทำให้มีการออกใบรับรองสำหรับโดเมนที่มีชื่อเสียงให้กับผู้ที่ไม่ใช่เจ้าของโดเมนเหล่านั้น การไว้วางใจ CA จำนวนมากอาจเป็นปัญหา เพราะ CA ที่ถูกละเมิดอาจออกใบรับรองสำหรับชื่อโดเมนใดก็ได้ DANE ช่วยให้ผู้ดูแลระบบของชื่อโดเมนสามารถรับรองคีย์ที่ใช้ในไคลเอนต์หรือเซิร์ฟเวอร์ TLS ของโดเมนนั้นได้โดยการจัดเก็บไว้ในระบบชื่อโดเมน (DNS) DANE ต้องการให้ระเบียน DNS ได้รับการลงนามด้วย DNSSEC เพื่อให้โมเดลความปลอดภัยทำงานได้

นอกจากนี้ DANE ยังอนุญาตให้เจ้าของโดเมนระบุว่า CA ใดได้รับอนุญาตให้ออกใบรับรองสำหรับทรัพยากรเฉพาะ ซึ่งช่วยแก้ปัญหาที่ว่า CA ใดก็ได้สามารถออกใบรับรองสำหรับโดเมนใดก็ได้

DANE แก้ปัญหาที่คล้ายคลึงกับปัญหาต่อไปนี้:

ความโปร่งใสของใบรับรอง

เพื่อให้มั่นใจว่าหน่วยงานออกใบรับรองที่ไม่ถูกต้องจะไม่สามารถออกใบรับรองโดยไม่ได้รับอนุญาตจากเจ้าของโดเมนโดยไม่ถูกตรวจจับได้

การอนุญาตหน่วยงานรับรอง DNS

การจำกัดว่าหน่วยงานออกใบรับรองใดบ้างที่สามารถออกใบรับรองสำหรับโดเมนที่กำหนด

จนกระทั่งเมื่อไม่นานมานี้ ยังไม่มีมาตรฐานที่ใช้กันอย่างแพร่หลายสำหรับการถ่ายโอนอีเมลที่เข้ารหัส^{[ 2 ]}การส่งอีเมลไม่คำนึงถึงความปลอดภัย ไม่มี รูปแบบ URI ใด ที่จะกำหนด SMTP ที่ปลอดภัยได้^{[ 3 ]}ด้วยเหตุนี้ อีเมลส่วนใหญ่ที่ส่งผ่าน TLS จึงใช้การเข้ารหัสแบบฉวยโอกาสเท่านั้น^{[ 4 ]}เนื่องจาก DNSSEC ให้การปฏิเสธการมีอยู่แบบตรวจสอบความถูกต้อง (อนุญาตให้ตัวแก้ไขตรวจสอบว่าชื่อโดเมนบางชื่อไม่มีอยู่จริง) DANE จึงช่วยให้การเปลี่ยนไปใช้ SMTP ที่เข้ารหัสและตรวจสอบแล้วเป็นไปอย่างค่อยเป็นค่อยไปโดยไม่ต้องใช้กลไกภายนอกอื่นใด ตามที่อธิบายไว้ในRFC 7672บันทึก DANE ระบุว่าผู้ส่งต้องใช้ TLS ^{[ 3 ]} 

นอกจากนี้RFC 8162 ^{ยังมีอยู่สำหรับการประยุกต์ใช้ DANE กับ S/MIME [ 5} ] และ RFC ^{7929 กำหนด}มาตรฐานการผูกสำหรับOpenPGP [ ^{6 ]}  

• Google Chromeไม่รองรับ DANE เนื่องจาก Google Chrome ต้องการกำจัดการใช้ RSA 1024 บิตภายในเบราว์เซอร์^{[ 7 ]} (ก่อนหน้านี้ DNSSEC ใช้รูทที่ลงนามด้วย RSA 1024 บิต^{[ 8 ]}และโซนจำนวนมากยังคงลงนามด้วย RSA 1024 บิต แม้ว่าค่าเริ่มต้นในปัจจุบันจะเป็น ECDSA 256 บิต^{[ 9 ]}ก็ตาม) ตามที่ Adam Langley กล่าวไว้ โค้ดนี้ถูกเขียนขึ้น^{[ 10 ]}และถึงแม้ว่าจะไม่มีอยู่ใน Chrome ในปัจจุบัน^{[ 11 ]}แต่ก็ยังคงมีให้ใช้งานในรูปแบบส่วนเสริม^{[ 12 ]}
• Mozilla Firefoxไม่รองรับ DANE จากการตอบสนองในตั๋วเกี่ยวกับหัวข้อ ("เราไม่มีแผนที่จะนำคุณสมบัตินี้ไปใช้") ปัจจุบันนักพัฒนาของ Mozilla มองว่า DNSSEC และ DANE อยู่นอกขอบเขตของ Firefox ^{[ 13 ] [ 14 ]}การสนับสนุน Addon เคยมีให้ใช้งานจนถึง Firefox 56 (อัปเดตครั้งล่าสุดในปี 2016 ^{[ 15 ]} ) แต่ปัจจุบันไม่มีแล้ว ไม่สามารถนำไปใช้กับ API ส่วนขยาย Firefox รุ่นใหม่ที่เข้มงวดกว่าได้อีกต่อไป^{[ 16 ]}
• GNU Privacy Guardอนุญาตให้ดึงคีย์ผ่าน OpenPGP DANE (--auto-key-locate) ตัวเลือกใหม่ --export-options export-dane (เวอร์ชัน 2.1.14) ^{[ 17 ]}
• Cheogram Android อนุญาตให้ตรวจสอบผ่าน DANE และแสดงสถานะว่ามีการใช้ DANE หรือไม่^{[ 18 ]}
• FairEmail สำหรับ Android อนุญาตให้ตรวจสอบ DANE สำหรับเซิร์ฟเวอร์ SMTP และ POP/IMAP ^{[ 19 ]}

• คำต่อท้าย^{[ 20 ]}
• PowerMTA ^{[ 21 ]}
• เอ็กซิม^{[ 22 ]}
• ฉันทลักษณ์^{[ 23 ]}

• โพสเตโอ^{[ 24 ]}
• ทูทาโนตะ^{[ 25 ]}
• กล่องจดหมาย^{[ 26 ]}

• OpenSSL ^{[ 27 ]}
• GnuTLS ^{[ 28 ]}

ระเบียนทรัพยากร TLSA (TLSA RR) สำหรับบริการจะอยู่ที่ชื่อ DNS ซึ่งระบุว่าควรใช้ข้อจำกัดของใบรับรองสำหรับบริการที่พอร์ต TCP หรือ UDP ที่กำหนด อย่างน้อยหนึ่งในระเบียนทรัพยากร TLSA ต้องมีเส้นทางการตรวจสอบ (path) สำหรับใบรับรองที่บริการเสนอให้ ณ ที่อยู่ที่ระบุ

ไม่ใช่ทุกโปรโตคอลที่จะจัดการการจับคู่ชื่อทั่วไป (Common Name) ในลักษณะเดียวกัน HTTP กำหนดให้ชื่อทั่วไปในใบรับรอง X.509 ที่ผู้ให้บริการให้มาต้องตรงกัน ไม่ว่า TLSA จะยืนยันความถูกต้องหรือไม่ก็ตาม ส่วน SMTP ไม่จำเป็นต้องให้ชื่อทั่วไปตรงกัน หากค่าการใช้งานของใบรับรองเป็น 3 (DANE-EE) แต่หากไม่ใช่กรณีดังกล่าว จะต้องมีการจับคู่ชื่อทั่วไป จึงเป็นสิ่งสำคัญที่จะต้องตรวจสอบว่ามีคำแนะนำเฉพาะสำหรับโปรโตคอลที่ใช้งานอยู่หรือไม่

ตัว RR เองมีข้อมูล 4 ช่อง ซึ่งอธิบายถึงระดับการตรวจสอบความถูกต้องที่เจ้าของโดเมนให้ไว้

• ช่องการใช้งานใบรับรอง
• ช่องตัวเลือก
• ช่องประเภทการจับคู่
• ข้อมูลการเชื่อมโยงใบรับรอง

เช่น_25._tcp.somehost.example.com.TLSA3110123456789ABCDEF

ช่องแรกถัดจากข้อความ TLSA ในระเบียน DNS จะระบุวิธีการตรวจสอบความถูกต้องของใบรับรอง

• ค่า 0 หมายถึงสิ่งที่เรียกกันทั่วไปว่าข้อจำกัด CA (และ PKIX-TA) ใบรับรองที่ให้ไว้เมื่อสร้าง TLS ต้องออกโดย root-CA ที่ระบุไว้หรือ CA ระดับกลางตัวใดตัวหนึ่ง โดยมีเส้นทางการรับรองที่ถูกต้องไปยัง root-CA ที่แอปพลิเคชันที่ทำการตรวจสอบเชื่อถืออยู่แล้ว บันทึกอาจชี้ไปยัง CA ระดับกลางเท่านั้น ในกรณีนี้ ใบรับรองสำหรับบริการนี้ต้องมาจาก CA นี้ แต่ห่วงโซ่ทั้งหมดไปยัง root-CA ที่เชื่อถือได้จะต้องยังคงถูกต้อง^{[ a ]}
• ค่า 1 หมายถึงสิ่งที่เรียกกันทั่วไปว่าข้อจำกัดใบรับรองบริการ (และ PKIX-EE) ใบรับรองที่ใช้ต้องตรงกับระเบียน TLSA และต้องผ่านการตรวจสอบความถูกต้องของเส้นทางการรับรอง PKIX ไปยัง CA รากที่เชื่อถือได้ ด้วย
• ค่า 2 หมายถึงสิ่งที่เรียกกันทั่วไปว่าTrust Anchor Assertion (และ DANE-TA) ระเบียน TLSA จะตรงกับใบรับรองของ Root CA หรือ Intermediate CA ตัวใดตัวหนึ่งของใบรับรองที่บริการใช้งานอยู่ เส้นทางการรับรองต้องถูกต้องจนถึงใบรับรองที่ตรงกัน แต่ไม่จำเป็นต้องมี Trusted Root CA
• ค่า 3 หมายถึงสิ่งที่เรียกกันทั่วไปว่าใบรับรองที่ออกโดยโดเมน (และ DANE-EE) ระเบียน TLSA จะตรงกับใบรับรองที่ใช้ ใบรับรองที่ใช้ไม่จำเป็นต้องได้รับการลงนามโดยบุคคลอื่น สิ่งนี้มีประโยชน์สำหรับใบรับรองที่ลงนามด้วยตนเอง แต่ยังรวมถึงกรณีที่ผู้ตรวจสอบไม่มีรายการใบรับรองรากที่เชื่อถือได้ด้วย

เมื่อเชื่อมต่อกับบริการและได้รับใบรับรองแล้ว ช่องตัวเลือกจะระบุว่าควรตรวจสอบส่วนใดของใบรับรองบ้าง

• ค่า 0 หมายถึงการเลือกใบรับรองทั้งหมดเพื่อทำการจับคู่
• ค่า 1 หมายถึงการเลือกเฉพาะคีย์สาธารณะสำหรับการจับคู่ใบรับรอง การจับคู่คีย์สาธารณะมักจะเพียงพอ เนื่องจากคีย์สาธารณะมักจะมีเอกลักษณ์เฉพาะตัว

• ค่าประเภท 0 หมายความว่าข้อมูลทั้งหมดที่เลือกนั้นมีอยู่ในข้อมูลการเชื่อมโยงใบรับรองแล้ว
• ค่าประเภท 1 หมายถึงการสร้างค่าแฮช SHA-256 ให้กับข้อมูลที่เลือก
• ประเภทที่ 2 หมายถึงการสร้างแฮช SHA-512 ของข้อมูลที่เลือก

ข้อมูลจริงที่จะต้องนำมาเปรียบเทียบโดยพิจารณาจากค่าที่ตั้งไว้ในช่องอื่นๆ นี่คือ "สตริงข้อความ" ยาวๆ ที่ประกอบด้วยข้อมูลเลขฐานสิบหก

บันทึก TLSA สำหรับwww.ietf.org ระบุ ให้ตรวจสอบค่าแฮช SHA-256 ของคีย์สาธารณะของใบรับรองที่ให้มา โดยไม่สนใจ CA ใดๆ

_443._tcp.www.ietf.org TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

บริการไปรษณีย์ของพวกเขามีใบรับรองและ TLSA ที่เหมือนกันทุกประการ

ietf.org MX 0 mail.ietf.org _25._tcp.mail.ietf.org TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

สุดท้ายนี้ ตัวอย่างต่อไปนี้ทำเช่นเดียวกับตัวอย่างอื่นๆ แต่ทำการคำนวณแฮชกับใบรับรองทั้งหมด

_25._tcp.mail.alice.example. TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9

• RFC  6394กรณีการใช้งานและข้อกำหนดสำหรับการตรวจสอบสิทธิ์แบบ DNS ของเอนทิตีที่มีชื่อ (DANE)
• RFC  6698โปรโตคอลความปลอดภัยระดับชั้นการขนส่ง (TLS) สำหรับการตรวจสอบความถูกต้องของเอนทิตีที่มีชื่อโดยใช้ DNS (DANE): TLSA
• RFC  7218การเพิ่มคำย่อเพื่อลดความซับซ้อนของการสนทนาเกี่ยวกับการตรวจสอบความถูกต้องของเอนทิตีที่มีชื่อโดยใช้ DNS (DANE)
• RFC  7671โปรโตคอลการตรวจสอบความถูกต้องของเอนทิตีที่มีชื่อโดยใช้ DNS (DANE): การอัปเดตและคำแนะนำในการปฏิบัติงาน
• RFC  7672การรักษาความปลอดภัย SMTP ผ่านการตรวจสอบสิทธิ์แบบ DNS เชิงโอกาสของเอนทิตีที่มีชื่อ (DANE) การรักษาความปลอดภัยระดับการขนส่ง (TLS)
• RFC  7673การใช้ระเบียน TLSA ของการตรวจสอบความถูกต้องของเอนทิตีที่มีชื่อโดยใช้ DNS (DANE) ร่วมกับระเบียน SRV
• RFC  7929การตรวจสอบความถูกต้องของเอนทิตีที่มีชื่อโดยใช้ DNS (DANE) สำหรับการเชื่อมต่อ OpenPGP
• RFC  8162การใช้ Secure DNS เพื่อเชื่อมโยงใบรับรองกับชื่อโดเมนสำหรับ S/MIME
• ร่าง: การเข้ารหัสแบบฉวยโอกาสด้วยความหมาย DANE และ IPsec: IPSECA ^{[ 29 ]}

• การอนุญาตหน่วยงานรับรอง DNS
• บันทึก SSHFP
• SMTP MTA Strict Transport Security (MTA-STS)

• DNSSEC ไม่จำเป็น - ขัดแย้งกับ DNSSEC
• สำหรับ DNSSEC - ข้อโต้แย้งต่อประเด็นต่างๆ ใน ​​"ข้อโต้แย้งต่อ DNSSEC"
• รายชื่อสถานที่สอบ DANE
• เครื่องมือออนไลน์สำหรับตรวจสอบเซิร์ฟเวอร์อีเมลว่ารองรับ DNSSEC และ DANE หรือไม่
• ภาพประกอบการรณรงค์ของ DANEพร้อมลิงก์ไปยังวิธีการและเครื่องมือต่างๆ