Tapaamme Cloudflaren palvelun osoitteissa 1.1.1.1 ja 1.0.0.1 tai "julkinen DNS-hylly on saapunut!"

Cloudflare Company esitetty julkinen DNS osoitteissa:

• 1.1.1.1
• 1.0.0.1
• 2606: 4700: 4700 :: 1111
• 2606: 4700: 4700 :: 1001

Käytännön sanotaan olevan "tietosuoja ensin", jotta käyttäjät voivat olla mielenrauhassa pyyntöjensä sisällön suhteen.

Palvelu on mielenkiintoinen siinä mielessä, että se tarjoaa tavanomaisen DNS:n lisäksi mahdollisuuden käyttää teknologioita DNS-over-TLS и DNS-over-HTTPS, joka estää suuresti palveluntarjoajia salakuuntelemasta pyyntöjäsi pyyntöjen polulla - ja kerää tilastoja, valvoo ja hallinnoi mainoksia. Cloudflare väittää, että ilmoituksen päivämäärää (1. huhtikuuta 2018 tai 04. amerikkalaisella merkinnällä) ei valittu sattumalta: minä muuna päivänä vuodesta "neljä yksikköä" esitetään?

Koska Habrin yleisö on teknisesti taitava, perinteinen osio "miksi tarvitset DNS?" Laitan sen postauksen loppuun, mutta kerron tässä vielä käytännönläheisempiä asioita:

Miten uutta palvelua käytetään?

Yksinkertaisin asia on määrittää yllä olevat DNS-palvelinosoitteet DNS-asiakkaassasi (tai ylävirran puolella käyttämäsi paikallisen DNS-palvelimen asetuksissa). Onko järkevää korvata tavalliset arvot Google DNS (8.8.8.8 jne.), tai hieman harvinaisempi Yandexin julkiset DNS-palvelimet (77.88.8.8 ja muut vastaavat) Cloudflaren palvelimille - he tekevät päätöksen puolestasi, mutta puhuvat aloittelijan puolesta aikataulu vastenopeus, jonka mukaan Cloudflare on nopeampi kuin kaikki kilpailijat (täsmennä: mittaukset on tehnyt kolmannen osapuolen palvelu, ja nopeus tietylle asiakkaalle voi tietysti vaihdella).

On paljon mielenkiintoisempaa työskennellä uusilla tiloilla, joissa pyyntö lentää palvelimelle salatun yhteyden kautta (itse asiassa vastaus palautetaan sen kautta), mainittujen DNS-over-TLS- ja DNS-over-HTTPS-yhteyksien kanssa. Valitettavasti niitä ei tueta "pakkauksesta" (tekijät uskovat, että tämä on "vielä"), mutta heidän työnsä järjestäminen ohjelmistossasi (tai jopa laitteistossasi) ei ole vaikeaa:

DNS HTTP:n kautta (DoH)

Kuten nimestä voi päätellä, viestintä tapahtuu HTTPS-kanavan kautta, mikä tarkoittaa

1. laskeutumispisteen (päätepisteen) läsnäolo - se sijaitsee osoitteessa https://cloudflare-dns.com/dns-queryJa
2. asiakas, joka voi lähettää pyyntöjä ja vastaanottaa vastauksia.

Pyynnöt voivat olla joko DNS Wireformat -muodossa, joka on määritetty RFC1035 (lähetetään POST- ja GET HTTP -menetelmillä) tai JSON-muodossa (käyttäen GET HTTP -menetelmää). Minulle henkilökohtaisesti ajatus DNS-pyyntöjen tekemisestä HTTP-pyyntöjen kautta tuntui odottamattomalta, mutta siinä on järkeä: tällainen pyyntö läpäisee monet liikenteen suodatusjärjestelmät, vastausten jäsentäminen on melko yksinkertaista ja pyyntöjen luominen on vielä helpompaa. Tavalliset kirjastot ja protokollat ​​vastaavat turvallisuudesta.

Pyydä esimerkkejä suoraan asiakirjoista:

GET-pyyntö DNS Wireformat -muodossa

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
HTTP/2 200
date: Fri, 23 Mar 2018 05:14:02 GMT
content-type: application/dns-udpwireformat
content-length: 49
cache-control: max-age=0
set-cookie: __cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=Sat, 23-Mar-19 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly
server: cloudflare-nginx
cf-ray: 3ffe69838a418c4c-SFO-DOG

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

