เกิดอะไรขึ้นกับ TLD ของแต่ละประเทศในสงครามที่เกี่ยวข้องกับประเทศนั้น?


30

ฉันพยายามค้นหาสิ่งที่อาจเกิดขึ้นและสิ่งที่น่าจะเกิดขึ้น - ฉันอาศัยอยู่ในสหราชอาณาจักรและเป็นเจ้าของโดเมนของสหราชอาณาจักรรวมถึงโดเมนต่างประเทศเช่น TLD ของรัสเซียและสหรัฐอเมริกาเช่น: domain.co.uk, domain .ru, domain.us

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

  • เป็นไปได้หรือไม่ว่าประเทศหนึ่ง ๆ สามารถ จำกัด หรือห้ามการเข้าถึง TLD ที่เฉพาะเจาะจงจากบางประเทศหรือทุกประเทศได้ (เช่นสหรัฐอเมริกาและรัสเซียอยู่ในภาวะสงครามเป็นไปได้หรือไม่ที่จะหยุดรัสเซียจากการเข้าถึง. us TLD ของพวกเขา)
  • เป็นไปได้ไหมว่า TLD นั้นจะถูก จำกัด หรือห้ามในทางใดทางหนึ่ง? มันจะบรรลุข้อได้เปรียบใด ๆ กับประเทศใดที่จะทำสิ่งนี้หรือไม่? (เช่นสหราชอาณาจักรและสหรัฐอเมริกาอยู่ในภาวะสงครามจะมีข้อได้เปรียบใด ๆ หรือไม่ที่สหรัฐอเมริกาจะห้ามไม่ให้สหราชอาณาจักรเข้าถึง. th TLD ของพวกเขา?)
  • ประเทศใดจะ จำกัด ประเทศของตนเองไม่ให้เข้าถึง TLD ของประเทศอื่นได้หรือไม่? (เช่นสหราชอาณาจักรที่ทำสงครามกับรัสเซียสหราชอาณาจักรจะมีเหตุผลใดที่จะห้ามการเข้าถึงเว็บไซต์รัสเซียหรือไม่)

5
หัวข้อที่เกี่ยวข้องบ้าง: เป็นเจ้าของสหราชอาณาจักร .eu โดเมนจะไม่ได้รับอนุญาตอีกต่อไปเนื่องจาก Brexit และเห็นได้ชัดว่าจะปิดลง: dot-eu-is-going.uk
a_horse_with_no_name

คำตอบ:


35

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

คำตอบสั้น ๆ คือใช่ (แต่โปรดอย่าคิดถึงเพียง URL นั่นคือเว็บ แต่บริการประเภทใดก็ได้เช่นอีเมล VOIP เป็นต้น)

นี่คือเหตุผลว่าทำไม IANA DNS root มอบหมายแต่ละ TLD ให้กับการลงทะเบียนบางส่วน gTLD ได้รับการมอบหมายจากการลงทะเบียนภายใต้สัญญากับ ICANN และ ccTLDs ได้รับการมอบหมายให้รัฐบาลของประเทศที่เกี่ยวข้องซึ่งแต่ละคนตัดสินใจทางเทคนิคว่า CCTLD มีการจัดการอย่างไร (มีหลายรุ่น: บางครั้งมันก็ยังทำงานโดยรัฐบาลเอง outsource ให้กับองค์กรที่ไม่แสวงหาผลกำไรและบางครั้งมันก็อยู่ภายใต้การประกวดราคาสำหรับข้อเสนอที่ดีที่สุดรวมถึง บริษัท ต่างๆ)

การลงทะเบียนเหล่านี้จะจัดการเนมเซิร์ฟเวอร์ซึ่งแต่ละโดเมนที่ลงทะเบียนภายใต้ TLD จะได้รับการมอบหมายผ่านระเบียน NS

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

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

กระบวนการนี้สามารถมองเห็นได้ง่ายโดยใช้ dns +traceเช่น:

