เหตุใดฉันจึงควรใช้ FQDN แทนที่อยู่ IP ของเซิร์ฟเวอร์

ในการทำงานกับเซิร์ฟเวอร์ฉันเจอไฟล์กำหนดค่าที่คุณควรป้อนที่อยู่ไปยังเซิร์ฟเวอร์ภายนอก ฉันเคยเห็นบางคนใช้ที่อยู่ IP ของเซิร์ฟเวอร์โดยตรง แต่ฉันเคยได้ยินคำแนะนำมากมายที่จะใช้ชื่อโฮสต์แบบเต็ม (FQDN) แทน เหตุใดฉันจึงควรใช้ชื่อโฮสต์แทนที่อยู่ IP โดยตรง

เพราะถ้าคุณใช้ชื่อโฮสต์คุณจะต้องมีเซิร์ฟเวอร์ DNS ในตัวที่จะเชื่อมโยงชื่อโฮสต์แต่ละรายการกับที่อยู่ IP ข้อเสียระหว่างการใช้ชื่อโฮสต์หรือที่อยู่ IP คืออะไร

— Emil Rowland
แหล่งที่มา

หากคุณมี IP แบบไดนามิกคงเป็นเรื่องง่ายกว่าที่จะเปลี่ยนระเบียน DNS และทำไมเซิร์ฟเวอร์ DNS ท้องถิ่น ทำไมไม่ทำให้ทุกเครื่องมีการแก้ไข IP ของสาธารณะ ข้อเสียอีกอย่างของ IP คือแม้ว่าพวกเขาจะไม่ได้เป็นแบบไดนามิกพวกเขาอาจยังคงขึ้นอยู่กับตำแหน่งทางกายภาพทำให้การย้ายไปยังตำแหน่งอื่นยากขึ้น ดูเหมือนว่าคุณกำลังถามว่าทำไม DNS จึงถูกคิดค้น คำถามนี้ได้รับคำตอบจากที่อื่นหลายครั้ง

— Janus Troelsen

มันเป็นคำแนะนำเสมอ (เช่นใน RFCs) ว่าในระดับแอปพลิเคชันจะจัดการกับชื่อโฮสต์เท่านั้น อย่างไรก็ตามแอปพลิเคชั่นบางตัวอาจไม่ทำงานเว้นแต่จะใช้ IP แต่ตัวผมเองมีความผิดมักจะติดต่ออุปกรณ์ของฉันโดย IP แทนชื่อโฮสต์ - แต่ที่นิสัยไม่ดีอย่างแน่นอนจะสิ้นสุดทันทีที่เราได้อพยพอย่างเต็มที่เพื่อ IPv6 :)

— ฮาเจนฟอน Eitzen

เนื่องจากแน่นอนว่าเซิร์ฟเวอร์ภายนอกจะรักษาความปลอดภัยการสื่อสารทั้งหมดด้วย SSL และใบรับรอง SSL จะถูกเซ็นชื่อสำหรับ FQDN และแอปพลิเคชันของคุณไม่สามารถตรวจสอบเซิร์ฟเวอร์ที่ถูกต้องหากคุณใช้ที่อยู่ IP ขวา? : |

— TessellatingHeckler

@HagenvonEitzen แน่ใจหรือไม่ว่าคุณจะไม่เคยพิมพ์ออกมา::1? :-)

— CVn

คำตอบ:

การใช้ที่อยู่ IP ช่วยให้มั่นใจได้ว่าคุณไม่ได้ใช้เซิร์ฟเวอร์ DNS นอกจากนี้ยังมีประโยชน์ในการป้องกันการโจมตีผ่านการปลอมแปลง DNS

การใช้ FQDN แทนที่อยู่ IP หมายความว่าหากคุณต้องการโยกย้ายบริการของคุณไปยังเซิร์ฟเวอร์ที่มีที่อยู่ IP ที่แตกต่างกันคุณจะสามารถเปลี่ยนระเบียนใน DNS แทนที่จะลองค้นหาทุกหนทุกแห่งที่ใช้ที่อยู่ IP .

สิ่งนี้มีประโยชน์อย่างยิ่งเมื่อคุณมีเซิร์ฟเวอร์และบริการจำนวนมากที่กำหนดค่าโดยบุคคลหลายคน

— Joshua Griffiths
แหล่งที่มา

