จำนวนสูงสุดของ IPs ที่ DNS A สามารถมีได้คือเท่าใด


30

ฉันมีความคิดแปลก ๆ - ให้หลายคน / องค์กรโฮสต์แอปพลิเคชันเดียวกันและให้ทุกโหนดของพวกเขาสามารถเข้าถึงได้ผ่านชื่อโดเมนเดียว นั่นคือเพื่อที่จะมีเครือข่ายโซเชียลที่กระจายตัวจริง ๆ ที่ไม่เสียสละการใช้งาน (เช่นผู้ใช้ไม่จำเป็นต้องจำ URL ผู้ให้บริการที่แตกต่างกันและเมื่อผู้ให้บริการรายหนึ่งหยุดทำงานให้เปลี่ยนไปใช้อีกเครือข่ายหนึ่ง)

เพื่อให้บรรลุนั้นฉันคิดว่าสามารถใช้ระเบียน DNS ที่มีหลาย IP ได้

ดังนั้นหนึ่ง DNS สามารถเก็บระเบียน A ไว้ได้กี่ IP คำตอบนี้บอกว่ามันประมาณ 30 แต่กรณีที่ใช้มีความแตกต่าง สำหรับสถานการณ์ข้างต้นฉันไม่สนใจว่า ISP ที่ให้จะมีแคชเพียง 30 รายการเท่านั้นตราบใดที่ ISP อื่น ๆ นั้นแคชอีก 30 รายการและอื่น ๆ


2
คุณกำลังเกี่ยวกับAnycast ?
Lie Ryan

4
ฉันได้เรียนรู้เมื่อนานมาแล้วว่าถ้าคุณต้องถามว่า "จำนวน X สูงสุดคือเท่าไหร่" คุณอาจจะใช้มันผิด ...
LordOfThePigs

ไม่จำเป็นต้อง;) แต่โดยทั่วไปแล้วใช่
Bozho

คำตอบ:


78

คำเตือน: ไม่มีความผิด แต่นี่เป็นความคิดที่เลว ฉันไม่แนะนำให้ใครทำในชีวิตจริง

แต่ถ้าคุณให้แล็บ IT เบื่อหน่ายเรื่องตลก ๆ จะเกิดขึ้น!

สำหรับการทดลองนี้ฉันใช้เซิร์ฟเวอร์ Microsoft DNS ที่ทำงานบน Server 2012 R2 เนื่องจากความยุ่งเหยิงของการโฮสต์โซน DNS ใน Active Directory ฉันจึงสร้างโซนหลักใหม่ที่ชื่อว่า test.com ซึ่งไม่ได้ผสานรวมโฆษณา

ใช้สคริปต์นี้:

$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
    for ($y = 1; $y -lt 256; $y++)
    {
        for ($z = 1; $z -lt 256; $z++)
        {
            Write-Host "1.$x.$y.$z`t( $Count )"
            $Count++
            dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
        }
    }
}

ฉันดำเนินการสร้างโดยไม่มีข้อผิดพลาด 65025 บันทึกโฮสต์สำหรับชื่อที่testing.testing.com.มีทุกที่อยู่ IPv4 จาก 1.1.1.1 ถึง 1.1.255.255

จากนั้นฉันต้องการตรวจสอบให้แน่ใจว่าฉันสามารถทำลายสถิติ A จำนวน 65536 (2 ^ 16 บิต) ทั้งหมดโดยไม่มีข้อผิดพลาดและฉันทำได้ดังนั้นฉันจึงคิดว่าฉันน่าจะได้ไปถึง 16581375 (1.1.1.1 ถึง 1.255 .255.255) แต่ฉันไม่ต้องการนั่งที่นี่และดูสคริปต์นี้ทำงานทั้งคืน

บันทึกมากเกินไป

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

แต่มันจะใช้งานได้จริงหรือไม่

นี่คือสิ่งที่ฉันได้รับจากลูกค้าของฉันตามที่ Wireshark ดู:

แบบสอบถามที่สอง (เปิดภาพในแท็บเบราว์เซอร์ใหม่ขนาดเต็ม)

nslookup

แบบสอบถาม TCP