dig www.openstreetmap.fr +trace @1.1.1.1 +nodnssec

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.openstreetmap.fr +trace @1.1.1.1 +nodnssec
;; global options: +cmd
.           6313    IN  NS  a.root-servers.net.
.           6313    IN  NS  b.root-servers.net.
.           6313    IN  NS  c.root-servers.net.
.           6313    IN  NS  d.root-servers.net.
.           6313    IN  NS  e.root-servers.net.
.           6313    IN  NS  f.root-servers.net.
.           6313    IN  NS  g.root-servers.net.
.           6313    IN  NS  h.root-servers.net.
.           6313    IN  NS  i.root-servers.net.
.           6313    IN  NS  j.root-servers.net.
.           6313    IN  NS  k.root-servers.net.
.           6313    IN  NS  l.root-servers.net.
.           6313    IN  NS  m.root-servers.net.
;; Received 431 bytes from 1.1.1.1#53(1.1.1.1) in 64 ms

fr.         172800  IN  NS  f.ext.nic.fr.
fr.         172800  IN  NS  d.ext.nic.fr.
fr.         172800  IN  NS  g.ext.nic.fr.
fr.         172800  IN  NS  e.ext.nic.fr.
fr.         172800  IN  NS  d.nic.fr.
;; Received 357 bytes from 192.33.4.12#53(c.root-servers.net) in 62 ms

openstreetmap.fr.   172800  IN  NS  a.dns.gandi.net.
openstreetmap.fr.   172800  IN  NS  c.dns.gandi.net.
openstreetmap.fr.   172800  IN  NS  b.dns.gandi.net.
;; Received 110 bytes from 194.0.36.1#53(g.ext.nic.fr) in 68 ms

www.openstreetmap.fr.   10800   IN  CNAME   osm146.openstreetmap.fr.
osm146.openstreetmap.fr. 10800  IN  A   217.182.186.67
openstreetmap.fr.   10800   IN  NS  b.dns.gandi.net.
openstreetmap.fr.   10800   IN  NS  a.dns.gandi.net.
openstreetmap.fr.   10800   IN  NS  c.dns.gandi.net.
;; Received 147 bytes from 217.70.179.1#53(c.dns.gandi.net) in 81 ms

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

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

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

หมายเหตุตัวอย่างเช่นกรณีนี้: โจทก์บางคนฟ้องให้ชดใช้ค่าเสียหายจากการโจมตีของผู้ก่อการร้ายและเรียกร้อง (แต่ตอนนี้ถูกปฏิเสธ) เพื่อที่จะควบคุม ccTLD ที่พวกเขาคิดว่าเป็นแหล่งกำเนิดของการก่อการร้าย ดูบทความนี้สำหรับบางส่วนของเรื่องนี้: " ฆ่า. IR เพื่อชดเชยผู้ที่ตกเป็นเหยื่อการก่อการร้าย: IGOs ​​เพื่อช่วยเหลือ? "

จุดสำคัญอื่น ๆ ที่ต้องทำความเข้าใจก่อนคือเมื่อคุณซื้อชื่อโดเมนใน TLD ใด ๆ ที่คุณเป็น ขอบเขต (แม้ว่าคุณจะไม่ได้อ่านเมื่อคุณควร) ตามข้อบังคับของ TLD นั้นซึ่งกำหนดข้อกำหนดคุณสมบัติและข้อ จำกัด อื่น ๆ ที่เกี่ยวข้องกับการลงทะเบียนและรักษาชื่อโดเมน สำหรับ ccTLD นี้รวมถึงการปฏิบัติตามกฎหมายของประเทศโดยเฉพาะ และเนื่องจาก CCTLD บางส่วนถูกทำการตลาดว่าเป็น TLD ที่ดีสำหรับเกมชื่อโดเมนบางคนไม่ได้ตระหนักถึงสิ่งนี้ ตัวอย่างเช่นแนวโน้ม ณ จุดหนึ่งเปิดอยู่ .LYและตลกพอ ๆ กับที่คุณต้องการให้ชื่อโดเมนดีนี่ยังคงเป็น ccTLD ของประเทศ "Lybia" และด้วยเหตุนี้คุณต้องปฏิบัติตามกฎหมายและศาสนาอิสลาม บริษัท บางแห่งหลวมหรือเสี่ยงที่จะเสียชื่อโดเมนของพวกเขาด้วยเหตุผลเดียวกันนี้ ดูตัวอย่าง: " ปัญหาในดินแดนโดเมนที่ฉลาด: Bit.ly และอื่น ๆ เสี่ยงต่อการสูญเสีย Swift.ly " หรือ " การปิดระบบโดเมนของลิเบียไม่มีการคุกคาม "

