ระเบียน DNS ที่จะเปลี่ยนบ่อย ๆ [ปิด]

ฉันจะสร้างระเบียนโดเมนที่สามารถเปลี่ยนบ่อยได้อย่างไร

สมมติว่าจุดที่จะต้องexample.org สองนาทีต่อมาก็มีการชี้ไปที่203.0.113.0198.51.100.0

มันจะเป็นเว็บไซต์ทั่วไปที่อยู่เบื้องหลังโดเมน ("ปกติ" เท่านั้นในแง่ของการเข้าถึงโดยใช้เว็บเบราว์เซอร์ทั่วไป) แต่มีอายุการใช้งานสั้นมาก โดเมนจะชี้ไปยังที่อยู่เป็นเวลาอย่างน้อย 3-4 ชั่วโมงก่อนที่จะถูกปิดหรือปิด ไม่จำเป็นต้องปกป้องเซิร์ฟเวอร์ DNS จากการสอบถามบ่อยครั้ง

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

ฉันไม่เชื่อในสิ่งนี้ ... ISP หรือเบราว์เซอร์บางตัวสามารถเพิกเฉยหรือแทนที่ TTL ได้ใช่ไหม หากเป็นข้อกังวลที่ถูกต้องสิ่งที่คาดว่าจะเป็นที่เหมาะสมคือ TTL?

ขอขอบคุณ!

นี้เรียกว่าจานฟลักซ์ระเบียน DNS และโดยปกติแล้วผู้เขียนมัลแวร์จะซ่อนเซิร์ฟเวอร์โครงสร้างพื้นฐานไว้อย่างไร

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

แม้ว่าคุณจะมี TTL 1 นาที แต่มีหนึ่งระเบียนที่มีแนวโน้มว่าจะถูกต้องมากกว่านั้น:

1. แคชของเบราว์เซอร์

   เบราว์เซอร์มักจะแคชระเบียน DNS สำหรับระยะเวลาตัวแปร Firefox ใช้60 วินาที , Chrome ใช้60 วินาทีเช่นกัน, IE 3.x และแคชก่อนหน้านี้เป็นเวลา 24 ชั่วโมง , IE 4.x และสูงกว่าแคชเป็นเวลา 30 นาที

2. ระบบปฏิบัติการแคช

   Windows จะไม่ได้มักจะให้เกียรติ TTL TTL สำหรับ DND ไม่เหมือนกับ TTL สำหรับแพ็กเก็ต IPv4 มันเป็นตัวบ่งชี้ความสดชื่นมากกว่าการรีเฟรชบังคับ Linux สามารถกำหนดค่า nscd เพื่อกำหนดระยะเวลาที่ผู้ใช้ต้องการโดยไม่สนใจ DNS TTL สามารถแคชรายการเป็นเวลาหนึ่งสัปดาห์

3. ISP แคช

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

ตัวสร้างสมดุลจะทำในสิ่งที่คุณต้องการ ด้วย load balancer คุณสามารถมีเซิร์ฟเวอร์ 2 หรือ 4 หรือ 10 ออนไลน์ทั้งหมดในเวลาเดียวกันโดยแบ่งการโหลด หากหนึ่งในนั้นออฟไลน์บริการจะไม่ได้รับผลกระทบ การเปลี่ยนระเบียน DNS จะมีการหยุดทำงานระหว่างเวลาที่เซิร์ฟเวอร์หยุดทำงานและ DNS นั้นเปลี่ยนไป จะใช้เวลามากกว่าหนึ่งนาทีเนื่องจากคุณต้องตรวจสอบการหยุดทำงานเปลี่ยนระเบียนและรอให้เผยแพร่

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

DNS และวิธีการทำงานอาจมาพร้อมกับความเข้าใจผิดตำนานความเชื่อโชคลางและเทพนิยายมากขึ้นในแง่มุมต่าง ๆ ของไอที

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

สำหรับความกังวลและการเขียนด้วยมือเกี่ยวกับ TTL สั้น ๆ พวกเขามักจะทำงานบ่อยกว่าไม่ถึงจุดที่คุณอาจสนใจลองง่ายๆ ที่ $ {day_job} เมื่อเว็บไซต์ของเราย้ายจากแพลตฟอร์ม "เก่า" ไปยังแพลตฟอร์ม "ใหม่" มักจะหมายถึงพวกเขากำลังโยกย้ายในลักษณะที่ไม่มีการแบ่งปันโครงสร้างพื้นฐานใด ๆ ขั้นตอนแรกของฉันในการย้ายข้อมูลคือการตัด TTL ไปที่ 60s ล่วงหน้าก่อนที่จะตัดเพื่อให้ TTL เก่ามีทวีคูณหลายตัวให้หมดทำให้ฉันมั่นใจอย่างสมเหตุสมผลว่า RR ในระยะเปลี่ยนผ่านที่มี TTL สั้นจะ "แพร่กระจายออกไป ." เมื่อฉันพร้อมสำหรับการตัดฉันกำหนดค่าตัว balancer เก่าอีกครั้งเพื่อเปลี่ยนการรับส่งข้อมูลไปยังระบบใหม่ - ผ่านอินเทอร์เน็ต - เพื่อให้ตัว balancer นั้นไม่สมดุลอีกต่อไป แต่เป็น "