อย่างที่คุณเห็นเมื่อฉันใช้ nslookup หรือ ping จากไคลเอนต์ของฉันมันจะออกแบบสอบถามสองรายการโดยอัตโนมัติ - หนึ่ง UDP และหนึ่ง TCP อย่างที่คุณทราบแล้วส่วนใหญ่ที่ฉันสามารถยัดเข้าไปในดาตาแกรม UDP คือ 512 ไบต์ดังนั้นเมื่อเกินขีด จำกัด นั้น (เช่นที่อยู่ IP 20-30) ต้องใช้ TCP แทน แต่ถึงแม้จะมี TCP ฉันก็จะได้รับ A ระเบียนย่อย ๆ สำหรับการ test.testing.com เท่านั้น มีการส่งคืน 1,000 รายการต่อการสืบค้น TCP รายการของเรกคอร์ด A จะหมุนเวียนโดย 1 อย่างถูกต้องกับแต่ละเคียวรีที่ต่อเนื่องเช่นเดียวกับที่คุณคาดว่า DNS รอบโรบินจะทำงาน มันจะใช้เวลาหลายล้านแบบสอบถามเพื่อปัด robin ผ่านสิ่งเหล่านี้ทั้งหมด

ฉันไม่เห็นว่าสิ่งนี้จะช่วยให้คุณสร้างเครือข่ายโซเชียลมีเดียที่ยืดหยุ่นและยืดหยุ่นได้ขนาดใหญ่ แต่มีคำตอบให้คุณ


แก้ไข:ในความคิดเห็นการติดตามของคุณคุณถามว่าทำไมฉันคิดว่านี่เป็นความคิดที่ไม่ดี

  • สมมติว่าฉันเป็นผู้ใช้อินเทอร์เน็ตโดยเฉลี่ยและฉันต้องการเชื่อมต่อกับบริการของคุณ ฉันพิมพ์ www.bozho.biz ลงในเว็บเบราว์เซอร์ของฉัน ไคลเอ็นต์ DNS ในคอมพิวเตอร์ของฉันได้รับการบันทึก 1,000 ครั้ง โชคไม่ดีที่ 30 รายการแรกในรายการไม่ตอบสนองเพราะรายการของระเบียน A ไม่ได้รับการปรับปรุงหรืออาจมีการหยุดทำงานขนาดใหญ่ที่ส่งผลกระทบต่ออินเทอร์เน็ต สมมติว่าเว็บเบราว์เซอร์ของฉันมีการหมดเวลา 5 วินาทีต่อ IP ก่อนที่จะดำเนินการต่อและลองอีกครั้ง ตอนนี้ฉันกำลังนั่งอยู่ที่นี่จ้องมองนาฬิกาทรายหมุนรอบ 2 นาทีครึ่งรอให้เว็บไซต์ของคุณโหลด ไม่มีใครมีเวลาสำหรับเรื่องนั้น และฉันแค่สมมติว่าเว็บเบราว์เซอร์ของฉันหรือแอปพลิเคชันใดก็ตามที่ฉันใช้ในการเข้าถึงบริการของคุณจะพยายามมากกว่าที่อยู่ IP 4 หรือ 5 รายการแรก มันอาจจะไม่

  • หากคุณใช้การตรวจสอบโดยอัตโนมัติและอนุญาตให้มีการอัปเดตที่ไม่ผ่านการตรวจสอบหรือไม่ระบุชื่อไปยังโซน DNS โดยหวังว่าจะรักษารายการ A ให้ใหม่อยู่เสมอ ... แค่ลองจินตนาการว่าจะไม่ปลอดภัย! แม้ว่าคุณจะออกแบบระบบบางอย่างที่ลูกค้าต้องการใบรับรอง TLS ของไคลเอ็นต์ที่พวกเขาได้รับจากคุณล่วงหน้าเพื่ออัปเดตโซนหนึ่งไคลเอ็นต์ที่ถูกบุกรุกที่ใดก็ได้บนโลกนี้จะเริ่มต้นบ็อตเน็ตและทำลายบริการของคุณ DNS แบบดั้งเดิมนั้นไม่ปลอดภัยอย่างที่ควรจะเป็น

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

  • DNS round-robin ไม่สามารถทดแทนการโหลดบาลานซ์ที่เหมาะสมได้ มันไม่มีวิธีการกู้คืนจากหนึ่งโหนดที่จะลงหรือไม่สามารถใช้งานได้ในช่วงกลางของสิ่ง คุณจะสั่งให้ผู้ใช้ของคุณทำ ipconfig / flushdns หรือไม่ถ้าโหนดที่พวกเขาเชื่อมต่อลงไป? ปัญหาประเภทนี้ได้รับการแก้ไขโดยสิ่งต่าง ๆ เช่น GSLB และ Anycast

  • เป็นต้น


15
เสียงตบมือช้า
mfinni

