wildcard DNS บันทึกการปฏิบัติที่ไม่ถูกต้องหรือไม่?


18

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

http://i.dont.like.your.website.mywebsite.tldผมพบว่าเพียงลบคือว่าคนที่สามารถเชื่อมโยงไปยังเว็บไซต์ของฉันโดยใช้


8
บางคนสามารถเชื่อมโยงไปยังเซิร์ฟเวอร์ของคุณโดยใช้ " i.dont.like.your.website.mywebsite.tld " แต่เซิร์ฟเวอร์ของคุณไม่ควรตอบกลับหากไม่ได้กำหนดค่าให้ตอบกลับ (ผ่าน hostheaders หรือ virtualhosts)
joeqwerty

6
ในบางกรณีอาจจำเป็นต้องใช้สัญลักษณ์แทน ยกตัวอย่างเช่น webapps หลายลูกเช่น Wordpress สามารถกำหนดค่าให้อินสแตนซ์ใหม่วางไข่โดยอัตโนมัติโดยใช้โดเมนย่อย - เช่น site1.blog.example.com, site2.blog.example.com - มีสัญลักษณ์แทนในสถานที่สำหรับ*.blog.example.comคุณ don ไม่จำเป็นต้องไปกำหนดค่าแต่ละรายการเหล่านี้
jscott

คำตอบ:


16

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

พิจารณา: example.comคุณเป็นเจ้าของโดเมน คุณตั้งค่าเวิร์กสเตชันของคุณและตั้งชื่อ ... yukon.example.comขอบอกว่า ตอนนี้คุณจะสังเกตเห็น/etc/resolv.confว่ามันมีสาย:

search example.com

สะดวกกว่าเพราะหมายความว่าคุณสามารถค้นหาชื่อโฮสต์เช่นwwwจากนั้นจะค้นหาwww.example.comโดยอัตโนมัติ แต่มันมีด้านมืด: ถ้าคุณเยี่ยมชมแล้วพูดว่า Google แล้วมันจะค้นหาwww.google.com.example.comและถ้าคุณมี wildcard DNS มันจะแก้ไขเว็บไซต์ของคุณและแทนที่จะไปถึง Google คุณจะปิดท้ายด้วยเว็บไซต์ของคุณเอง

สิ่งนี้ใช้ได้กับเซิร์ฟเวอร์ที่คุณใช้งานเว็บไซต์! ถ้าเคยต้องเรียกบริการภายนอกการค้นหาชื่อโฮสต์อาจล้มเหลวในลักษณะเดียวกัน ดังนั้นapi.twitter.comสำหรับตัวอย่างก็จะกลายเป็นapi.twitter.com.example.comเส้นทางโดยตรงกลับไปยังเว็บไซต์ของคุณและแน่นอนล้มเหลว

นี่คือเหตุผลที่ฉันไม่เคยใช้ wildcard DNS


3
@ChrisLively ตำหนิระบบ Linux ที่ทันสมัยว่า "มีประโยชน์" แล้วเพิ่มเข้าไป BTW การใช้ ".local" นั้นเป็นวิธีปฏิบัติที่ไม่ดีไม่ใช่เฉพาะในสภาพแวดล้อม Windows
Michael Hampton

6
ที่จริงผม blogged เกี่ยวกับเรื่องนี้ในการไปถึงสภาพแวดล้อมของ ไม่ต้องพูดถึงว่าอย่างน้อยสามกลุ่มมีการเสนอราคาใน. local TLD ในขณะนี้ที่ ICANN กำลังขายให้กับทุกคนที่มีกระเป๋าเงินเพียงพอ .localไม่ได้จองและไม่ควรใช้ การทำเช่นนั้นเป็นการละเมิด RFC และไม่จำเป็นเลย internal.company.comวิธีที่ดีที่สุดคือการใช้โดเมนย่อยระดับที่สามได้รับมอบหมายสำหรับทรัพยากรภายในเช่น เพียงเพราะคุณเห็นบางสิ่งบางอย่างไม่ถูกต้อง
MDMarra