โดยเฉพาะอย่างยิ่งหากความรู้เกี่ยวกับที่อยู่ IP นั้นอยู่ภายนอกเช่นกันเช่นหากลูกค้าหรือคู่ค้าหรือผู้ขายใช้ ลองนึกภาพว่าแทนที่จะเป็น stackoverflow.com เราทุกคนไปที่ IP ที่เรารู้จักในชื่อ stackoverflow.com แล้วพวกเขาต้องการเปลี่ยน IP หรือไม่ พวกเขาจะบอกผู้ใช้ทุกคนที่เป็นไปได้ของไซต์ว่า IP มีการเปลี่ยนแปลงอย่างไร ดังนั้นชื่อ

— แบรนดอน

@Brandon มันจะเป็นเช่นเดียวกับถ้าตอนนี้พวกเขาตัดสินใจที่จะเปลี่ยนจากการ stackoverflow.com heapunderflow.com ประโยชน์เดิมของชื่อโดเมนสำหรับมนุษย์ที่จะจำแทนstackoverflow.com 151.101.1.69แน่นอนทุกวันนี้ที่อนุญาตโฮสติ้งเสมือนโดเมนย่อยที่เกี่ยวข้องกับผู้ปกครองและผลประโยชน์อื่น ๆ ที่เกิดขึ้นกับพวกเขา

— Ángel

ฉันคิดว่าแก่นแท้ของคำตอบนี้คือองค์กรเป็นเจ้าของ FQDN แต่อาจไม่ได้เป็นเจ้าของที่อยู่ IP

— Pieter Geerkens

ลองใช้ HTTPS / Kerberos ผ่าน IP เทียบกับ FQDN

— Aron

นี่คือจุดประสงค์ของ DNS อย่างแท้จริง

— Lightness Races กับโมนิก้า

DNS ไม่ใช่เพียง FQDN = IP

สิ่งที่สำคัญเกี่ยวกับ DNS คือมันให้มากกว่าระเบียน A (hostname = IP) DNS มีเรคคอร์ดประเภทต่าง ๆ เช่น MX, CNAME, TXT และอื่น ๆ ... ซึ่งบางครั้งอาจจำเป็นต้องใช้กับซอฟต์แวร์บางตัว อนุญาตให้มีการบันทึกที่อยู่หลายรายการ, บันทึก IPv4 + IPv6, ที่อยู่แบบไดนามิก, การทำโหลดบาลานซ์, การแก้ปัญหาตำแหน่งทางภูมิศาสตร์, ความล้มเหลว / ความซ้ำซ้อน ฯลฯ ... DNS บอกคุณว่าอะไรคือสิ่งที่ (www.google.com คือบริการเว็บของ Google, 172.217 .4.110 อะไรนั้น?) ช่วยให้คุณสามารถเปลี่ยนการตั้งค่า / บันทึกเหล่านี้และให้ลูกค้าเลือกโดยไม่ทำการเปลี่ยนแปลงกับไคลเอนต์ทั้งหมด DNS สามารถทำสิ่งที่ซับซ้อนได้

มักจะมีข้อได้เปรียบที่ชัดเจนในการใช้ DNS ผ่านที่อยู่ IP โดยตรง

FQDN สามารถเป็นข้อกำหนดได้

บางสิ่งเช่นเว็บเซิร์ฟเวอร์ที่ใช้ชื่อโฮสต์เสมือนหรือโหลดบาลานเซอร์ ฯลฯ ... จำเป็นอย่างยิ่งที่คุณต้องจัดการผ่าน FQDN หรือชื่อโฮสต์ พวกเขากำหนดวิธีการตอบสนองต่อคำขอของคุณตาม FQDN ที่คุณกำลังเชื่อมต่อ การเชื่อมต่อผ่าน IP อาจไม่ทำงานเลย

มีการออกใบรับรอง SSL โดยใช้ชื่อโดเมนดังนั้นคุณอาจไม่สามารถใช้บริการที่เปิดใช้งาน SSL (อย่างถูกต้อง) โดยไม่มี DNS

นี่เป็นคำค้นหาที่ขุดสำหรับโดเมน google.com เพื่อให้คุณเห็นความซับซ้อนของ DNS