4
หากต้องการเพิ่มไปยังสิ่งนี้หากมีการสอบถามเรคคอร์ด A ผ่าน BIND (ซึ่งเป็นสิ่งที่ทำงานบนเซิร์ฟเวอร์ DNS ส่วนใหญ่) จะทำการสลับเรคคอร์ด A และส่งคืนเรคคอร์ด A จำนวนหนึ่งจากนั้น จำนวนที่แน่นอนนั้นถูกกำหนดไว้ในMAX_SHUFFLEซอร์สโค้ด BIND (ซึ่งโดยค่าเริ่มต้นคือ 32)
ub3rst4r

1
อยากรู้อยากเห็นทำไมคุณจะไม่แนะนำ มันแน่นอนเป็นสิ่งที่แปลกมาก แต่นอกเหนือจากการมีโหนดที่เป็นอันตรายให้บริการภายใต้การร้องขอ 'ดี' โดเมนและโหนดล้มเหลวยังคงได้รับการร้องขออะไรที่สามารถไปผิด :-)
Bozho

นอกจากนี้ประสบการณ์ของผู้ใช้จะไม่เปลี่ยนแปลงหรือไม่ แต่ละโหนดเป็นแบบจำลองที่สมบูรณ์หรือไม่ คุณจะมั่นใจได้อย่างไรว่าพวกเขาอยู่ภายใต้การควบคุมของผู้อื่น? หากพวกเขาแตกต่างกันผู้คนจะได้รับหนึ่งไซต์ในวันนี้และอีกไซต์ในวันพรุ่งนี้ โดยส่วนตัวแล้วนั่นจะทำให้ฉันบ้าคลั่ง!
Brandon

18

เพื่อตอบคำถามตามที่ระบุไว้ ("มีกี่ IP ที่สามารถเก็บระเบียน A ระเบียน DNS ได้หรือไม่") คำตอบนั้นง่ายมาก: Aระเบียนเดียวมีที่อยู่เดียวทั้งหมด อย่างไรก็ตามอาจมีหลายAระเบียนสำหรับชื่อเดียวกัน


10

ที่อยู่ IPv4 แต่ละอันจะใช้เวลา 16 ไบต์ในการตอบกลับ ที่อยู่ IPv6 แต่ละแห่งจะใช้เวลา 28 ไบต์ในการตอบกลับ

ขอแนะนำอย่างยิ่งให้คุณมั่นใจว่าคำตอบจะพอดีกับ 512 ไบต์ ที่จะอนุญาตให้มีที่อยู่ IPv4 ประมาณ 25 แห่งและที่อยู่ IPv6 14 แห่ง (พิจารณาว่าคุณต้องการข้อมูลอื่น ๆ ในแพ็กเก็ตด้วย) ขีด จำกัด ที่แน่นอนขึ้นอยู่กับความยาวของชื่อโดเมนของคุณ

หากคุณมีทั้งที่อยู่ IPv4 25 แห่งและที่อยู่ IPv6 14 แห่งคุณจะนับลูกค้าที่ร้องขอที่อยู่ IPv4 และ IPv6 ในแบบสอบถามแยกต่างหาก หากลูกค้าขอที่อยู่ทั้งสองประเภทในแบบสอบถามเดียว (ซึ่งหายาก) คุณจะต้องลดระดับลง

หากขนาดการตอบกลับเกิน 512 ไบต์อาจยังคงใช้งาน UDP ได้หากไคลเอ็นต์และเซิร์ฟเวอร์รองรับ EDNS หากไม่มี EDNS ลูกค้าจะได้รับการตอบกลับที่ถูกตัดทอนและจะต้องลองอีกครั้งผ่าน TCP สิ่งนี้จะเพิ่มการสื่อสารจาก 1 ถึง 4 roundtrips แต่ยิ่งแย่กว่านั้นบางครั้งมีการกำหนดค่าที่ผิดพลาดทำให้ DNS ผ่าน TCP ไม่ทำงาน

แม้ว่าคุณสามารถบีบอัดที่อยู่มากกว่า 14 ที่อยู่ในการตอบกลับโดยไม่ทำให้เกิดปัญหาที่เลเยอร์ DNS แต่ก็ไม่น่าจะมีประโยชน์มาก การหมดเวลาใช้งานโดยไคลเอนต์ก่อนที่จะให้ที่อยู่เดียวและการดำเนินการต่อไปมักจะมีความสำคัญ