2
คุณช่วยชี้ฉันไปที่ส่วนของ RFC 2606 ที่จองได้.localไหม ฉันได้อ่าน RFC นี้อย่างน้อยหนึ่งโหลกับคนที่ใช้มันในการโต้แย้งนี้และฉันสามารถบอกคุณได้อย่างแน่นอนว่ามันไม่ได้มี
MDMarra

2
@Zypher จริงๆแล้วมันก็ไม่เคยแนะนำโดย Microsoft (ที่ debunked ในโพสต์บล็อกของฉันเกินไปไปอ่านมันเป็นสิ่งที่ดี) แต่ความจริงที่ว่า SBS จัดส่งโดยใช้.localเริ่มต้นทำให้ MS ดูเหมือนเป็นระเบียบในเรื่องนั้น SBS มาพร้อมกับการกำหนดค่านั้นเพราะมันมีไว้สำหรับลูกค้าที่ไม่ใช่เทคโนโลยีที่มีความรู้ด้านเทคนิคต่ำ มันเป็นเส้นทางของความต้านทานน้อยที่สุด แต่เอกสารโฆษณาที่แท้จริงแนะนำโดเมนย่อยระดับที่สามตลอดทางในยุค W2K
MDMarra

3
โอ้และในอีกไม่กี่ปีมันจะยากมากที่จะได้รับใบรับรองสำหรับ. localซึ่งหมายความว่า UCC / SAN certs สำหรับ Lync / Exchange จะต้องมีการลงนามโดย CA ภายในทำให้มันเจ็บปวดถ้าคุณมีโดเมนภายนอกเข้าร่วม ผู้ใช้
MDMarra

14

wildcard DNS บันทึกการปฏิบัติที่ไม่ถูกต้องหรือไม่?

ส่วนตัวฉันไม่ชอบมัน โดยเฉพาะอย่างยิ่งเมื่อมีเครื่องจักรในโดเมนนั้น ไม่ได้ตรวจสอบข้อผิดพลาดข้อผิดพลาดชัดเจนน้อยกว่า ... แต่ไม่มีอะไรผิดปกติกับมัน

ผมพบว่าเพียงลบคือว่าคนที่สามารถเชื่อมโยงไปยังเว็บไซต์ของฉันโดยใช้http: //i.dont.like.your.website.mywebsite.tld

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

server {
    listen 80;
    server_name *.mywebsite.tld;
    return 301 $scheme://mywebsite.tld$request_uri;
    }

แล้วตามปกติ

server {
    listen  80;
    server_name mywebsite.tld;
    [...]
    }

7

มันเป็นเรื่องของความเห็น สำหรับฉันมันไม่ใช่การฝึกฝนที่ไม่ดี

ฉันกำลังสร้างแอพหลายผู้เช่าซึ่งใช้ฐานข้อมูลต่อผู้เช่า จากนั้นเลือกฐานข้อมูลที่จะใช้ตามโดเมนย่อย

ตัวอย่างเช่นmilkman.example.comจะใช้tenant_milkmanฐานข้อมูล

เช่นนี้ผมได้แยกตารางสำหรับผู้เช่าแต่ละเช่นtenant_milkman.users, tenant_fisherman.users, tenant_bobs_garage.usersซึ่งในความเห็นของผมเป็นจำนวนมากขนาดใหญ่ง่ายต่อการรักษาที่เฉพาะเจาะจงสำหรับ app นี้แทนที่จะมีผู้ใช้ทุกคนจากทุก บริษัท ในโต๊ะเดียวกัน

[edit - Michael Hampton has a good point]

ถ้าคุณไม่มีเหตุผลเฉพาะที่จะยอมรับโดเมนย่อยใด ๆ (เช่นตัวแปร) อย่างที่ฉันทำคุณก็ไม่ควรยอมรับมัน


4
คุณมีเหตุผลทางเทคนิคที่ดีในการใช้ wildcard DNS คนส่วนใหญ่ทำไม่ได้
Michael Hampton