เนื่องจากเราอยู่ .LY และคุณได้พูดเกี่ยวกับสงครามบทความเหล่านี้อาจทำให้คุณเข้าใจถึงสิ่งที่สงครามสามารถทำได้กับชื่อโดเมน (TLDs) หรือเพียงแค่ดิ้นรนควบคุม

แต่สังเกตด้วยว่าการเปลี่ยนแปลงที่รุนแรงสามารถเกิดขึ้นได้กับ ccTLD แม้ว่าจะไม่มีสงครามก็ตาม นี่คือตัวอย่างที่มีชื่อเสียง (ใน): " เรื่องราวของโดเมนระดับบนสุดของสโลวาเกียที่ถูกขโมย "

ให้เรากลับไปที่คำถามเฉพาะของคุณ แต่อย่าลืมว่าพวกเขาเกี่ยวข้องกับคำตอบส่วนตัว

เป็นไปได้หรือไม่ที่ประเทศสามารถ จำกัด หรือห้ามการเข้าถึง   ไปยัง TLD ที่เฉพาะเจาะจงจากบางประเทศหรือทุกประเทศ? (เช่นสหรัฐอเมริกาและ   รัสเซียตกอยู่ในภาวะสงครามเป็นไปได้ไหมที่รัสเซียจะห้ามมิให้เข้าถึง   เป็น. TLD ของพวกเขาหรือไม่)

ใช่คุณสามารถจินตนาการในทางเทคนิคว่า .US เซิร์ฟเวอร์ชื่อปฏิเสธการตอบคำขอที่มาจากสถานที่ทางภูมิศาสตร์ที่เฉพาะเจาะจงในโลก อย่างไรก็ตามสิ่งนี้จะอยู่ไกลจาก 100% ด้วยเหตุผลหลายประการ: ตำแหน่งทางภูมิศาสตร์ของ IP ไม่ใช่วิทยาศาสตร์ที่ยากต่อการเชื่อถือได้ 100% DNS มีแคชใช้งานง่าย VPN ทุกคน (รวมถึงผู้คนจากประเทศที่ได้รับผลกระทบ) สามารถใช้ตัวแก้ไขแบบเปิด เช่น Google Public DNS หรือ CloudFlare หนึ่งหรือ Quad9 อย่างใดอย่างหนึ่ง (อันที่จริงสิ่งนี้เคยใช้ในอดีตเพื่อต่อต้านการเซ็นเซอร์ของรัฐดูตัวอย่าง: " Google DNS Freedom Fight: 8.8.8.8 ") ฯลฯ

เป็นไปได้ไหมว่า TLD นั้นจะถูก จำกัด หรือห้ามในทางใดทางหนึ่ง?   มันจะบรรลุข้อได้เปรียบใด ๆ กับประเทศใด ๆ ที่จะทำเช่นนี้? (เช่นสหราชอาณาจักรและ   สหรัฐอเมริกาตกอยู่ในภาวะสงครามมันจะมีประโยชน์สำหรับสหรัฐอเมริกาที่จะห้ามอังกฤษจาก   เข้าถึง. yuk TLD ของพวกเขา?)