จากนั้นฉันก็ตัด DNS และดูบาลานเซอร์ใหม่และเก่า

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

แต่มีสถานการณ์หนึ่งที่ทำให้เกิดการคาดเดาไม่ได้: เมื่อหน้าต่างเบราว์เซอร์ของผู้ใช้ยังคงเปิดอยู่พวกเขามักจะสลักไปยังที่อยู่ที่ค้นพบแล้วและมักจะยังคงอยู่จนกว่าหน้าต่างเบราว์เซอร์ทั้งหมดจะปิด

แต่ในการบรรยายข้างต้นคุณจะพบวิธีแก้ปัญหา: "load balancer" - โดยเฉพาะและแม่นยำมากขึ้น reverse proxy - สามารถเป็นระบบที่ DNS ของคุณชี้ไป

reverse proxy ส่งต่อการร้องขอไปยังที่อยู่ IP เป้าหมายที่ถูกต้องซึ่งแก้ไขโดยใช้ชื่อโฮสต์ "dummy" ตัวที่สองด้วย TTL สั้น ๆ ซึ่งชี้ไปที่เซิร์ฟเวอร์ back-end ที่แท้จริง รายการ DNS จำลองคุณจะมั่นใจได้ถึงการเปลี่ยนแปลงอย่างรวดเร็วและสมบูรณ์แบบ

ข้อเสียคือคุณอาจกำหนดเส้นทางการรับส่งข้อมูลผ่านโครงสร้างพื้นฐานพิเศษที่ไม่จำเป็นหรือจ่ายเงินมากขึ้นสำหรับการขนส่งข้ามขอบเขตเครือข่ายที่หลากหลายซ้ำซ้อน

มีบริการที่ให้ความสามารถแบบนี้ในระดับโลกและสิ่งที่ฉันคุ้นเคยมากที่สุดคือ CloudFront (ส่วนใหญ่แล้ว Cloudflare จะตอบสนองวัตถุประสงค์เดียวกันอย่างแน่นอนเนื่องจากข้อสงสัยเล็ก ๆ น้อย ๆ ของการทดสอบที่ฉันทำบ่งชี้ว่ามันทำงานได้อย่างถูกต้องและฉันแน่ใจว่ามีคนอื่น)

แม้ว่าตลาดหลักเป็น CDN, CloudFront เป็นที่หลักของเครือข่ายทั่วโลกของผู้รับมอบฉันทะแบบย้อนกลับที่มีความสามารถของการเลือกแคชตอบ หากwww.example.comชี้ไปที่ CloudFront และ CloudFront ได้รับการกำหนดค่าให้ส่งต่อคำขอเหล่านี้ไปยังbackend.example.comและระเบียน DNS สำหรับbackend.example.comใช้ TTL สั้น ๆ CloudFront จะทำสิ่งที่ถูกต้องเพราะให้เกียรติ TTL สั้นนั้น เมื่อเร็กคอร์ดส่วนหลังเปลี่ยนแปลงการรับส่งข้อมูลทั้งหมดจะถูกโอนย้ายตามเวลาที่ TTL ทำงาน

TTL บนระเบียนด้านหน้าชี้ไปที่ CloudFront และเบราว์เซอร์และตัวแก้ไขแคชกำลังให้ความเคารพหรือไม่เพราะการเปลี่ยนแปลงปลายทางปลายทางไม่ต้องการการเปลี่ยนแปลงในwww.example.comระเบียน ... ดังนั้นแนวคิดที่ว่า "อินเทอร์เน็ต" มีโดยคำนึงถึงเป้าหมายที่ถูกต้องสำหรับความwww.example.comสอดคล้องไม่ว่าระบบแบ็คเอนด์จะเกิดขึ้นที่ไหน

สำหรับฉันแล้วการแก้ปัญหาอย่างสมบูรณ์โดยการลดเบราว์เซอร์ที่จำเป็นต้อง "ติดตาม" การเปลี่ยนแปลง IP ของเซิร์ฟเวอร์ต้นทาง