1
ตามจริงแล้วมันดูอันตรายมากสำหรับฉัน - ช่วยให้คุณเข้าถึงฐานข้อมูลโดยพลการโดยเปลี่ยนชื่อโดเมน ฉันขอยืนยันว่านี่เป็นช่องโหว่การฉีดชนิดหนึ่ง เป็นที่ทราบกันดีว่ามันไม่จำเป็นต้องใช้ประโยชน์ - แต่ทำไมจึงมีโอกาส?
sleske

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

@PedroMoreira: ใช่มันช่วยลดพื้นที่การโจมตี ยังคงให้การเข้าถึงฐานข้อมูลโดยพลการดูเหมือนอันตราย ตัวอย่างเช่นจะเกิดอะไรขึ้นถ้ามีฐานข้อมูลสำรองที่มีข้อมูลรับรองเหมือนกัน แต่ข้อมูลที่ถูกลบออกจากฐานข้อมูลหลัก - สิ่งนี้จะอนุญาตให้ทุกคนเข้าถึงผู้ที่รู้จักชื่อได้ ถึงกระนั้นฉันตระหนักถึงความปลอดภัยเป็นเสมอการแลกเปลี่ยน - เพียงแค่ต้องการชี้ให้เห็นถึงอันตรายโดยธรรมชาติ
sleske

1
@sleske tenant_นั่นทำไมทุกฐานข้อมูลสามารถเข้าถึงได้จะมีคำนำหน้า ฉันทำให้แน่ใจว่าแอปพลิเคชันไม่สามารถเชื่อมต่อได้
Pedro Moreira

2