เช่นเดียวกับที่เขียนไว้ด้านบนเทคนิครากของ IANA แสดงรายการ TLD ที่ใช้งานอยู่ในปัจจุบัน ในทางเทคนิคอาจมีการเปลี่ยนแปลงและเปลี่ยนแปลง แต่ภายใต้กระบวนการเฉพาะเช่น ICTN ใหม่รอบ gTLD ในปี 2012 สำหรับการเปลี่ยนแปลงใน ccTLD (เนื่องจากประเทศสามารถตัดสินใจที่จะเปลี่ยนแปลงรายละเอียดต่าง ๆ ของ TLD รวมถึงผู้จัดการด้านเทคนิค) " การมอบหมายหรือถ่ายโอนโดเมนระดับบนสุดของรหัสประเทศ (ccTLD) "

ตอนนี้นอกเหนือจากส่วนทางเทคนิคแล้วมี "การเมือง" ในความหมายทั่วไป:

  • ปัจจุบัน IANA เป็น "ฟังก์ชั่น" มากกว่าโครงสร้าง โครงสร้างคือ PTI (Public Technical Identifiers) ซึ่งปัจจุบันเป็น บริษัท ในเครือของ ICANN ดู https://www.iana.org/about สำหรับรายละเอียด
  • ICANN เป็นองค์กรที่ไม่แสวงหาผลกำไรจัดตั้งขึ้นในแคลิฟอร์เนียสหรัฐอเมริกา เมื่อไม่นานมานี้มีการเปลี่ยนแปลงที่ลึกซึ้งหลังจากความกดดันจากรัฐบาลต่างประเทศหลายแห่งเพื่อให้สามารถมองเห็นได้ว่าเป็น "ระดับสากล" มากขึ้นและมีการควบคุมโดยตรงน้อยลงจากรัฐบาลสหรัฐอเมริกาเหมือนที่เคยเกิดขึ้นในอดีต .XXX คณะผู้แทน) ขณะนี้ไม่มีสัญญาที่เฉพาะเจาะจงระหว่าง ICANN และรัฐบาลสหรัฐอเมริกาอีกต่อไปโดยเฉพาะสำหรับฟังก์ชั่น IANA
  • ผู้ดำเนินการด้านเทคนิคของรูทเนมเซิร์ฟเวอร์ A ซึ่งเป็นมาสเตอร์ของทั้งหมดที่เนมเซิร์ฟเวอร์รูทอื่น ๆ "ล้วน" คัดลอกได้รับการจัดการโดย VeriSign ซึ่งเป็น บริษัท สหรัฐภายใต้สัญญาโดยตรงจากรัฐบาลสหรัฐอเมริกา

ประเทศใดจะ จำกัด ประเทศของตนเองไม่ให้เข้าถึงประเทศอื่น   TLD ของประเทศใด (เช่นสหราชอาณาจักรที่ทำสงครามกับรัสเซียสหราชอาณาจักรจะมีเหตุผลใด ๆ   ที่จะห้ามการเข้าถึงเว็บไซต์รัสเซีย?)

นี่เป็นรูปแบบหนึ่งของการเซ็นเซอร์ DNS และจะกำหนดเป้าหมายให้กับเซิร์ฟเวอร์ชื่อซ้ำมากกว่าที่เป็นแบบใช้สิทธิ์ ใช่ประเทศต่างๆสามารถสั่งให้ผู้ให้บริการท้องถิ่นห้ามการเข้าถึง (แม่นยำยิ่งขึ้น: การแก้ไข) ไปยังเว็บไซต์บางแห่ง สิ่งนี้เกิดขึ้นได้ทุกที่: สหรัฐอเมริกา, เยอรมัน, ฝรั่งเศส, จีน, ออสเตรเลีย, และอื่น ๆ (พูดตามตรงฉันไม่แน่ใจว่าคุณจะพบหลายประเทศที่ไม่มีการเซ็นเซอร์อย่างนั้น) ด้วยเหตุผลต่าง ๆ ตามการเมืองท้องถิ่นและเนื่องจากบางเว็บไซต์ ถือว่าผิดกฎหมายเพื่อขอคำปรึกษาจากประเทศที่กำหนด

