Cloudflare-ren zerbitzua 1.1.1.1 eta 1.0.0.1 helbideetan aurkitzen dugu, edo "DNS apalategi publikoa iritsi da!"

Cloudflare konpainia aurkeztu DNS publikoa helbideetan:

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

Politika "Pribatutasuna lehenik" dela esaten da, erabiltzaileek beren eskaeren edukiari buruz lasaitasuna izan dezaten.

Zerbitzua interesgarria da, ohiko DNSaz gain, teknologiak erabiltzeko gaitasuna ematen duelako DNS-gaineko TLS и DNS-gaineko HTTPS, eta horrek asko eragotziko du hornitzaileek zure eskaerak entzutea eskaeren bidean zehar - eta estatistikak bildu, kontrolatu, publizitatea kudeatu. Cloudflare-k dio iragarpenaren data (1ko apirilaren 2018a edo 04/01 idazkera amerikarrean) ez zela kasualitatez aukeratu: urteko zein beste egun aurkeztuko dira "lau unitateak"?

Habr-en audientzia teknikoki aditua denez, "zergatik behar duzu DNS?" atal tradizionala. Postaren amaieran jarriko dut, baina hemen gauza praktikoago erabilgarriagoak adieraziko ditut:

Nola erabili zerbitzu berria?

Gauzarik errazena goiko DNS zerbitzariaren helbideak zure DNS bezeroan zehaztea da (edo erabiltzen duzun tokiko DNS zerbitzariaren ezarpenetan goranzko moduan). Ba al du zentzurik ohiko balioak ordezkatzeak Google DNS (8.8.8.8, etab.), edo apur bat gutxiago arrunta Yandex DNS zerbitzari publikoak (77.88.8.8 eta antzeko beste batzuk) Cloudflare-ko zerbitzarietara - zuk erabakiko dute, baina hasiberri baten alde hitz egiten du ordutegi erantzun-abiadura, eta horren arabera, Cloudflare lehiakide guztiak baino azkarragoa da (argituko dut: neurketak hirugarrenen zerbitzu batek hartu ditu, eta bezero zehatz bati egindako abiadura, noski, desberdina izan daiteke).

Askoz interesgarriagoa da eskaera enkriptatutako konexio baten bidez zerbitzarira hegan egiten duen modu berriekin lan egitea (hain zuzen ere, erantzuna horren bidez itzultzen da), aipatutako DNS-over-TLS eta DNS-over-HTTPS. Zoritxarrez, ez dira "kutxatik kanpo" onartzen (egileek uste dute hori "oraindik"), baina ez da zaila zure softwarean (edo zure hardwarean) antolatzea:

DNS HTTP bidez (DoH)

Izenak dioen bezala, komunikazioa HTTPS kanal baten bidez egiten da, hau da

1. lurreratzeko puntu baten presentzia (amaiera) - helbidean dago https://cloudflare-dns.com/dns-queryEta
2. eskaerak bidali eta erantzunak jaso ditzakeen bezeroa.

Eskaerak atalean zehaztutako DNS Wireformat formatuan egon daitezke RFC1035 (POST eta GET HTTP metodoak erabiliz bidalita), edo JSON formatuan (GET HTTP metodoa erabiliz). Niri pertsonalki, DNS eskaerak HTTP eskaeren bidez egitearen ideia ez zen ustekabekoa iruditu zitzaidan, baina arrazional bat dago horretan: eskaera horrek trafikoa iragazteko sistema asko gaindituko ditu, erantzunak analizatzea nahiko erraza da eta eskaerak sortzea are errazagoa da. Ohiko liburutegiak eta protokoloak segurtasunaz arduratzen dira.

Eskatu adibideak, dokumentaziotik zuzenean:

GET eskaera DNS Wireformat formatuan

$ 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 eskaera DNS Wireformat formatuan

$ 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

Berdin baina JSON erabiliz

$ 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"
    }
  ]
}

Jakina, etxeko bideratzaile arraro batek (gutxienez bat bada) DNSrekin lan egin dezake modu honetan, baina horrek ez du esan nahi bihar euskarria agertuko ez denik - eta, interesgarria dena, hemen nahiko inplementatu dezakegu DNS-ekin lan egitea gure aplikazioan (dagoeneko bezala). Mozilla egitera joango da, Cloudflare zerbitzarietan bakarrik).

DNS TLS bidez

Lehenespenez, DNS kontsultak zifratu gabe transmititzen dira. TLS bidezko DNS konexio seguru baten bidez bidaltzeko modu bat da. Cloudflare-k DNS onartzen du TLS bidez 853 ataka estandarrean agindu bezala RFC7858. Honek cloudflare-dns.com ostalariarentzat emandako ziurtagiri bat erabiltzen du, TLS 1.2 eta TLS 1.3 onartzen dira.

Konexio bat ezartzea eta protokoloaren arabera lan egitea honelakoa da:

• DNS konexioa ezarri aurretik, bezeroak cloudflare-dns.com-en TLS ziurtagiriaren base64 kodetutako SHA256 hash bat gordetzen du (SPKI izenekoa)
• DNS bezeroak TCP konexioa ezartzen du cloudflare-dns.com:853
• DNS bezeroak TLS esku-ematea abiarazten du
• TLS handshake prozesuan, cloudflare-dns.com ostalariak bere TLS ziurtagiria aurkezten du.
• TLS konexioa ezarri ondoren, DNS bezeroak DNS kontsultak bidal ditzake kanal seguru baten bidez, eta horrek eskaerak eta erantzunak entzun eta faltsutzea eragozten du.
• TLS konexio baten bidez bidalitako DNS kontsulta guztiek bete behar dute DNS TCP bidez bidaltzen.