ต้องรอให้หมดเวลาแม้แต่ครั้งเดียวสามารถนำไปสู่ประสบการณ์การใช้งานที่ไม่ดี หากลูกค้าต้องผ่านที่อยู่ 14 แห่งก่อนได้รับการตอบกลับผู้ใช้จะต้องรอ 13 ไทม์เอาต์


2
ทุก DNS ควรสนับสนุน EDNS ในวันนี้ ขีด จำกัด 512 ไบต์สำหรับการตอบกลับ DNS ไม่สามารถใช้งานได้อีกต่อไปเนื่องจาก DNSSEC
Barmar

@Barmar แต่ถ้าคุณเปิดเครื่องไว้มันมีความเสี่ยงที่สำคัญทีเดียวเซิร์ฟเวอร์ของคุณจะถูกใช้ในการโจมตีแบบขยายสัญญาณ ครั้งล่าสุดที่ฉันตรวจสอบฉันพบว่าการปิดการผูกนั้นเป็นสิ่งเดียวที่สามารถทำได้เพื่อลดการโจมตีจากการขยายเสียง จนกว่า EDNS จะได้รับการขยายพร้อมกับฟิลด์คุกกี้และการสนับสนุนสำหรับสิ่งที่ได้รับการปรับใช้อย่างกว้างขวางการปิดการสนับสนุนสำหรับการตอบกลับที่มีขนาดใหญ่กว่า 512 ไบต์ยังคงเป็นแนวปฏิบัติที่แนะนำ
kasperd

1
ฉันไม่ได้รับผลการค้นหามากนักเนื่องจากการปิดใช้งาน EDNS เป็นวิธีปฏิบัติที่ดีที่สุด ได้โปรดอ้างอิง การโจมตีการขยายการใช้ประโยชน์จากเซิร์ฟเวอร์แบบเรียกซ้ำจะเกิดขึ้นไม่ว่า EDNS จะเปิดใช้งานหรือไม่หากเครือข่ายของคุณไม่ได้ทำการตรวจสอบความถูกต้องของแหล่งที่อยู่ แม้ว่าเรากำลังพูดถึงเซิร์ฟเวอร์ที่ให้สิทธิ์เท่านั้นนั่นจะเกี่ยวข้องเมื่อคุณกำหนดค่าให้ส่งคืนข้อมูลจำนวนมากในการตอบกลับครั้งเดียวซึ่งการปิดใช้งานจุดนั้นจะไม่ช่วยคุณได้
Andrew B

@AndrewB ฉันจำไม่ได้ว่าฉันอ่านคำแนะนำนั้นได้ที่ไหน ฉันได้อ่านคำแนะนำที่แตกต่างกันมากมายเกี่ยวกับวิธีหลีกเลี่ยงการโจมตีแบบขยายและพวกเขาทั้งหมดดูด เป็นเรื่องที่น่าเสียดายที่ EDNS ไม่ได้แนะนำคุกกี้ซึ่งอาจเป็นวิธีที่มีประสิทธิภาพในการโจมตีการขยายโดยใช้ DNS สิ่งที่ฉันแนะนำในคำตอบของฉันคือหลีกเลี่ยงการใส่บันทึกจำนวนมากในแบบสอบถามที่คุณต้องพึ่งพาผู้อื่นเพื่อเปิดใช้งาน EDNS เพื่อให้คำตอบมีประสิทธิภาพ
kasperd

@AndrewB หากฉันใส่ระเบียน A มากกว่า 512 ไบต์ในโซนหนึ่งและตรวจสอบให้แน่ใจว่าโฮสต์บนเซิร์ฟเวอร์ DNS ที่มีสิทธิ์ซึ่งเปิดใช้งาน EDNS อาจเป็นปัญหาสำหรับผู้ใช้ตัวแก้ไขแบบเรียกซ้ำที่ไม่อนุญาตการตอบสนองที่มีขนาดใหญ่ และนั่นคือเหตุผลที่ฉันแนะนำให้เก็บรักษาระเบียน A ให้น้อยลง ยิ่งกว่านั้นฉันได้อธิบายว่าเหตุใดการรับรู้ประโยชน์ของระเบียน A จำนวนมากจึงไม่เกี่ยวข้องกัน
kasperd

5

สิ่งที่คุณกำลังอธิบายไม่ใช่ความคิดใหม่โดยเฉพาะ ตามที่คำตอบอื่น ๆ ได้กล่าวไปแล้วคุณจะถูก จำกัด ในจำนวนระเบียน A ที่คุณสามารถมีได้ในการตอบครั้งเดียว แต่นั่นไม่ได้กล่าวถึงจำนวนระเบียน A ทั้งหมดที่อาจมี

