Google Chrome болон шинэ Microsoft Edge-ийн хөгжиж буй нээлттэй эх сурвалж болох Chromium хөтөч нь сайн санааны зорилготой функцэд ихээхэн сөрөг анхаарал хандуулсан: энэ нь хэрэглэгчийн ISP байхгүй домэйны хайлтын үр дүнг "хулгайлж" байгаа эсэхийг шалгадаг. .
, нь статистикийн хувьд байх магадлал багатай санамсаргүй "домэйн"-д зориулсан хуурамч асуулга үүсгэдэг бөгөөд дэлхий даяарх root DNS серверүүдийн хүлээн авсан нийт траффикийн тэн хагасыг хариуцдаг. Verisign инженер Мэтт Томас урт бичжээ APNIC блог дээр асуудлыг тайлбарлаж, түүний цар хүрээг үнэлж байна.
DNS нарийвчлалыг ихэвчлэн хэрхэн гүйцэтгэдэг
Эдгээр серверүүд нь .com, .net гэх мэтийг шийдвэрлэхийн тулд таны холбоо барих ёстой хамгийн дээд байгууллага бөгөөд frglxrtmpuf нь дээд түвшний домэйн (TLD) биш гэдгийг танд хэлэх болно.
DNS буюу Домэйн Нэрийн Систем нь компьютерууд arstechnica.com гэх мэт мартагдашгүй домэйн нэрийг 3.128.236.93 гэх мэт хэрэглэгчдэд ээлтэй IP хаяг болгон шийдвэрлэх систем юм. DNS-гүй бол интернет хүн төрөлхтний хэрэглэж болохуйц байдлаар байхгүй байх байсан бөгөөд энэ нь дээд түвшний дэд бүтцэд шаардлагагүй ачаалал өгөх нь бодит асуудал юм.
Орчин үеийн ганц вэб хуудсыг ачаалахад гайхалтай олон тооны DNS хайлт шаардлагатай. Жишээлбэл, бид ESPN-ийн нүүр хуудсанд дүн шинжилгээ хийхдээ a.espncdn.com-аас z.motads.com хүртэлх 93 тусдаа домэйн нэрийг тоолсон. Хуудсыг бүрэн ачаалахад бүгд шаардлагатай!
Дэлхий даяар үйлчлэх шаардлагатай хайлтын системийн ийм төрлийн ачааллыг хангахын тулд DNS нь олон түвшний шатлалаар бүтээгдсэн. Энэ пирамидын дээд талд root серверүүд байдаг - .com гэх мэт дээд түвшний домэйн тус бүр өөрийн гэсэн гэр бүлийн серверүүдтэй бөгөөд тэдгээр нь доорх домэйн бүрийн хувьд хамгийн өндөр эрх мэдэлтэй байдаг. Нэг алхам дээшээ Эдгээрээс серверүүд нь өөрсдөө эх серверүүд юм a.root-servers.net нь m.root-servers.net.
Энэ нь хэр олон удаа тохиолддог вэ?
DNS дэд бүтцийн олон түвшний кэшийн шатлалын ачаар дэлхийн DNS асуулгын маш бага хувь нь үндсэн серверт хүрдэг. Ихэнх хүмүүс DNS шийдэгчийнхээ мэдээллийг ISP-ээс шууд авдаг. Хэрэглэгчийн төхөөрөмж тодорхой вэбсайт руу хэрхэн нэвтрэхийг мэдэх шаардлагатай үед эхлээд тухайн локал үйлчилгээ үзүүлэгчийн удирддаг DNS сервер рүү хүсэлт илгээгддэг. Хэрэв локал DNS сервер хариултыг мэдэхгүй бол хүсэлтийг өөрийн "зуучлагч" руу (хэрэв заасан бол) дамжуулдаг.
Хэрэв локал үйлчилгээ үзүүлэгчийн DNS сервер болон түүний тохиргоонд заасан "дамжуулах серверүүд"-ийн аль нь ч кэшгүй хариултгүй бол хүсэлтийг эрх бүхий домэйн сервер рүү шууд илгээнэ. их таны хөрвүүлэх гэж оролдож буй хүн. Хэзээ домен.com Энэ нь хүсэлтийг домэйны эрх бүхий серверүүд рүү илгээнэ гэсэн үг юм com-д байрладаг gtld-servers.net.
систем gtld-servers, хүсэлт гаргасан нь domain.com домэйны эрх бүхий нэрийн серверүүдийн жагсаалт, мөн ийм нэрийн серверийн IP хаягийг агуулсан дор хаяж нэг холбоосын бичлэгийн хамт хариу өгдөг. Дараа нь хариултууд нь гинжин хэлхээгээр дамждаг - дамжуулагч бүр эдгээр хариултыг хүссэн сервер рүү дамжуулж, хариулт нь эцэст нь локал үйлчилгээ үзүүлэгчийн сервер болон хэрэглэгчийн компьютерт хүртлээ. Дээд түвшний системд шаардлагагүй саад учруулахгүйн тулд тэд бүгд энэ хариултыг кэшлэнэ.
Ихэнх тохиолдолд нэрийн серверийн бүртгэлийг хийдэг domain.com Эдгээр дамжуулагчийн аль нэгэнд кэш хийгдсэн байх тул root серверт саад учруулахгүй. Гэсэн хэдий ч одоохондоо бид ердийн вэб сайт руу хөрвүүлсэн URL-ын төрөл зүйлийн талаар ярьж байна. Chrome хүсэлтүүд түвшинд байна их энэ нь кластеруудын алхам дээр root-servers.net.
Chromium болон NXDomain хулгайн шалгалт
Chromium "энэ DNS сервер намайг хуурч байна уу?" гэж шалгадаг. Энэ нь Verisign-ийн үндсэн DNS серверүүдийн кластерт хүрч байгаа траффикийн бараг тал хувийг эзэлдэг.
Google Chrome-ийн эх төсөл болох Chromium хөтөч, шинэ Microsoft Edge болон тоо томшгүй олон тооны танигдаагүй хөтчүүд нь заримдаа "Omnibox" гэж нэрлэгддэг нэг хайрцагт хайлт хийхэд хялбар болгохыг хүсдэг. Өөрөөр хэлбэл, хэрэглэгч хөтчийн цонхны дээд талд байгаа ижил текст талбарт жинхэнэ URL болон хайлтын системийн асуулгыг хоёуланг нь оруулна. Хялбарчлах өөр нэг алхам хийх нь хэрэглэгчийг URL-ийн хэсгийг оруулахыг албаддаггүй http:// буюу https://.
Как бы удобно это ни было, такой подход требует, чтобы браузер понял, что нужно считать URL, а что — поисковым запросом. В большинстве случаев это довольно очевидно — например, строка с пробелами не может быть URL. Но всё может быть хитрее, если учесть интранеты — приватные сети, которые могут также использовать приватные домены верхнего уровня для резолвинга настоящих веб-сайтов.
Хэрэв өөрийн компанийн дотоод сүлжээнд хэрэглэгч "маркетинг" гэж бичдэг бол компанийн дотоод сүлжээнд ижил нэртэй дотоод вэб сайт байгаа бол Chromium нь хэрэглэгчээс "маркетинг" гэж хайх уу эсвэл дараах руу очих уу гэсэн мэдээллийн цонхыг харуулдаг. https://marketing. Энэ нь тийм биш байж болох ч олон ISP болон олон нийтийн Wi-Fi үйлчилгээ үзүүлэгчид буруу бичсэн URL бүрийг хулгайлж, хэрэглэгчийг баннераар дүүргэсэн хуудас руу дахин чиглүүлдэг.
Санамсаргүй үеийн
Chromium-ийн хөгжүүлэгчид ердийн сүлжээн дэх хэрэглэгчдэд ганц үг хайх бүрт юу гэсэн үг болохыг асуудаг мэдээллийн хайрцаг харагдуулахыг хүсээгүй тул туршилтыг хэрэгжүүлсэн: Тэд вэб хөтчийг эхлүүлэх эсвэл сүлжээгээ өөрчлөх үед Chromium нь гурван төрлийн DNS хайлт хийдэг. санамсаргүй байдлаар үүсгэгдсэн "домайн" дээд түвшний долоогоос арван таван тэмдэгт. Хэрэв эдгээр хүсэлтүүдийн аль нэг нь ижил IP хаягаар буцаж ирвэл Chromium нь дотоод сүлжээ нь алдааг "булаан авч байна" гэж үздэг. NXDOMAIN, энэ нь хүлээн авах ёстой тул хөтөч нь оруулсан бүх нэг үгтэй асуулгад дараагийн мэдэгдэл хүртэл хайлтын оролдлого гэж үздэг.
Харамсалтай нь сүлжээнд ийм байна үгүй DNS асуулгын үр дүнг хулгайлж, эдгээр гурван үйлдлүүд нь ихэвчлэн хамгийн дээд хэсэгт, үндсэн нэрийн серверүүд хүртэл өсдөг: локал сервер хэрхэн шийдвэрлэхээ мэдэхгүй байна. qwajuixk, тиймээс энэ хүсэлтийг дамжуулагч руугаа дамжуулдаг бөгөөд тэр нь мөн адил хийдэг a.root-servers.net эсвэл түүний нэг "ах" нь "Уучлаарай, гэхдээ энэ домэйн биш" гэж хэлэхийг албадахгүй.
Долоон арван таван тэмдэгтийн урттай ойролцоогоор 1,67*10^21 хуурамч домэйн нэр байдаг тул хамгийн түгээмэл нь тус бүр "Шударга" сүлжээнд хийгдсэн эдгээр туршилтуудаас энэ нь үндсэн сервер рүү ордог. Энэ нь үүнтэй тэнцүү юм хагас кластеруудын тухайн хэсгийн статистикийн дагуу root DNS дээрх нийт ачааллаас root-servers.net, Verisign компанийн эзэмшдэг.
Түүх давтагддаг
Энэ бол хамгийн сайн санаагаар бүтээгдсэн анхны төсөл биш юм эсвэл олон нийтийн нөөцийг шаардлагагүй урсгалаар дүүргэх шахсан - энэ нь 2000-аад оны дундуур D-Link болон Poul-Henning Kamp-ийн NTP (Сүлжээний Цагийн Протокол) серверийн урт бөгөөд гунигтай түүхийг бидэнд санууллаа.
2005 онд Дани улсын цорын ганц Stratum 1 Network Time Protocol серверийг эзэмшдэг FreeBSD хөгжүүлэгч Поул-Хеннинг дамжуулсан траффикийн хувьд гэнэтийн бөгөөд их хэмжээний төлбөр хүлээн авсан. Товчхондоо шалтгаан нь D-Link хөгжүүлэгчид Кампа сервер зэрэг Stratum 1 NTP серверүүдийн хаягийг компанийн свич, чиглүүлэгч, хандалтын цэгүүдийн програм хангамжид бичсэнтэй холбоотой юм. Энэ нь Кампагийн серверийн траффикийг даруй 9 дахин нэмэгдүүлж, Данийн интернет солилцооны (Данийн Интернэт солилцооны цэг) тарифаа "Үнэгүй" байсныг "Жилд 000 доллар" болгон өөрчлөхөд хүргэсэн.
Асуудал нь хэтэрхий олон D-Link чиглүүлэгчид биш, харин тэдгээр нь "шугамаас гадуур" байсан юм. DNS-тэй адил NTP нь шаталсан хэлбэрээр ажиллах ёстой - Stratum 0 серверүүд нь Stratum 1 серверүүд рүү мэдээлэл дамжуулдаг ба тэдгээр нь Stratum 2 серверүүд рүү мэдээлэл дамжуулдаг гэх мэт шатлалын доод шатлалаар дамждаг. NTP серверийн хаягаар програмчлагдсан D-Link шиг ердийн гэрийн чиглүүлэгч, шилжүүлэгч эсвэл хандалтын цэг нь Stratum 2 эсвэл Stratum 3 сервер рүү хүсэлт илгээдэг.
Chromium төсөл нь магадгүй хамгийн сайн санааны үүднээс DNS-ийн асуудал дахь NTP-ийн асуудлыг давтаж, интернетийн үндсэн серверүүдийг хэзээ ч зохицуулах ёсгүй хүсэлтээр ачааллаа.
Хурдан шийдэгдэнэ гэсэн найдвар бий
Chromium төсөл нь нээлттэй эх сурвалжтай , энэ асуудлыг шийдэхийн тулд анхдагчаар Intranet Redirect Detector-ийг идэвхгүй болгох шаардлагатай. Бид Chromium төсөлд үнэлэлт өгөх ёстой: алдаа олдсон өмнө ньVerisign-ийн Мэтт Томас хэрхэн түүний анхаарлыг татсан APNIC блог дээр. Алдаа нь зургадугаар сард илэрсэн боловч Томасын бичлэг хүртэл мартагдсан хэвээр байсан; Мацаг барьсны дараа тэрээр нарийн хяналтанд байх болсон.
Асуудал удахгүй шийдэгдэж, root DNS серверүүд өдөр бүр ойролцоогоор 60 тэрбум хуурамч асуулгад хариу өгөх шаардлагагүй болно гэж найдаж байна.
Сурталчилгааны эрх
Эпик серверүүд Байна уу эсвэл хүчирхэг AMD EPYC гэр бүлийн процессор, маш хурдан Intel NVMe хөтчүүдтэй Линукс. Захиалга өгөхдөө яараарай!
Эх сурвалж: www.habr.com