google.com 299 IN 172.217.0.174
google.com 299 IN AAAA 2607: f8b0: 400b: 807 :: 200e
google.com 599 IN MX 10 aspmx.l.google.com
google.com 599 ใน MX 40 alt3.aspmx.l.google.com
google.com 59 IN SOA ns2.google.com dns-admin.google.com 126990955 900 900 1800 60
google.com 599 ใน MX 30 alt2.aspmx.l.google.com
google.com 21599 ใน NS ns2.google.com
google.com 599 ใน MX 20 alt1.aspmx.l.google.com
google.com 599 ใน MX 50 alt4.aspmx.l.google.com
google.com 21599 ใน NS ns1.google.com
google.com 3599 IN TXT "v = spf1 ประกอบด้วย: _spf.google.com ~ all"
google.com 21599 IN CAA 0 ปัญหา "symantec.com"
google.com 21599 IN NS ns3.google.com
google.com 21599 ใน NS ns4.google.com

Yahoo ตอบกลับด้วย 3 ที่อยู่ IP

$ host -ta yahoo.ca
yahoo.ca มีที่อยู่ 77.238.184.24
yahoo.ca มีที่อยู่ 74.6.50.24
yahoo.ca มีที่อยู่ 98.137.236.24

ข้อดีของการใช้ที่อยู่ IP

สำหรับฉันแล้วมันมักจะเป็นเมื่อ DNS สามารถเข้าไปได้หรือไม่ว่าง โดยทั่วไปฉันจะใช้ DNS สำหรับสิ่งส่วนใหญ่

ตัวอย่างหนึ่งที่ที่อยู่ IP อาจดีกว่าคือเมื่อคุณมีสองเครื่องที่มีลิงก์โดยตรงระหว่างเครื่อง (ไม่มีสวิตช์) ที่มีที่อยู่เครือข่ายส่วนตัว (พูด 192.168.1.1 และ 192.168.1.2) และพวกเขาใช้เพื่อการสื่อสารที่มีความพร้อมใช้งานสูง หรือ DRBD หรือบริการที่เฉพาะเจาะจงอื่น ๆ ในกรณีนี้การตั้งค่าสิ่งต่างๆใน DNS อาจไม่สมเหตุสมผล ไม่จำเป็นต้องเพิ่มความซับซ้อนปัญหาด้านประสิทธิภาพและอาจทำให้เกิดข้อผิดพลาด

อีกตัวอย่างหนึ่งคือการกำหนดเส้นทาง ตารางการจัดเส้นทางจะบันทึกที่อยู่ IP ด้วยเหตุผลต่างๆ

อีกอย่างคือการอ้างอิงเซิร์ฟเวอร์ชื่อ (เช่นใน /etc/resolv.conf) เนื่องจากไม่มีเนมเซิร์ฟเวอร์คุณจะไม่สามารถแก้ไขอะไรได้

— ไรอัน Babchishin
แหล่งที่มา

นี่เป็นคำตอบที่ดี แต่ก็ควรพูดอะไรเกี่ยวกับบริการ vhosted ด้วยเช่นกัน IP⟷FQDNเป็นการทำแผนที่แบบหลายต่อหลายคนไม่ใช่แบบตัวต่อตัว

— ปุย

ขอขอบคุณและตกลง DNS มีประโยชน์มากสำหรับการโฮสต์เสมือนแบบใช้ชื่อหากนั่นคือสิ่งที่คุณกำลังอ้างถึง

— Ryan Babchishin

ใช่นั่นคือสิ่งที่ฉันพูดถึง

— ปุย

คำตอบที่ยอดเยี่ยมที่ทำให้ DNS มีสิทธิ์ - ทำบุ๊คมาร์คเพื่อใช้อ้างอิงในอนาคต ฉันมีความคิดเห็นเล็กน้อยของคุณคือ "ตารางการกำหนดเส้นทางจะบันทึกที่อยู่ IP ด้วยเหตุผลต่างๆ" อะไรคือเหตุผลต่าง ๆ ที่คุณอ้างถึง ตารางการจัดเส้นทางไม่มีทางเลือกนอกจากใช้ IP เนื่องจากการกำหนดเส้นทางเกิดขึ้นที่เลเยอร์อินเทอร์เน็ตในขณะที่ DNS ใช้ชั้นแอปพลิเคชันและดังนั้นจึงจำเป็นต้องขึ้นอยู่กับการกำหนดเส้นทาง

— Gardenhead

@gardenhead ขอบคุณ ถูกต้องเกี่ยวกับการกำหนดเส้นทางฉันไม่ต้องการเข้าไป ให้อภัยคำที่ฉันเลือก

— Ryan Babchishin