ตัวอย่างเช่นคุณสามารถใช้เซิร์ฟเวอร์ DNS ที่ตอบแบบสอบถามใด ๆ สำหรับระเบียน A ด้วย IP แบบสุ่ม มีเวลาเพียงพอที่จะส่งผลให้ 4294967296 ระเบียน A ที่ไม่ซ้ำกัน: หนึ่งรายการสำหรับแต่ละที่อยู่ IPv4

อย่างที่ฉันพูดนี่ไม่ใช่ความคิดใหม่ อันที่จริงแล้วมันเป็นส่วนหนึ่งของการทำงานของ Akamai (และอาจเป็น CDN อื่น ๆ อีกมากมาย) ระเบียน A ที่คุณได้รับสำหรับโดเมน Akamai นั้นกำหนดโดยเซิร์ฟเวอร์ DNS black-magic ฉันเดิมพันคำตอบที่คุณได้รับขึ้นอยู่กับการทำโหลดบาลานซ์แบบไดนามิกและข้อกังวลทางภูมิศาสตร์

ตัวอย่างเช่นฉันเลือก a338.g.akamaitech.net ถ้าฉันดูสิ่งนั้นบนคอมพิวเตอร์ของฉันตอนนี้ซึ่งใช้เนมเซิร์ฟเวอร์ที่กำหนด DHCP จาก Comcast:

$ host a338.g.akamaitech.net
a338.g.akamaitech.net has address 23.3.98.65
a338.g.akamaitech.net has address 23.3.98.89

ถ้าฉันถาม DNS ของ Google จะเป็นอย่างไร

$ host a338.g.akamaitech.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

a338.g.akamaitech.net has address 23.3.96.152
a338.g.akamaitech.net has address 23.3.96.120

ฉันเดิมพันถ้าคุณลองฉันเดิมพันคุณจะได้รับคำตอบที่ต่างออกไป Akamai มีเซิร์ฟเวอร์ขอบกี่เครื่องที่ให้บริการทรัพยากรเฉพาะใด ๆ ฉันพนันมากกว่าสอง


ขอบคุณ ใช่ฉันรู้ว่า CDN ทำงานอย่างนั้น แต่ในมุมมองของฉันพวกเขามีบันทึกจำนวน จำกัด ต่อโดเมนย่อย (2 ในข้อสอบของคุณ) คำถามล่าสุดอื่น ๆ ของฉันเกี่ยวกับ CDNs และการใช้ DNS ของพวกเขา :-)
Bozho

2

คนอื่น ๆ บอกว่ามันเป็นรายละเอียด แต่จากมุมมองที่ใช้งานได้จริงขีด จำกัด ฮาร์ดคือขีด จำกัด ขนาดแพ็กเก็ต UDP ที่ 512 ไบต์ ในขณะที่เป็นไปได้ที่จะเปลี่ยนเป็น TCP เมื่อตรวจพบการตัดทอน แต่ในทางปฏิบัติลูกค้าจำนวนมาก / ส่วนใหญ่จะไม่ทำมัน (และพวกเขาไม่ควรจะเป็นมันจะให้ประสบการณ์การใช้งานที่ไม่ดีแก่ผู้ใช้งานส่วนใหญ่ การค้นหาวัตถุประสงค์พิเศษเพื่อสนับสนุน TCP) ดังนั้นคุณจึงดูที่ จำกัด ที่อยู่ประมาณ 30 แห่งสำหรับ IPv4 (ระเบียน A) และค่อนข้างน้อยสำหรับ IPv6 (AAAA) เนื่องจากมีขนาดใหญ่กว่า ความยาวของชื่อโดเมนจะถูกตัดออกและจะ จำกัด จำนวนต่อไป


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

@MichaelMcNally: DNSSEC ไม่ได้มีจุดประสงค์ (อย่างน้อยไม่ได้มาจากผู้ดำเนินการตามหัวข้อในรายการส่งเมล glibc ที่ฉันเข้าร่วม) เพื่อใช้ที่ปลายทาง (แอปพลิเคชั่นที่ทำการค้นหา DNS) แต่ที่เซิร์ฟเวอร์แบบเรียกซ้ำภายในเครื่อง การค้นหาในนามของแอปพลิเคชัน ดังนั้นแม้จะมีการตั้งค่า DNSSEC ก็ไม่มีเหตุผลที่จะคาดหวังให้แอปพลิเคชันพูด DNS ผ่าน TCP UDP ทำงานได้อย่างสมบูรณ์แบบ
..