POST-pyyntö DNS Wireformat -muodossa

$ echo -n 'q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | base64 -D | curl -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://cloudflare-dns.com/dns-query -o - | hexdump

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

Sama, mutta käyttämällä JSONia

$ curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=example.com&type=AAAA'

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "example.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "example.com.",
      "type": 1,
      "TTL": 1069,
      "data": "93.184.216.34"
    }
  ]
}

Ilmeisesti harvinainen (jos ainakin yksi) kotireititin voi toimia DNS:n kanssa tällä tavalla, mutta tämä ei tarkoita, että tuki ei ilmesty huomenna - ja mielenkiintoista kyllä, täällä voimme toteuttaa DNS-työskentelyn sovelluksessamme (kuten jo jo). aikoo tehdä Mozillan, vain Cloudflare-palvelimilla).

DNS TLS: n kautta

Oletusarvoisesti DNS-kyselyt lähetetään ilman salausta. DNS TLS:n kautta on tapa lähettää ne suojatun yhteyden kautta. Cloudflare tukee DNS:ää TLS:n kautta vakioportissa 853 ohjeiden mukaisesti RFC7858. Tämä käyttää varmennetta, joka on myönnetty cloudflare-dns.com-isännälle, TLS 1.2 ja TLS 1.3 ovat tuettuja.

Yhteyden muodostaminen ja työskentely protokollan mukaan menee jotakuinkin näin:

• Ennen DNS-yhteyden muodostamista asiakas tallentaa base64-koodatun SHA256-tiivisteen cloudflare-dns.comin TLS-sertifikaatista (nimeltään SPKI).
• DNS-asiakas muodostaa TCP-yhteyden osoitteeseen cloudflare-dns.com:853
• DNS-asiakas aloittaa TLS-kättelyn
• TLS-kättelyprosessin aikana cloudflare-dns.com-isäntä esittää TLS-sertifikaattinsa.
• Kun TLS-yhteys on muodostettu, DNS-asiakas voi lähettää DNS-pyyntöjä suojatun kanavan kautta, mikä estää pyyntöjen ja vastausten salakuuntelun ja huijauksen.
• Kaikkien TLS-yhteyden kautta lähetettyjen DNS-kyselyiden on oltava DNS:n lähettäminen TCP:n kautta.

Esimerkki pyynnöstä DNS:n kautta TLS:n kautta:

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 170 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare, Inc.,CN=*.cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; QUESTION SECTION:
;; example.com.             IN  A

;; ANSWER SECTION:
example.com.            2347    IN  A   93.184.216.34

;; Received 468 B
;; Time 2018-03-31 15:20:57 PDT
;; From 1.1.1.1@853(TCP) in 12.6 ms

Tämä vaihtoehto näyttää toimivan parhaiten paikallisissa DNS-palvelimissa, jotka palvelevat paikallisen verkon tai yksittäisen käyttäjän tarpeita. Totta, standardin tuella ei ole kovin hyvä, mutta - toivotaan!

Kaksi sanaa selittämään, mistä keskustelussa on kyse

