หากฉันสอบถามเนมเซิร์ฟเวอร์ ระเบียนนั้นจะมีสิทธิ์เนื่องจากดูเหมือนว่าคำตอบจะไม่ได้รับการตรวจสอบความถูกต้องของ DNSSEC:
$ ขุด cloudflare.com @ns3.cloudflare.com
; <<>> DiG 9.16.22-Debian <<>> cloudflare.com @ns3.cloudflare.com
;; ตัวเลือกส่วนกลาง: +cmd
;; ได้รับคำตอบ:
;; ->>HEADER<<- opcode: QUERY, สถานะ: NOERROR, id: 28361
;; ธง: qr aa rd; คำถาม: 1, คำตอบ: 2, ผู้มีอำนาจ: 0, เพิ่มเติม: 1
;; คำเตือน: มีการร้องขอการเรียกซ้ำ แต่ไม่สามารถใช้ได้
;; เลือก PSEUDOSECTION:
; EDNS: เวอร์ชัน: 0, แฟล็ก:; UDP: 1232
;; ส่วนคำถาม:
;cloudflare.com ใน
;; ส่วนคำตอบ:
cloudflare.คอม 300 ใน 104.16.133.229
cloudflare.คอม 300 ใน 104.16.132.229
;; เวลาสืบค้น: 3 มิลลิวินาที
;; เซิร์ฟเวอร์: 162.159.0.33#53(162.159.0.33)
;; เมื่อ: วันเสาร์ที่ 20 พฤศจิกายน 15:29:00 CET 2021
;; ขนาดผงชูรส rcvd: 75
ไม่มีการส่งคืนค่าสถานะ "โฆษณา" ดังนั้นคำตอบจึงไม่ผ่านการตรวจสอบ DNSSEC หากฉันถามเซิร์ฟเวอร์ที่ไม่ได้รับอนุญาตด้วยข้อความค้นหาเดียวกัน แฟล็ก "โฆษณา" จะถูกส่งกลับ:
$ ขุด cloudflare.com @ 1.1.1.1
; <<>> DiG 9.16.22-Debian <<>> cloudflare.com @1.1.1.1
;; ตัวเลือกส่วนกลาง: +cmd
;; ได้รับคำตอบ:
;; ->>HEADER<<- opcode: QUERY, สถานะ: NOERROR, id: 23361
;; ธง: qr rd ra ad; คำถาม: 1, คำตอบ: 2, ผู้มีอำนาจ: 0, เพิ่มเติม: 1
;; เลือก PSEUDOSECTION:
; EDNS: เวอร์ชัน: 0, แฟล็ก:; UDP: 1232
;; ส่วนคำถาม:
;cloudflare.com ใน
;; ส่วนคำตอบ:
cloudflare.คอม 145 ใน 104.16.132.229
cloudflare.คอม 145 ใน 104.16.133.229
;; เวลาสืบค้น: 3 มิลลิวินาที
;; เซิร์ฟเวอร์: 1.1.1.1#53(1.1.1.1)
;; เมื่อ: วันเสาร์ที่ 20 พฤศจิกายน 15:35:35 CET 2021
;; ขนาดผงชูรส rcvd: 75
คุณช่วยบอกฉัน:
ISC ผูก 9 ในการกำหนดค่า? ยังไง?(หากพฤติกรรมนี้เกิดขึ้นโดยเจตนา เราไม่ควรกำหนดค่าเนมเซิร์ฟเวอร์ให้ใช้ซอฟต์แวร์เนมเซิร์ฟเวอร์ของตัวเองในการแก้ไข เนื่องจากซอฟต์แวร์ไคลเอนต์บางตัวจะสร้างความแตกต่างไม่ว่าคำตอบจะผ่านการตรวจสอบหรือไม่: ฉันสงสัยว่าทำไม SSHFP บันทึกไม่ทำงาน ssh -o VerifyHostKeyDNS <โฮสต์> จากเนมเซิร์ฟเวอร์นั่นเอง)
เหตุใดเซิร์ฟเวอร์ชื่อที่เชื่อถือได้จึงไม่ตรวจสอบความถูกต้องของ DNSSEC ผลลัพธ์ของตนเอง
เนื่องจากไม่สามารถเป็นเนมเซิร์ฟเวอร์แบบเรียกซ้ำได้ซึ่งจะไม่ดี
ในการตรวจสอบ DNSSEC อย่างสมบูรณ์ คุณต้องเริ่มจากรูทและผ่านลิงก์ทั้งหมดของ ดีเอส/DNSKEY บันทึก และตัวแก้ไขที่มีสิทธิ์ที่คุณปรึกษาไม่ได้มีสิทธิ์ในทั้งหมดนั้น เป็นเพียงส่วนหนึ่งของลิงค์ด้านล่าง
ดูตัวอย่างส่วนที่ 6 ของ RFC 4033 "การพิจารณาตัวแก้ไข":
ตัวแก้ไขที่ตระหนักถึงความปลอดภัยจะต้องสามารถดำเนินการเข้ารหัสได้ ฟังก์ชันที่จำเป็นในการตรวจสอบลายเซ็นดิจิทัลโดยใช้อย่างน้อย อัลกอริทึมที่จำเป็นในการนำไปใช้งาน ตัวแก้ไขที่คำนึงถึงความปลอดภัยจะต้อง ยังสามารถสร้างห่วงโซ่การรับรองความถูกต้องจากใหม่ โซนที่เรียนรู้กลับไปยังคีย์การรับรองความถูกต้องตามที่อธิบายไว้ข้างต้น นี้ กระบวนการอาจต้องการการสืบค้นเพิ่มเติมสำหรับโซน DNS ระดับกลางเพื่อรับระเบียน DNSKEY, DS และ RRSIG ที่จำเป็น ตระหนักถึงความปลอดภัย ตัวแก้ไขควรกำหนดค่าด้วย trust anchor อย่างน้อยหนึ่งตัวเป็น จุดเริ่มต้นที่จะพยายามสร้างการรับรองความถูกต้อง ห่วงโซ่.
และ RFC 4035 ส่วน §3.2.3 "บิตโฆษณา" ภายใต้ "เซิร์ฟเวอร์ชื่อเรียกซ้ำ":
ฝั่งเนมเซิร์ฟเวอร์ของเนมเซิร์ฟเวอร์แบบเรียกซ้ำที่คำนึงถึงความปลอดภัยจะต้อง อย่าตั้งค่าบิตโฆษณาในการตอบสนอง เว้นแต่เซิร์ฟเวอร์ชื่อจะพิจารณาทั้งหมด RRsets ในส่วนคำตอบและสิทธิ์ของการตอบกลับเป็น แท้. ฝั่งเนมเซิร์ฟเวอร์ควรตั้งค่าบิต AD ก็ต่อเมื่อ ด้านตัวแก้ไขจะพิจารณาชุด RR ทั้งหมดในส่วนคำตอบและชุดอื่นๆ RRs การตอบสนองเชิงลบที่เกี่ยวข้องในส่วนผู้มีอำนาจที่จะเป็น แท้. ด้านตัวแก้ปัญหาต้องปฏิบัติตามขั้นตอนที่อธิบายไว้ใน ส่วนที่ 5 เพื่อพิจารณาว่า RR ที่เป็นปัญหานั้นเป็นของจริงหรือไม่ อย่างไรก็ตาม สำหรับความเข้ากันได้แบบย้อนหลัง อาจตั้งค่าเซิร์ฟเวอร์ชื่อเรียกซ้ำ บิต AD เมื่อการตอบกลับรวม CNAME RR ที่ไม่ได้ลงนาม หาก CNAME เหล่านั้น RRs ได้รับการพิสูจน์แล้วว่าสังเคราะห์มาจาก DNAME แท้ๆ RR ที่รวมอยู่ในการตอบสนองตามการสังเคราะห์ กฎที่อธิบายไว้ใน [RFC2672]
ส่วน:
มันสร้างความแตกต่างไม่ว่าคำตอบจะได้รับการตรวจสอบหรือไม่
แน่นอนว่านั่นคือจุดประสงค์ทั้งหมดของ DNSSEC แต่ลูกค้าปลายทางไม่ได้ปรึกษากับเนมเซิร์ฟเวอร์ที่เชื่อถือได้โดยตรงระหว่างการดำเนินการตามปกติ พวกเขาใช้เนมเซิร์ฟเวอร์แบบเรียกซ้ำ ซึ่งจะวนซ้ำเนมเซิร์ฟเวอร์ที่เชื่อถือได้หลายตัวเพื่อรับการตอบกลับสุดท้าย และสามารถตรวจสอบ DNSSEC ได้หากกำหนดค่าให้ทำเช่นนั้น
ฉันสงสัยว่าเหตุใดบันทึก SSHFP จึงไม่ทำงานเมื่อทำ ssh -o VerifyHostKeyDNS จากเนมเซิร์ฟเวอร์เอง
ไม่ว่าคุณจะมีปัญหาอะไรที่นี่ไม่เกี่ยวข้องกับสิ่งที่กล่าวมาข้างต้น จุ๊ๆ ควรใช้ตัวแก้ไขระดับ OS ใดก็ตามที่ได้รับการกำหนดค่าเพื่อรับข้อมูล
ดู https://github.com/openssh/libopenssh/blob/05dfdd5f54d9a1bae5544141a7ee65baa3313ecd/ssh/dns.c#L191 ซึ่งอยู่ภายใน ตรวจสอบ_host_key_dns การทำงาน:
ผลลัพธ์ = getrrsetbyname (ชื่อโฮสต์ DNS_RDATACLASS_IN
DNS_RDATATYPE_SSHFP, 0, &ลายนิ้วมือ);
ถ้า (ผลลัพธ์) {
verbose("ข้อผิดพลาดในการค้นหา DNS: %s", dns_result_totext(ผลลัพธ์));
กลับ -1;
}
ถ้า (ลายนิ้วมือ->rri_flags & RRSET_VALIDATED) {
*ตั้งค่าสถานะ |= DNS_VERIFY_SECURE;
debug("พบ %d ลายนิ้วมือที่ปลอดภัยใน DNS",
ลายนิ้วมือ->rri_nrdatas);
} อื่น {
debug("พบ %d ลายนิ้วมือที่ไม่ปลอดภัยใน DNS",
ลายนิ้วมือ->rri_nrdatas);
}
และ getrrsetbyname กำหนดไว้ใน https://github.com/openssh/openssh-portable/blob/2dc328023f60212cd29504fc05d849133ae47355/openbsd-compat/getrrsetbyname.c และเป็นพื้นห่อหุ้ม res_query ซึ่งเป็นการเชื่อมโยง libc ระดับต่ำเพื่อทำการสืบค้น DNS
ฉันได้พบที่ https://weberblog.net/sshfp-authenticate-ssh-fingerprints-via-dnssec/ รายละเอียดบางอย่างเกี่ยวกับ จุ๊ๆ พฤติกรรมระหว่างการตรวจสอบ (DNSSEC) SSHFP บันทึกหรือไม่
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
