Chromium-selain, Google Chromen ja uuden Microsoft Edgen kukoistava avoimen lähdekoodin emo, on saanut merkittävää negatiivista huomiota hyvällä tarkoituksella tarkoitetusta ominaisuudesta: se tarkistaa, "varastaako" käyttäjän Internet-palveluntarjoaja olemattomia verkkotunnuskyselyn tuloksia. .
, joka luo väärennettyjä kyselyjä satunnaisille "verkkotunnuksille", joiden olemassaolo on tilastollisesti epätodennäköistä, vastaa noin puolesta DNS-juuripalvelimien maailmanlaajuisesti vastaanottamasta kokonaisliikenteestä. Verisignin insinööri Matt Thomas kirjoitti pitkän tekstin APNIC-blogissa, jossa kuvataan ongelmaa ja arvioidaan sen laajuutta.
Miten DNS-selvitys yleensä suoritetaan
Nämä palvelimet ovat korkein viranomainen, johon sinun tulee ottaa yhteyttä ratkaistaksesi .com-, .net- jne., jotta ne kertovat sinulle, että frglxrtmpuf ei ole ylätason verkkotunnus (TLD).
DNS eli Domain Name System on järjestelmä, jonka avulla tietokoneet voivat jakaa mieleenpainuvat verkkotunnukset, kuten arstechnica.com, paljon vähemmän käyttäjäystävällisiksi IP-osoitteiksi, kuten 3.128.236.93. Ilman DNS:ää Internetiä ei olisi olemassa tavalla, jota ihmiset voisivat käyttää, mikä tarkoittaa, että ylemmän tason infrastruktuurin tarpeeton kuormitus on todellinen ongelma.
Yhden modernin web-sivun lataaminen voi vaatia uskomattoman määrän DNS-hakuja. Kun esimerkiksi analysoimme ESPN:n kotisivua, laskemme 93 erillistä verkkotunnusta a.espncdn.comista z.motads.comiin. Kaikki ne ovat välttämättömiä, jotta sivu latautuu täyteen!
Jotta hakukoneen, jonka on palveltava koko maailmaa, tämäntyyppistä työtaakkaa, DNS on suunniteltu monitasoiseksi hierarkiaksi. Tämän pyramidin huipulla ovat juuripalvelimet – jokaisella ylätason verkkotunnuksella, kuten .com:lla, on oma palvelinperhe, joka on korkein auktoriteetti jokaiselle alla olevalle verkkotunnukselle. Yksi askel ylöspäin nämä palvelimet ovat itse juuripalvelimia a.root-servers.net до m.root-servers.net.
Kuinka usein näin tapahtuu?
DNS-infrastruktuurin monitasoisen välimuistihierarkian ansiosta hyvin pieni osa maailman DNS-kyselyistä saavuttaa juuripalvelimia. Useimmat ihmiset saavat DNS-selvitystietonsa suoraan Internet-palveluntarjoajaltaan. Kun käyttäjän laitteen on tiedettävä, kuinka päästä tietylle verkkosivustolle, pyyntö lähetetään ensin paikallisen palveluntarjoajan hallinnoimalle DNS-palvelimelle. Jos paikallinen DNS-palvelin ei tiedä vastausta, se välittää pyynnön omille "välittäjilleen" (jos määritetty).
Jos paikallisen palveluntarjoajan DNS-palvelimella tai sen asetuksissa määritellyillä "edelleenlähetyspalvelimilla" ei ole välimuistissa olevaa vastausta, pyyntö nostetaan suoraan arvovaltaiselle toimialuepalvelimelle edellä jota yrität muuntaa. Kun домен.com tämä tarkoittaa, että pyyntö lähetetään itse toimialueen arvovaltaisille palvelimille com, jotka sijaitsevat osoitteessa gtld-servers.net.
Järjestelmä gtld-servers, jolle pyyntö tehtiin, vastaa luettelolla verkkotunnuksen domain.com arvovaltaisista nimipalvelimista sekä vähintään yhdellä linkkitietueella, joka sisältää yhden tällaisen nimipalvelimen IP-osoitteen. Seuraavaksi vastaukset siirtyvät ketjua alaspäin - jokainen huolitsija välittää nämä vastaukset niitä pyytäneelle palvelimelle, kunnes vastaus lopulta saapuu paikallisen palveluntarjoajan palvelimelle ja käyttäjän tietokoneelle. Kaikki ne tallentavat tämän vastauksen välimuistiin, jotta ne eivät tarpeettomasti häiritse korkeamman tason järjestelmiä.
Useimmissa tapauksissa nimipalvelin tallentaa domain.com on jo välimuistissa jossakin näistä huolitsijoista, joten juuripalvelimia ei häiritä. Puhumme kuitenkin toistaiseksi meille tutun URL-osoitteen tyypistä - sellaisesta, joka muunnetaan tavalliseksi verkkosivustoksi. Chrome-pyynnöt ovat tasolla edellä tämä itse klustereiden tasolla root-servers.net.
Chromium ja NXDomain varkaustarkistus
Chromium tarkistaa: "Hämmäyttääkö tämä DNS-palvelin minua?" osuus on lähes puolet kaikesta Verisignin DNS-juuripalvelinklusteriin saapuvasta liikenteestä.
Chromium-selain, Google Chromen, uuden Microsoft Edgen ja lukemattomien vähemmän tunnettujen selaimien pääprojekti, haluaa tarjota käyttäjille helpon haun yhdessä laatikossa, jota kutsutaan joskus "omniboxiksi". Toisin sanoen käyttäjä kirjoittaa sekä oikeat URL-osoitteet että hakukonekyselyt samaan tekstikenttään selainikkunan yläosassa. Ottamalla jälleen askeleen kohti yksinkertaistamista, se ei myöskään pakota käyttäjää syöttämään osaa URL-osoitteesta http:// tai https://.
Niin kätevä kuin tämä onkin, tämä lähestymistapa edellyttää, että selain ymmärtää, mitä pitäisi pitää URL-osoitteena ja mitä hakukyselynä. Useimmissa tapauksissa tämä on melko ilmeistä - esimerkiksi merkkijono, jossa on välilyöntejä, ei voi olla URL-osoite. Mutta asiat voivat muuttua hankalammaksi, kun harkitset intranetejä – yksityisiä verkkoja, jotka voivat myös käyttää yksityisiä ylätason verkkotunnuksia oikeiden verkkosivustojen ratkaisemiseen.
Jos käyttäjä yrityksensä intranetissä kirjoittaa sanalla "markkinointi" ja yrityksen intranetissä on samanniminen sisäinen verkkosivusto, Chromium näyttää tietoruudun, jossa kysytään, haluaako hän etsiä sanalla "markkinointi" vai mennä https://marketing. Näin ei ehkä ole, mutta monet Internet-palveluntarjoajat ja julkiset Wi-Fi-palveluntarjoajat "kaappaavat" jokaisen väärin kirjoitetun URL-osoitteen ja ohjaavat käyttäjän jollekin bannereilla täytetylle sivulle.
Satunnainen sukupolvi
Chromiumin kehittäjät eivät halunneet tavallisten verkkojen käyttäjien näkevän tietoruutua, jossa kysytään, mitä he tarkoittivat joka kerta kun he hakivat yhtä sanaa, joten he toteuttivat testin: Kun he käynnistävät selaimen tai vaihtavat verkkoa, Chromium suorittaa DNS-hakuja kolmelle. satunnaisesti luodut "verkkotunnukset" ylimmällä tasolla, seitsemästä viiteentoista merkkiä pitkä. Jos jompikumpi näistä pyynnöistä palaa samalla IP-osoitteella, Chromium olettaa, että paikallinen verkko "kaappaa" virheet NXDOMAIN, jonka sen pitäisi saada, joten selain pitää kaikkia syötettyjä yhden sanan kyselyjä hakuyrityksinä toistaiseksi.
Valitettavasti verkoissa se ei varastaa DNS-kyselyiden tulokset, nämä kolme toimintoa nousevat yleensä huipulle aina juurinimipalvelimille itselleen: paikallinen palvelin ei osaa ratkaista qwajuixk, joten välittää tämän pyynnön välittäjälleen, joka tekee samoin, kunnes lopulta a.root-servers.net tai joku hänen "veljistään" ei joudu sanomaan "Anteeksi, mutta tämä ei ole toimialue".
Koska mahdollisia väärennettyjä verkkotunnuksia on noin 1,67*10^21, joiden pituus vaihtelee seitsemästä viiteentoista merkkiin, yleisin kukin näistä "rehellisessä" verkossa suoritetuista testeistä se pääsee juuripalvelimelle. Tämä vastaa yhtä paljon puoli juuri DNS:n kokonaiskuormituksesta klustereiden kyseisen osan tilastojen mukaan root-servers.net, jotka ovat Verisignin omistamia.
Historia toistuu
Tämä ei ole ensimmäinen kerta, kun projekti on luotu parhailla aikomuksilla tai melkein tulvinut julkisen resurssin tarpeettomalla liikenteellä - tämä muistutti välittömästi D-Linkin ja Poul-Henning Kampin NTP (Network Time Protocol) -palvelimen pitkästä ja surullisesta historiasta 2000-luvun puolivälissä.
Vuonna 2005 FreeBSD-kehittäjä Poul-Henning, joka omisti myös Tanskan ainoan Stratum 1 Network Time Protocol -palvelimen, sai odottamattoman ja suuren laskun lähetetystä liikenteestä. Lyhyesti sanottuna syynä oli se, että D-Linkin kehittäjät kirjoittivat Stratum 1 NTP -palvelimien, mukaan lukien Kampa-palvelimen, osoitteet yrityksen kytkimien, reitittimien ja tukiasemien laiteohjelmistoon. Tämä lisäsi Kampan palvelinliikennettä välittömästi yhdeksännkertaiseksi, jolloin Tanskan Internet Exchange (Tanskan Internet Exchange Point) muutti tariffinsa "Ilmaisesta" "9 000 dollariin vuodessa".
Ongelmana ei ollut se, että D-Link-reitittimiä oli liikaa, vaan se, että ne olivat "poissa rivistä". Kuten DNS, NTP:n on toimittava hierarkkisessa muodossa - Stratum 0 -palvelimet välittävät tiedot Stratum 1 -palvelimille, jotka välittävät tiedot Stratum 2 -palvelimille ja niin edelleen hierarkiassa. Tyypillinen kodin reititin, kytkin tai tukiasema, kuten se, jonka D-Link oli ohjelmoinut NTP-palvelinosoitteilla, lähettäisi pyyntöjä Stratum 2- tai Stratum 3 -palvelimelle.
Chromium-projekti, luultavasti parhaimmillaan, toisti NTP-ongelman DNS-ongelmassa lataamalla Internetin juuripalvelimille pyyntöjä, joita niiden ei koskaan ollut tarkoitus käsitellä.
Toivoa nopeasta ratkaisusta on
Chromium-projektilla on avoin lähdekoodi , joka vaatii oletuksena Intranet Redirect Detectorin poistamisen käytöstä tämän ongelman ratkaisemiseksi. Meidän on annettava tunnustusta Chromium-projektille: virhe löydettiin sitä ennenkuinka Verisignin Matt Thomas sai häneen paljon huomiota APNIC-blogissa. Virhe löydettiin kesäkuussa, mutta unohdettiin Thomasin viestiin asti; Paaston jälkeen hän alkoi olla tiiviissä valvonnassa.
Ongelman toivotaan pian ratkeavan, ja juuri DNS-palvelimien ei enää tarvitse vastata arviolta 60 miljardiin vääriin kyselyihin joka päivä.
Mainonnan oikeuksista
Epic palvelimet - Onko tai Linux tehokkailla AMD EPYC -perheen prosessoreilla ja erittäin nopeilla Intel NVMe -asemilla. Kiirehdi tilaamaan!
Lähde: will.com