แต่ก็เหมือนกับการเซ็นเซอร์ทุกรูปแบบมันสามารถหลบหลีกได้โดยกลไกที่ซับซ้อนมากหรือน้อย เช่นเดียวกับตัวอย่างที่ให้ไว้ข้างต้นเมื่อในบางประเทศเซิร์ฟเวอร์ชื่อซ้ำในพื้นที่ถูกห้ามไม่ให้แก้ไขชื่อบางชื่อคนเขียน 8.8.8.8 (ที่อยู่ IPv4 ของ Resolver DNS สาธารณะของ Google) เพื่อให้ทุกคนสามารถกำหนดค่าระบบใหม่เพื่อใช้งานแทนการใช้ตัวแก้ไข DNS ท้องถิ่น (โกหก) เนื่องจากเห็นได้ชัดว่าประเทศที่ระบุไม่สามารถกำหนดให้ Google เปลี่ยนการตอบกลับสำหรับการค้นหา ในกรณีอื่น ๆ ในอดีตที่แม้อินเทอร์เน็ตในขณะที่การขนส่งถูกรบกวน ISP บางรายในประเทศอื่น ๆ ได้ให้สายโทรศัพท์ที่แนบกับโมเด็มที่คุณสามารถโทรไปเพื่อรับการเข้าถึงอินเทอร์เน็ตได้อีกครั้งแม้ว่า FAI ในพื้นที่ทั้งหมดจะถูกปิด

ในปัจจุบันการเซ็นเซอร์ DNS นั้นมักจะเกี่ยวกับชื่อโดเมนบางชื่อในหลาย TLDs แต่พื้นฐานจะเหมือนกันทั้งหมดในการตรวจสอบ TLD ทั้งหมด

บทความทางเทคนิคนี้สามารถให้คำแนะนำถึงปัญหามากมายเกี่ยวกับวิธีการทำและวิธีการหลีกเลี่ยง: " การเซ็นเซอร์ DNS (DNS โกหก) เท่าที่เห็นโดย RIPE Atlas "

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


3

นี่เป็นคำถามที่น่าสนใจ เป็นไปได้หรือไม่ที่ประเทศใดปฏิเสธการเข้าถึง ccTLD ของโดเมนย่อย? ใช่. เป็นไปได้ไหมที่พวกเขาจะทำเช่นนั้นจากระยะไกล เลขที่

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

ภายใต้มาตรฐานสากล DNS เป็นโปรโตคอลที่ยุติธรรมหมายความว่าทุกคำถามจะได้รับการตอบกลับ เป็นไปได้ว่าเซิร์ฟเวอร์ .ru TLD จะพูดว่า 'aha! IP นั้นมาจากสหราชอาณาจักรและเราจะไม่บอกพวกเขาว่าเซิร์ฟเวอร์ชื่อ domain.ru นั้นอยู่ที่ใด

ในที่สุดทิศทางสำหรับทุกสิ่งถูกควบคุมโดยเซิร์ฟเวอร์ราก เหล่านี้คือเซิร์ฟเวอร์รูทอิสระ 13 เซิร์ฟเวอร์ดำเนินการโดยองค์กรอิสระ 12 แห่งซึ่งทำงานร่วมกันเพื่อรักษาสิทธิ์การเข้าถึง DNS อย่างเท่าเทียมกัน หากสิ่งนี้เกิดขึ้นจริงเซิร์ฟเวอร์รูทร่วมกับหน่วยมาตรฐานสากลสามารถแทนที่เซิร์ฟเวอร์รัสเซียด้วยคนอื่นได้ นั่นคือแทนที่จะพูดว่า 'ไปหา. ถึงที่นั่นในรัสเซีย' พวกเขาอาจพูดว่า 'ไปหาที่นั่น. ใน Urkraine'

