Chromium-nettleseren, den blomstrende åpen kildekode-forelderen til Google Chrome og den nye Microsoft Edge, har fått betydelig negativ oppmerksomhet for en funksjon som var ment med gode intensjoner: den sjekker om brukerens ISP "stjeler" ikke-eksisterende domenesøksresultater .
, som lager falske spørringer for tilfeldige "domener" som det er statistisk usannsynlig å eksistere, er ansvarlig for omtrent halvparten av den totale trafikken som mottas av rot-DNS-servere over hele verden. Verisign-ingeniør Matt Thomas skrev en lang på APNIC-bloggen som beskriver problemet og vurderer omfanget.
Hvordan DNS-oppløsning vanligvis utføres
Disse serverne er den høyeste myndigheten du bør kontakte for å løse .com, .net, etc. slik at de vil fortelle deg at frglxrtmpuf ikke er et toppnivådomene (TLD).
DNS, eller Domain Name System, er et system der datamaskiner kan løse minneverdige domenenavn som arstechnica.com til mye mindre brukervennlige IP-adresser som 3.128.236.93. Uten DNS ville ikke Internett eksistere på en måte som mennesker kunne bruke, noe som betyr at unødvendig belastning på infrastrukturen på øvre nivå er et reelt problem.
Å laste en enkelt moderne nettside kan kreve utrolig mange DNS-oppslag. For eksempel, da vi analyserte ESPNs hjemmeside, telte vi 93 separate domenenavn, alt fra a.espncdn.com til z.motads.com. Alle er nødvendige for at siden skal lastes helt inn!
For å imøtekomme denne typen arbeidsbelastning for en søkemotor som må betjene hele verden, er DNS utformet som et hierarki på flere nivåer. På toppen av denne pyramiden er rotserverne – hvert toppnivådomene, for eksempel .com, har sin egen familie av servere som er den høyeste autoriteten for hvert domene under dem. Ett steg opp disse servere er selve rotserverne, fra a.root-servers.net til m.root-servers.net.
Hvor ofte skjer dette?
Takket være bufringhierarkiet på flere nivåer i DNS-infrastrukturen, når en svært liten prosentandel av verdens DNS-spørringer rotserverne. De fleste får DNS-løserinformasjonen direkte fra Internett-leverandøren. Når en brukers enhet trenger å vite hvordan man kommer til et bestemt nettsted, sendes en forespørsel først til en DNS-server administrert av den lokale leverandøren. Hvis den lokale DNS-serveren ikke vet svaret, videresender den forespørselen til sine egne "videresendinger" (hvis spesifisert).
Hvis verken den lokale leverandørens DNS-server eller "videresendingsservere" spesifisert i konfigurasjonen har et bufret svar, sendes forespørselen direkte til den autoritative domeneserveren ovenfor den du prøver å konvertere. Når домен.com dette vil bety at forespørselen sendes til de autoritative serverne til selve domenet com, som ligger på gtld-servers.net.
System gtld-servers, som forespørselen ble sendt til, svarer med en liste over autoritative navneservere for domenet domain.com, samt minst én koblingspost som inneholder IP-adressen til en slik navneserver. Deretter beveger svarene seg nedover i kjeden - hver videresending sender disse svarene ned til serveren som ba om dem, til svaret til slutt når den lokale leverandørens server og brukerens datamaskin. Alle av dem cacher dette svaret for ikke å forstyrre systemer på høyere nivå unødvendig.
I de fleste tilfeller registrerer navneserver for domene.com vil allerede være bufret på en av disse videresendingene, så rotserverne vil ikke bli forstyrret. Men foreløpig snakker vi om typen URL vi er kjent med - den som er konvertert til en vanlig nettside. Chrome-forespørsler er på nivå ovenfor dette, på trinnet til selve klyngene root-servers.net.
Chromium og NXDomain tyverisjekk
Chromium sjekker "lurer denne DNS-serveren meg?" står for nesten halvparten av all trafikk som når Verisigns klynge av rot-DNS-servere.
Chromium-nettleseren, hovedprosjektet til Google Chrome, den nye Microsoft Edge og utallige mindre kjente nettlesere, ønsker å gi brukerne enkelt å søke i en enkelt boks, noen ganger kalt en "Omnibox". Med andre ord, brukeren skriver inn både ekte URL-er og søkemotorsøk i samme tekstfelt øverst i nettleservinduet. Ved å ta et nytt skritt mot forenkling, tvinger det heller ikke brukeren til å skrive inn deler av URL-en med http:// eller https://.
Så praktisk som dette er, krever denne tilnærmingen at nettleseren forstår hva som bør betraktes som en URL og hva som bør betraktes som et søk. I de fleste tilfeller er dette ganske åpenbart - for eksempel kan en streng med mellomrom ikke være en URL. Men ting kan bli vanskeligere når du vurderer intranett – private nettverk som også kan bruke private toppnivådomener for å løse ekte nettsteder.
Hvis en bruker på bedriftens intranett skriver «markedsføring» og bedriftens intranett har en intern nettside med samme navn, viser Chromium en informasjonsboks som spør brukeren om de vil søke etter «markedsføring» eller gå til https://marketing. Dette er kanskje ikke tilfelle, men mange Internett-leverandører og offentlige Wi-Fi-leverandører "kaprer" hver feilstavede URL, og omdirigerer brukeren til en bannerfylt side.
Tilfeldig generasjon
Chromium-utviklerne ønsket ikke at brukere på vanlige nettverk skulle se en informasjonsboks som spør hva de mente hver gang de søkte etter et enkelt ord, så de implementerte en test: Når de starter en nettleser eller bytter nettverk, utfører Chromium DNS-oppslag på tre tilfeldig genererte "domener" på toppnivå, syv til femten tegn lange. Hvis to av disse forespørslene returnerer med samme IP-adresse, antar Chromium at det lokale nettverket "kaprer" feilene NXDOMAIN, som den skal motta, så nettleseren anser alle enkeltord-søk som legges inn som søkeforsøk inntil videre.
Dessverre, i nettverk som no stjeler resultatene av DNS-spørringer, disse tre operasjonene stiger vanligvis til toppen, helt til selve rotnavnserverne: den lokale serveren vet ikke hvordan den skal løses qwajuixk, så videresender denne forespørselen til sin speditør, som gjør det samme, inntil endelig a.root-servers.net eller en av hans "brødre" vil ikke bli tvunget til å si "Beklager, men dette er ikke et domene."
Siden det er omtrent 1,67*10^21 mulige falske domenenavn med lengde fra syv til femten tegn, er den vanligste hver fra disse testene utført på det "ærlige" nettverket, kommer den til rotserveren. Dette utgjør like mye halv fra den totale belastningen på rot-DNS, ifølge statistikk fra den delen av klyngene root-servers.net, som eies av Verisign.
Historien gjentar seg selv
Dette er ikke første gang et prosjekt er laget med de beste intensjoner eller nesten oversvømmet en offentlig ressurs med unødvendig trafikk - dette minnet oss umiddelbart om den lange og triste historien til D-Link og Poul-Henning Kamps NTP-server (Network Time Protocol) på midten av 2000-tallet.
I 2005 mottok FreeBSD-utvikler Poul-Henning, som også eide Danmarks eneste Stratum 1 Network Time Protocol-server, en uventet og stor regning for overført trafikk. Kort fortalt var årsaken at D-Link-utviklere skrev adressene til Stratum 1 NTP-servere, inkludert Kampa-serveren, inn i fastvaren til selskapets linje med svitsjer, rutere og tilgangspunkter. Dette økte øyeblikkelig Kampas servertrafikk nidoblet, noe som fikk den danske Internet Exchange (Danmarks Internet Exchange Point) til å endre tariffen fra «gratis» til «$9 000 per år».
Problemet var ikke at det var for mange D-Link-rutere, men at de var "ute av linjen." På samme måte som DNS, må NTP operere i hierarkisk form - Stratum 0-servere sender informasjon til Stratum 1-servere, som sender informasjon til Stratum 2-servere, og så videre nedover i hierarkiet. En typisk hjemmeruter, switch eller tilgangspunkt som det D-Link hadde programmert med NTP-serveradresser ville sende forespørsler til Stratum 2- eller Stratum 3-serveren.
Chromium-prosjektet, sannsynligvis med de beste intensjoner, replikerte NTP-problemet i DNS-problemet, og lastet Internetts rotservere med forespørsler de aldri var ment å håndtere.
Det er håp om en rask løsning
Chromium-prosjektet har åpen kildekode , som krever deaktivering av Intranet Redirect Detector som standard for å løse dette problemet. Vi må gi kreditt til Chromium-prosjektet: feilen ble funnet før dethvordan Verisigns Matt Thomas ga ham mye oppmerksomhet med sin på APNIC-bloggen. Feilen ble oppdaget i juni, men forble glemt frem til Thomas sitt innlegg; Etter faste begynte han å være under tett oppsyn.
Håpet er at problemet snart vil bli løst, og rot-DNS-servere vil ikke lenger trenge å svare på anslagsvis 60 milliarder falske forespørsler hver dag.
Om rettighetene til annonsering
Episke servere - Er eller Linux med kraftige AMD EPYC-familieprosessorer og veldig raske Intel NVMe-stasjoner. Skynd deg å bestille!
Kilde: www.habr.com