TLS bidez DNS bidez egindako eskaeraren adibide bat:

$ 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

Aukera honek onena funtzionatzen duela dirudi sare lokal baten edo erabiltzaile bakar baten beharrak betetzen dituzten DNS zerbitzari lokaletarako. Egia da, estandarraren laguntzarekin ez da oso ona, baina - espero dezagun!

Elkarrizketa zer den azaltzeko bi hitz

DNS laburdurak Domeinu-izenen Zerbitzua esan nahi du (beraz, "DNS zerbitzua" esatea apur bat erredundantea da, laburdurak dagoeneko "zerbitzua" hitza dauka), eta zeregin sinple bat konpontzeko erabiltzen da: ostalari-izen jakin batek zer IP helbidea duen ulertzeko. Pertsona batek esteka batean klik egiten duen bakoitzean edo nabigatzailearen helbide-barran helbide bat sartzen duen bakoitzean (esan, "https://habrahabr.ru/post/346430/"), giza ordenagailua orriaren edukia lortzeko eskaera bat zein zerbitzari bidali behar duen asmatzen saiatzen ari da. habrahabr.ru-ren kasuan, DNS-ren erantzunak web zerbitzariaren IP helbidearen adierazpena izango du: 178.248.237.68, eta orduan arakatzailea dagoeneko saiatuko da zerbitzariarekin harremanetan jartzen zehaztutako IP helbidearekin.

Aldiz, DNS zerbitzariak, "zein da habrahabr.ru izeneko ostalariaren IP helbidea?" eskaera jaso ondoren, zehaztutako ostalariari buruz zerbait dakien ala ez zehazten du. Hala ez bada, munduko beste DNS zerbitzariei eskaera bat egiten die, eta, urratsez urrats, egindako galderaren erantzuna asmatzen saiatzen da. Ondorioz, azken erantzuna aurkitzean, aurkitutako datuak oraindik zain dagoen bezeroari bidaltzen zaizkio, gainera DNS zerbitzariaren beraren cachean gordetzen dira, hurrengoan antzeko galdera bati askoz azkarrago erantzuteko aukera emango dizuna.

Arazo arrunt bat da, lehenik eta behin, DNS kontsultaren datuak argi eta garbi transmititzen direla (horrek trafiko-fluxurako sarbidea duen edonori ahalmena ematen dio DNS kontsultak eta jasotzen dituen erantzunak isolatzeko eta gero bere helburuetarako analizatzeko; horrek ematen du. DNS bezero bati iragarkiak zehaztasunez bideratzeko gaitasuna, hau da, asko!). Bigarrenik, ISP batzuek (ez ditugu hatzaz adieraziko, baina ez txikienak) eskatutako orriren baten edo besteren ordez iragarkiak erakusteko joera dute (oso sinplean ezartzen dena: habranabr.ru-k kontsulta baterako zehaztutako IP helbidearen ordez. ostalari-izena, ausazko pertsona bat Horrela, hornitzailearen web zerbitzariaren helbidea itzultzen da, non iragarkia duen orria hornitzen den). Hirugarrenik, webgune indibidualak blokeatzeko baldintzak betetzeko mekanismo bat ezartzen duten Interneteko sarbide hornitzaileak daude, blokeatutako web-baliabideen IP helbideei buruzko DNS erantzun zuzenak ordezkatuz euren zerbitzariaren IP helbidea zirriborro-orriekin (ondorioz, sarbidea. horrelako guneak nabarmen konplikatuagoak), edo iragazketa egiten duen proxy zerbitzariaren helbidera.

Hau ziurrenik guneko argazki bat izan beharko litzateke. http://1.1.1.1/, zerbitzuarekiko konexioa deskribatzeko erabiltzen da. Badirudi egileek nahiko ziur daudela beren DNSaren kalitatean (hala ere, zaila da Cloudflaretik beste ezer espero izatea):

Ondo uler daiteke Cloudflare, zerbitzuaren sortzailea: munduko CDN sare ezagunenetako bat mantenduz eta garatuz irabazten dute bere ogia (funtzio horien artean edukia banatzeaz gain, DNS eremuak ostatzea ere barne hartzen dute), eta, ondorioz. horien nahia, ondo ezagutzen ez duena, irakatsi horiek ezagutzen ez dutena, horretara nora joan sare globalean, sarritan jasaten du bere zerbitzarien helbideak blokeatzea ez dezagun esan nor - beraz, enpresarentzat "oihu, txistu eta zirriborrak" eragiten ez duen DNS bat izateak kalte gutxiago dakar bere negozioarentzat. Eta abantaila teknikoek (txikikeria bat, baina polita: batez ere, doako DNS Cloudflare-ren bezeroentzat, konpainiaren DNS zerbitzarietan ostatatutako baliabideen DNS erregistroak eguneratzea berehalakoa izango da) argitalpenean deskribatutako zerbitzua erabiltzea are interesgarriago bihurtzen dute.

Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. Hasi saioa, mesedez.

Zerbitzu berria erabiliko duzu?

• Bai, sistema eragilean eta/edo bideratzailean zehaztu besterik ez dago

• Bai, eta protokolo berriak erabiliko ditut (DNS HTTP bidez eta DNS TLS bidez)

• Ez, uneko nahikoa zerbitzari ditut (hornitzaile publikoa da: Google, Yandex, etab.)

• Ez, ez dakit zer erabiltzen ari naizen ere

• Nire DNS errekurtsiboa erabiltzen dut SSL tunel batekin

693 erabiltzailek eman dute botoa. Erabiltzaile 191 abstenitu egin zen.

Iturria: www.habr.com