TL; dr: จัดเส้นทางการร้องขอไปยังระบบที่ทำหน้าที่เป็นพร็อกซีสำหรับเว็บเซิร์ฟเวอร์จริงดังนั้นเฉพาะการกำหนดค่าพร็อกซีเท่านั้นที่จะต้องรองรับการเปลี่ยนแปลงใน IP เซิร์ฟเวอร์ต้นทาง - ไม่ใช่ DNS ที่หันเข้าหาเบราว์เซอร์

โปรดทราบว่า CloudFront ยังลดเวลาแฝงลงด้วยเวทมนต์ DNS บางอย่างที่อยู่ด้านหน้าซึ่งส่งผลwww.example.comให้การแก้ไขตำแหน่งขอบ CloudFront ที่เหมาะสมที่สุดโดยอิงตามตำแหน่งของเบราว์เซอร์ที่ทำการสืบค้นwww.example.comดังนั้นจึงมีโอกาสน้อยที่สุดในการรับส่งข้อมูล จากเบราว์เซอร์ไปยังจุดกำเนิด ... แต่ส่วนนี้มีความโปร่งใสและอัตโนมัติและอยู่นอกขอบเขตของคำถาม

และแน่นอนว่าการแคชเนื้อหาอาจมีค่าด้วยการลดภาระบนเซิร์ฟเวอร์ต้นทางหรือการขนส่ง - ฉันได้กำหนดค่าเว็บไซต์บน CloudFront ที่เซิร์ฟเวอร์ต้นทางอยู่บนวงจร ADSL และ ADSL นั้นถูก จำกัด อย่างแท้จริงสำหรับแบนด์วิดท์อัปสตรีม เซิร์ฟเวอร์ต้นทางที่ CloudFront เชื่อมต่อเพื่อดึงเนื้อหาไม่จำเป็นต้องเป็นเซิร์ฟเวอร์ภายในระบบนิเวศ AWS

¹ฉันพูดถึงบาลานเซอร์เป็นเอนทิตี้เดียวเมื่ออันที่จริงมันมีหลายโหนด เมื่อ balancer เป็น ELB เครื่องที่อยู่ด้านหลัง balancer จะทำหน้าที่เป็นเซิร์ฟเวอร์แอปจำลองและทำการ hairpinning จริงกับ balancer ของแพลตฟอร์มใหม่เนื่องจาก ELB ไม่สามารถทำสิ่งนี้ได้ด้วยตัวเอง

²ความรู้เพียงอย่างเดียวของบาลานเซอร์ใหม่เกี่ยวกับอันเก่าคือมันจำเป็นต้องเชื่อถือ X-Forwarded-For ของบาลานเซอร์เก่าและไม่ควรทำอัตราบนไอพีใด ๆ ที่ จำกัด อยู่บนแหล่งที่มาของบาลานเซอร์เก่า

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

เมื่อฉันเปลี่ยนระเบียน DNS บ่อยครั้งจะใช้ที่อยู่ IP เก่าเป็นเวลาหลายเดือน ต้องบอกว่า TTL เพียงไม่กี่วินาทีเป็นสิ่งที่ Amazon ใช้ในการสร้างบริการทางเลือกเช่น

แทนที่จะเปลี่ยน DNS คุณสามารถวางพร็อกซีเซิร์ฟเวอร์ / ตัวโหลดบาลานซ์ไว้ด้านหน้าได้

คุณสามารถตรวจสอบการใช้ Dynamic DNS สิ่งนี้ถูกออกแบบมาสำหรับสถานการณ์ที่ @glglgl พูดถึงในความคิดเห็นด้านบนอย่างแม่นยำ ฉันเชื่อว่าพวกเขาใช้ TTL ต่ำซึ่งตามที่ได้กล่าวไว้ก่อนหน้านี้อาจไม่ได้ผล 100% เนื่องจากลูกค้าสามารถเพิกเฉยได้ แต่มันใช้งานได้ "ค่อนข้างดี"

แม้ว่าคุณจะไม่ได้เปลี่ยน IP ของคุณบ่อยๆก็ตามสิ่งสำคัญคือการทำให้ TTL ของคุณเหมาะสม เมื่อหลายปีก่อน บริษัท ที่ฉันเคยทำงานให้กับ ISP ที่มีการเปลี่ยนแปลงซึ่งทำให้ IP ของเราเปลี่ยนไป น่าเสียดายที่เราได้ตั้งค่า TTL ของเราเป็นสิ่งที่ไร้สาระเช่นเดือนดังนั้นระเบียน DNS เก่า ๆ จึงถูกเก็บไว้เป็นเวลานาน