Kuka ylläpitää 1.1.1.1:tä? DNS-osoitteen tarkistaminen ennen siihen luottamista

Liitit 1.1.1.1:n VPN:n DNS-kenttään, sivu latautui ja opas näyttää nyt vahvistetulta. Havainto on kapeampi kuin miltä tuntuu: sovellus käyttäytyi toisin, eikä muutos kerro vielä mitään siitä, kuka vastasi kyselyyn tai miksi vanha järjestely epäonnistui. Kopioitu opas kutsuu tunnettua julkista osoitetta usein ”VPN:n DNS:ksi”, ja se on väite omistuksesta, ei tavoitettavuudesta. Sen tarkistaminen, mitä osoite edustaa, kestää viisi minuuttia ja estää pysyvän muutoksen väärästä syystä.

Toimiva asetus ei ole identiteetti

Asetuskentän osoite on päätepiste, ja päätepisteellä on ylläpitäjä. Nämä kaksi tosiasiaa ovat erillisiä, ja jälkimmäinen on se, joka ohitetaan. Useimmin kopioidun parin kohdalla vastaus on julkinen: Cloudflare julkaisee 1.1.1.1 ja 1.0.0.1 resolveriosoitteinaan ja luettelee ne virallisessa osoiteviitteessään. Siksi ylläpitäjän nimi kuuluu osoitteen viereen, ei erilliseen oppaaseen.

Parin syöttäminen tunnelin ollessa päällä ei tee VPN-yhtiöstä sen ylläpitäjää eikä tee liikenteestä anonyymiä. Kysely lähtee koneeltasi kohti yhtiötä, joka julkaisee osoitealueen, ja se yhtiö voi olla arvostettu ja silti olla se osapuoli, johon opas viittasi. Ohjeiden nimike ja todellinen ylläpitäjä ovat eri väitteitä. Kumpikaan ei kerro, kuka ylläpitää välissä olevaa verkkopolkua.

Käytä resolverin omaa julkaistua viitettä osoiteparin tai salatun päätepisteen vahvistamiseen. Toisen toimittajan suositus voi olla perusteltu, ja ”suosittelema”, ”kautta saavutettu” ja ”ylläpitämä” kuvaavat edelleen kolmea eri suhdetta.

Vertaa kolmea asiaa, jotka tietue tarvitsee

Katselmointivalmis tietue erottaa kolme kysymystä: kenen pitäisi vastaanottaa kysely, onko vaihto salaamatonta vai salattua ja minkä polun pitäisi kuljettaa se. Palveluntarjoajan nimi ei voi täyttää toista tai kolmatta, eikä maatunniste täytä yhtäkään niistä. Kirjoita kolme merkintää muistiin ennen muutosta ja vertaa niitä jälkeenpäin. Nämä merkinnät eivät ole vaihdettavissa, ja niiden kohteleminen yhtenä on tapa, jolla arvaus muuttuu dokumentaatioksi.

Vertailu on se, mikä muuttaa toimivan asetuksen dokumentoiduksi päätökseksi. Ilman sitä seuraava henkilö perii osoitteen, johon ei ole liitetty mitään syytä. Lue ensin alla olevan taulukon kolmas sarake, sillä siihen useimmat itsevarmat selitykset todella pysähtyvät.

Taulukko on tarkoituksella lyhyt. Sen pointti on, että jokainen merkintä vastaa eri kysymykseen eikä mikään yksittäinen kenttä täytä kaikkia kolmea.

Paikallinen edelleenvälittäjä kätkee todellisen lähteen

Laite, joka on määritetty käyttämään reititintään DNS:nä, osoittaa edelleenvälittäjään. Se osoite yksilöi kyselyn seuraavan vastaanottajan, ei resolveria, joka lopulta vastaa siihen. Paikallinen stub-resolveri lisää saman lisäaskeleen, ja se on helppo sekoittaa todelliseen asiaan, koska se näkyy jokaisessa tilatulosteessa.

Stub välittää eteenpäin lähteille, jotka sama tuloste myös luettelee, yleensä alempana. Lue koko ketju ennen kuin päättelet mitään ylläpitäjästä, sillä ensimmäinen rivi ei ole koko vastaus. Muuten kutsut vastaanottoa yhtiöksi.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

Toinen komento käyttää resolverin kaikunimeä, kun ylläpitäjä julkaisee sellaisen, raportoidakseen näkemänsä lähdeosoitteen. Kolmas nimeää palvelimen, joka vastasi, eikä se useinkaan ole määrittämäsi osoite. Vertaa kaikkia kolmea tulostetta ennen kuin kirjoitat ylläpitäjän muistiin.

Salattu DNS muuttaa sitä, mikä on näkyvää, ei sitä, kuka sen näkee

DNS over HTTPS ja DNS over TLS suojaavat asiakkaan ja resolverin välistä vaihtoa. Resolveri lukee edelleen jokaisen nimen, jota siltä kysytään, koska vastaaminen on sen työ. Muuttuu se, kuka voi seurata vaihtoa: paikallinen verkko näkee yhteyden yhteen päätepisteeseen pelkkien tekstikyselyjen virran sijaan.

Se, mikä ei muutu, on luottamussuhde, joka osoittaa edelleen siihen organisaatioon, joka ylläpitää kyseistä päätepistettä. Selain, jolla on oma turvallisen DNS:n asetus, voi ohittaa käyttöjärjestelmän resolverin kokonaan. Kohtele niitä kahtena asetuksena, jotka voivat olla eri mieltä, älä yhtenä kahdesti sovellettuna asetuksena.

Yksityiset nimet tarvitsevat jälleen oman päätöksensä. Työtunneli voi ohjata valittuja verkkotunnuksia organisaation resolvereille, ja sen korvaaminen julkisella palvelulla voi rikkoa sisäiset haut tai paljastaa sisäiset nimet väärälle osapuolelle. Tarkista verkkotunnuskäytäntö ennen kuin korvaat kokonaisen sovittimen asetukset.

Pidä havainto kapeana

Kun vertailet, säilytä vanha kokoonpano ja muuta yhtä asetusta kerrallaan. Kirjaa sovellus, toiminto, resolverin käytäntö ja se, ratkeavatko julkiset ja sallitut yksityiset nimet vielä uudelleenyhdistämisen jälkeen. Vertailu, jossa on kaksi muutosta, ei todista kumpaakaan. Kirjoita tulos sinne, mistä seuraava henkilö sen löytää, itse asetuksen viereen.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

Jos sovellus alkaa toimia, pidä väite niin pienenä kuin todisteet sallivat. Muutos auttoi yhtä testiä, eikä se kerro mitään siitä, toimiko aiempi resolveri vilpillisesti, oliko tunneli rikki vai tarvitseeko toinen laite saman korvauksen. Kestävä tulos on kokoonpano, jonka ylläpitäjän ja tarkoituksen voit selittää.