ในขณะที่เป็นไปได้มันขัดกับพฤติกรรมระหว่างประเทศทั้งหมดและไม่น่าเป็นไปได้อย่างมาก

แก้ไข: เปลี่ยนถ้อยคำเพื่อชี้แจงไม่ใช่องค์กรอิสระ 13 แห่ง แต่เป็นเซิร์ฟเวอร์รูท 13 เครื่อง


1
เช่นเดียวกับการบ่งชี้อย่างแม่นยำว่าไม่น่าเป็นไปได้ที่ ccTLD จะถูกปิดใช้งาน: .SUccTLD สำหรับสหภาพโซเวียตซึ่งเป็นประเทศที่ไม่เคยมีมานานกว่าหนึ่งในสี่ของศตวรรษยังมีชีวิตอยู่และดี
Calle Dybedahl

คำตอบที่น่าสนใจมากและมีรายละเอียดขอบคุณ! นั่นหมายถึงการควบคุมเพียงอย่างเดียวที่ประเทศโฮสต์นั้นคือการควบคุมเซิร์ฟเวอร์ที่อยู่ในประเทศนั้นหรือไม่? และหากโดเมน. ru ของฉันชี้ไปที่เซิร์ฟเวอร์ที่อยู่ในสหราชอาณาจักรรัสเซียจะไม่มีทางขัดขวางการให้บริการ
Tomy-rex

ไม่สามารถรับรองความถูกต้อง แต่ยังพบสิ่งนี้: theregister.co.uk/2017/12/01/russia_own_internet
Tomy-rex

สำหรับ nitpick เซิร์ฟเวอร์โลจิคัลรูท 13 เซิร์ฟเวอร์ แต่ไม่ใช่องค์กร 13 แห่ง ตัวอย่างเช่นสองรายการ (A และ J,) ได้รับการจัดการโดย VeriSign ดู root-servers.org ซึ่งระบุอย่างชัดเจน: ตั้งแต่ปี 2018-06-15 ระบบเซิร์ฟเวอร์รากประกอบด้วยอินสแตนซ์ 928 ที่ดำเนินการโดยผู้ให้บริการเซิร์ฟเวอร์รูทอิสระ 12 ราย
Patrick Mevzek

3
@CalleDybedahl .su เป็นตัวอย่างที่มีชื่อเสียง แต่ไม่ใช่กฎ คุณมีวันนี้ .sk และ .cz หลังจากการแยกและ .cs ไม่หายไป เหมือนกันสำหรับ .yu ที่หายไปจะถูกแทนที่ด้วย .si, .hr, .rs และ .ms.
Patrick Mevzek

0

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

เป็นไปได้และเกิดขึ้นแล้วโดยไม่มีสงคราม

ประเทศจีนเป็นเจ้าของ. cn TLD มันเคยเปิดกว้างสู่โลกใบนี้ หากรัฐบาลจีนต้องการลบโดเมน. cn เนื่องจากไม่ชอบเนื้อหาบางอย่างมันอาจเปลี่ยนระเบียน DNS ของโดเมน. cn นั้น

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

รัฐบาลจีนสามารถตรวจสอบว่าบริการใดบ้างที่แต่ละโดเมนให้บริการและเนื้อหาใดที่แต่ละโดเมนให้บริการ มันยังสามารถบังคับให้คนติดตั้งแบ็คดอร์บนเซิร์ฟเวอร์ของพวกเขาตามความต้องการที่จะนำเซิร์ฟเวอร์ใด ๆ เข้าสู่ศูนย์ข้อมูล (ลองใช้ความคิดนั้นชั่วครู่หนึ่ง)

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