ปัญหาอีกประการหนึ่งคือ SEO: หากทุกคน*.example.comแสดงเนื้อหาเดียวกันเว็บไซต์ของคุณจะได้รับการอ้างอิงที่ไม่ดีอย่างน้อยโดย Google ( https://support.google.com/webmasters/answer/66359 )


จุดทั้งสองเป็นมุมฉาก แม้ว่าชื่อทั้งหมดจะชี้ไปที่ IP เดียวกันเว็บเซิร์ฟเวอร์จะได้รับชื่อที่ร้องขอและสามารถแสดงเนื้อหาที่แตกต่างอย่างสิ้นเชิง
Patrick Mevzek

นั่นเป็นเหตุผลที่ฉันได้ precized "ถ้าทั้งหมด *. example.com แสดงเนื้อหาเดียวกัน" ... ความเสี่ยง SEO ส่งเสียงถึงสิ่งที่ฉันสนใจ
Clément Moulin - SimpleRezo

"ความเสี่ยง SEO ทำให้ฉันฟังสิ่งที่น่าสนใจ" อาจจะ แต่พวกเขาไม่เกี่ยวข้องอย่างสมบูรณ์กับการใช้สัญลักษณ์แทนหรือไม่ คุณสามารถมีชื่อที่แยกกันได้มากมายทั้งหมดเพื่อการแก้ไขที่อยู่ IP เดียวโดยไม่ต้องใช้สัญลักษณ์เสริมใด ๆ และด้วยเหตุนี้ความเสี่ยง SEO ที่คุณพูดถึง (หรือไม่) การใช้สัญลักษณ์แทนจะไม่เปลี่ยนแปลงอะไรในทิศทางใด ๆ ที่นี่
Patrick Mevzek

0

นี่เป็นความคิดที่เลวถ้าคุณต้องการโฮสต์ a.company.com หนึ่งโดเมนย่อยในเว็บเซิร์ฟเวอร์หนึ่งและ b.company.com ในเว็บเซิร์ฟเวอร์อื่นอาจเป็น ISP อีกรายการหนึ่ง คุณจะทำอะไร ?. ดังนั้น wildcard DNS ไม่ใช่ตัวเลือกควรแม่นยำสร้างระเบียน A สำหรับแต่ละโดเมนย่อยและชี้ไปที่ IP ที่เกี่ยวข้อง มีโอกาสที่จะย้ายเว็บเซิร์ฟเวอร์ของคุณจาก ISP หนึ่งไปยัง ISP อื่นในกรณีนี้คุณจะทำอย่างไร


0

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

ฉันช่วยคนที่มีปัญหากับ DMARC ซึ่งเป็นส่วนหนึ่งของการตรวจสอบฉันมักจะค้นหาระเบียน DMARC ด้วย DIG

;; ANSWER SECTION:
_dmarc.somedomain.com. 21599 IN      CNAME   somedomain.com.
somedomain.com.      21599   IN      TXT     "v=spf1 <rest of spf record> -all"

ฉันยังได้ผลลัพธ์เดียวกันเมื่อค้นหาบันทึก DKIM ของพวกเขา

ดังนั้นอีเมลที่ส่งจากโดเมนนี้จะทำให้ DKIM ล้มเหลวเนื่องจากโมดูล DKIM จะพยายามวิเคราะห์ระเบียน SPF สำหรับคีย์ DKIM และล้มเหลวและจะได้รับ Permerror สำหรับ DMARC ด้วยเหตุผลเดียวกัน

โดเมนตัวแทนอาจดูเหมือนเป็นความคิดที่ดี แต่ตั้งค่าผิดพวกเขาสามารถทำให้เกิดปัญหาได้ทุกประเภท


-2

wildcard DNS บันทึกการปฏิบัติที่ไม่ถูกต้องหรือไม่?

ไม่และตรงกันข้ามกับคนอื่นฉันเชื่อว่านี่เป็นวิธีปฏิบัติที่ดี

ผู้ใช้อินเทอร์เน็ตส่วนใหญ่ระบุชื่อ DNS ในบางจุด พวกเขาจะพิมพ์ww.mycompany.comหรือwwe.mycompany.com คุณจะเกิดอะไรขึ้นกับ "อุ๊ปส์ที่เราไม่พบไซต์นั้น" หรือให้พวกเขาดึงหน้าแรกของคุณขึ้นมา บ่อยกว่าไม่ให้ดึงหน้าหลักของคุณเป็นที่ต้องการ ซึ่งเป็นสิ่งที่ผู้คนจำนวนมากทำ

แม้ว่าใครบางคนใส่ลิงค์ไปยังi.dont.like.your.website.whatever.comมันจะยังดึงหน้าแรกของคุณขึ้นมาซึ่งเป็นสิ่งที่คุณต้องการ i.dont....ท้ายที่สุดพวกเขาไม่สามารถทำให้ไซต์นั้นไปยังเซิร์ฟเวอร์ของพวกเขาได้คุณยังคงควบคุมการกำหนดเส้นทาง DNS เพื่อให้ไปที่ไซต์ของคุณ


5
ปัญหาที่ฉันมีกับเหตุผลนี้คือ 1. มันจัดการกับข้อผิดพลาด 2. มันเป็น www-centric ทั้งหมดในขณะที่เร็กคอร์ด wildcard ของคุณจะมีผลกับโปรโตคอลอื่นเช่นกัน ผลที่ตามมาคือการที่คุณจัดการข้อผิดพลาดผิดพลาดสำหรับสิ่งอื่น ๆ ที่คุณไม่ได้พยายามแก้ไขสิ่งต่างๆ
Håkan Lindqvist

-2

ฉันคิดว่าเหตุผลที่ดีที่สุดที่จะไม่มีระเบียน DNS ในครั้งแรกคือหลีกเลี่ยงการมอบที่อยู่ IP เซิร์ฟเวอร์ของคุณให้แก่ผู้โจมตีที่อาจเกิดขึ้นและลดการเปิดเผยการโจมตี DDOS นี่คือการติดตั้งที่แนะนำโดย Cloudflare: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/


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

หากคุณใช้ wildcard dns กับ cloudflare เนื่องจากไม่ผ่าน cloudflare (เว้นแต่คุณจะจ่ายให้กับองค์กรส่วนใหญ่ทำไม่ได้) ทุกคนสามารถ ping โดเมนย่อยที่สร้างขึ้นและค้นหา IP จริงของคุณ หากไม่มีสัญลักษณ์ตัวแทนพวกเขาไม่สามารถทำได้ นั่นคือทั้งหมดที่มีให้มัน
Michael Rogers

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