Lyhenne DNS tarkoittaa Domain Name Serviceä (siis sanominen "DNS-palvelu" on jokseenkin tarpeetonta, lyhenne sisältää jo sanan "palvelu"), ja sitä käytetään ratkaisemaan yksinkertainen tehtävä - ymmärtää, mikä IP-osoite tietyllä isäntänimellä on. Joka kerta kun joku napsauttaa linkkiä tai kirjoittaa osoitteen selaimen osoitepalkkiin (esim.https://habrahabr.ru/post/346430/"), ihmistietokone yrittää selvittää, mille palvelimelle lähetetään pyyntö sivun sisällön saamiseksi. Habrahabr.ru:n tapauksessa DNS:n vastaus sisältää osoituksen verkkopalvelimen IP-osoitteesta: 178.248.237.68, ja sitten selain yrittää jo ottaa yhteyttä palvelimeen määritetyllä IP-osoitteella.

DNS-palvelin puolestaan ​​​​vastaanotettuaan pyynnön "mikä on habrahabr.ru-nimisen isännän IP-osoite?" määrittää, tietääkö se mitään määritetystä isännästä. Jos ei, se tekee pyynnön muille maailman DNS-palvelimille ja yrittää askel askeleelta selvittää vastauksen esitettyyn kysymykseen. Tämän seurauksena, kun lopullinen vastaus on löydetty, löydetyt tiedot lähetetään niitä edelleen odottavalle asiakkaalle, ja ne tallennetaan itse DNS-palvelimen välimuistiin, minkä avulla voit vastata samanlaiseen kysymykseen paljon nopeammin seuraavalla kerralla.

Yleinen ongelma on, että ensinnäkin DNS-kyselytiedot lähetetään selkeästi (mikä antaa kenelle tahansa, jolla on pääsy liikennevirtaan, mahdollisuuden eristää DNS-kyselyt ja saamansa vastaukset ja sitten jäsentää ne omiin tarkoituksiinsa; tämä antaa kyky kohdistaa mainoksia tarkasti DNS-asiakkaalle, mikä on melko paljon!). Toiseksi, jotkut Internet-palveluntarjoajat (emme osoita sormella, mutta eivät pienimmät) pyrkivät näyttämään mainoksia yhden tai toisen pyydetyn sivun sijasta (joka toteutetaan yksinkertaisesti: habranabr.ru-kyselyn määritetyn IP-osoitteen sijaan isäntänimi, satunnainen henkilö Näin ollen palautetaan palveluntarjoajan web-palvelimen osoite, jossa mainoksen sisältävä sivu palvellaan). Kolmanneksi on Internet-palveluntarjoajia, jotka ottavat käyttöön mekanismin yksittäisten sivustojen estämistä koskevien vaatimusten täyttämiseksi korvaamalla estettyjen verkkoresurssien IP-osoitteita koskevat oikeat DNS-vastaukset tyngäsivuja sisältävän palvelimensa IP-osoitteella (seurauksena sellaiset sivustot huomattavasti monimutkaisempia) tai suodatuksen suorittavan välityspalvelimesi osoitteeseen.

Tämän pitäisi olla kuva sivustolta. http://1.1.1.1/, jota käytetään kuvaamaan yhteyttä palveluun. Kirjoittajat näyttävät olevan melko varmoja DNS-palvelunsa laadusta (Cloudflarelta on kuitenkin vaikea odottaa mitään muuta):

Palvelun luojaa Cloudflarea voi ymmärtää täysin: he ansaitsevat leipäänsä ylläpitämällä ja kehittämällä yhtä maailman suosituimmista CDN-verkoista (johon toimintoihin kuuluu paitsi sisällön jakelu myös DNS-vyöhykkeiden isännöinti), ja johtuen niiden halu, joka ei ole hyvin perehtynyt, opeta ne joita he eivät tunne, sille minne mennä globaalissa verkossa kärsii melko usein palvelimiensa osoitteiden estämisestä älkäämme sanoko kuka - DNS, johon ei vaikuta "huudot, pillit ja kirjoitukset" yritykselle merkitsee vähemmän haittaa heidän liiketoiminnalleen. Ja tekniset edut (pikku juttu, mutta mukavaa: erityisesti ilmaisen DNS Cloudflaren asiakkaille yrityksen DNS-palvelimilla isännöityjen resurssien DNS-tietueiden päivittäminen on välitöntä) tekevät viestissä kuvatun palvelun käytöstä entistä mielenkiintoisemman.

Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. Kirjaudu sisään, ole kiltti.

Käytätkö uutta palvelua?

• Kyllä, yksinkertaisesti määrittämällä se käyttöjärjestelmässä ja/tai reitittimessä

• Kyllä, ja käytän uusia protokollia (DNS HTTP:n yli ja DNS TLS:n kautta)

• Ei, minulla on tarpeeksi nykyisiä palvelimia (tämä on julkinen palveluntarjoaja: Google, Yandex jne.)

• Ei, en edes tiedä mitä käytän juuri nyt

• Käytän rekursiivista DNS:täni SSL-tunnelin kanssa

693 käyttäjää äänesti. 191 käyttäjä pidättyi äänestämästä.

Lähde: will.com