1

คำตอบสั้น ๆ : ประมาณ 25 เร็กคอร์ดพอดีในแพ็คเก็ต UDP นอกเหนือจากนั้น DNS จะเปลี่ยนเป็น TCP และจะไม่เร็วพอ คุณจะมีปัญหากับลูกค้าที่ไม่ได้ใช้ตัวแก้ไข DNS ที่สามารถเลือก IP "ใกล้ที่สุด" ได้ นอกจากนี้ด้วย wifi และมือถือ "ที่ใกล้ที่สุด" มักจะไม่ใช่เซิร์ฟเวอร์ที่เหมาะสม

คำตอบอีกต่อไป:

อย่าทำอย่างนั้น วิธีที่ดีกว่าคือการตั้งค่าระเบียน CNAME แต่ละรายการสำหรับผู้ใช้แต่ละคนที่ชี้ไปยังเซิร์ฟเวอร์ที่เหมาะสม สมมติว่าคุณมีเซิร์ฟเวอร์สองเครื่องserver-fและserver-rใช้สำหรับ IMAP กำหนดค่าไคลเอ็นต์ IMAP ของแต่ละคนด้วยชื่อเซิร์ฟเวอร์ที่เป็น USERNAME.imap.example.com โดยที่ "USERNAME" ถูกแทนที่ด้วยชื่อผู้ใช้อีเมล ตอนนี้คุณสามารถย้ายผู้คนระหว่างเซิร์ฟเวอร์โดยไม่ต้องกำหนดค่าไคลเอนต์อีเมลของพวกเขาอีกครั้ง

server-f.example.com. IN A 10.10.10.10 server-r.example.com. IN A 10.20.20.20 wilma.imap.example.com. IN CNAME server-f.example.com. fred.imap.example.com. IN CNAME server-f.example.com. betty.imap.example.com. IN CNAME server-r.example.com. barney.imap.example.com. IN CNAME server-r.example.com.

อย่างไรก็ตามถ้าคุณทำเช่นนี้ฉันขอแนะนำอย่างมากว่าคุณสร้างระเบียน DNS โดยอัตโนมัติจากฐานข้อมูลของผู้ใช้ คุณต้องการให้แน่ใจว่าในขณะที่บัญชีถูกสร้างและลบระเบียน DNS จะถูกสร้างและลบด้วยเช่นกัน ไม่เช่นนั้นคุณจะจบลงด้วยความยุ่งเหยิงและความสับสนมากมาย

ฉันเคยเห็นสิ่งนี้ทำใน บริษัท ที่มีผู้ใช้หลายพันคนและเนื่องจากสิ่งต่าง ๆ เป็นแบบอัตโนมัติโลกก็ดีมาก


0

ตามที่คนอื่น ๆ ได้ชี้ให้เห็นมันเป็นความคิดที่น่ากลัวสำหรับการใช้งานจริง

ในโลกแห่งความเป็นจริงมีไคลเอ็นต์ที่ไม่เป็นไปตามข้อกำหนดและตัวแก้ไขที่มีปัญหากับการตอบสนองที่ไม่เหมาะสมภายในเดตาแกรม UDP เดียวและมีไฟร์วอลล์ซึ่งจะบังคับใช้แนวคิดที่เฉพาะเจาะจง แต่ไม่สอดคล้องกับโปรโตคอล

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


0

จุดที่น่าสนใจของเรื่องไม่สำคัญทางประวัติศาสตร์ในเรื่องนี้ ใน 90s, AOL ขยายระเบียน DNS ของพวกเขาเพื่อให้การค้นหา MX จะส่งกลับ> 512 ไบต์ RFC ที่ละเมิดนี้ทำลายเซิร์ฟเวอร์ SMTP จำนวนมาก (qmail เป็นเซิร์ฟเวอร์ที่ได้รับความนิยมในเวลานั้น) และทำให้ปวดศีรษะจำนวนมาก การแก้ไขที่ต้องการการแก้ไขหรือการเพิ่มเส้นทางแบบคงที่

ฉันไม่ทราบว่าสถานการณ์ปัจจุบันคืออะไร แต่ไม่กี่ปีที่ผ่านมาเมื่อฉันได้สัมผัส qmail ล่าสุดแพทช์ยังคงอยู่ในสถานที่

http://www.gossamer-threads.com/lists/qmail/users/30503

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.