Ni renkontas la servon de Cloudflare ĉe adresoj 1.1.1.1 kaj 1.0.0.1, aŭ "la publika DNS-breto alvenis!"

Cloudflare Kompanio prezentita publika DNS ĉe adresoj:

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

La politiko laŭdire estas "Privateco unue" por ke uzantoj povu havi trankvilon pri la enhavo de siaj petoj.

La servo estas interesa en tio, ke, krom la kutima DNS, ĝi disponigas la kapablon uzi teknologiojn DNS-super-TLS и DNS-super-HTTPS, kiu multe malhelpos provizantoj subaŭskulti viajn petojn laŭ la vojo de petoj - kaj kolekti statistikojn, monitori, administri reklamadon. Cloudflare asertas, ke la dato de la anonco (aprilo 1, 2018, aŭ 04/01 en usona skribmaniero) ne estis hazarde elektita: kiu alia tago de la jaro estos prezentitaj la "kvar unuoj"?

Ĉar la publiko de Habr estas teknike sagaca, la tradicia sekcio "kial vi bezonas DNS?" Mi metos ĝin ĉe la fino de la afiŝo, sed ĉi tie mi deklaros pli praktike utilajn aferojn:

Kiel uzi la novan servon?

La plej simpla afero estas specifi la suprajn adresojn de DNS-servilo en via DNS-kliento (aŭ kiel kontraŭflue en la agordoj de la loka DNS-servilo, kiun vi uzas). Ĉu havas sencon anstataŭigi la kutimajn valorojn Google DNS (8.8.8.8, ktp.), aŭ iomete malpli ofta Yandex-publikaj DNS-serviloj (77.88.8.8 kaj aliaj kiel ili) al la serviloj de Cloudflare - ili decidos por vi, sed parolas por komencanto horaro respondrapideco, laŭ kiu Cloudflare estas pli rapida ol ĉiuj konkurantoj (mi klarigos: la mezuradoj estis faritaj de triaparta servo, kaj la rapideco al specifa kliento, kompreneble, povas malsami).

Estas multe pli interese labori kun novaj reĝimoj, en kiuj la peto flugas al la servilo per ĉifrita konekto (fakte, la respondo estas resendita per ĝi), la menciitaj DNS-over-TLS kaj DNS-over-HTTPS. Bedaŭrinde, ili ne estas subtenataj "el la skatolo" (la aŭtoroj kredas, ke tio estas "ankoraŭ"), sed ne estas malfacile organizi sian laboron en via programaro (aŭ eĉ sur via aparataro):

DNS super HTTPs (DoH)

Kiel la nomo sugestas, komunikado okazas per HTTPS-kanalo, kio signifas

1. la ĉeesto de surteriĝopunkto (finpunkto) - ĝi situas ĉe la adreso https://cloudflare-dns.com/dns-querykaj
2. kliento kiu povas sendi petojn kaj ricevi respondojn.

Petoj povas aŭ esti en la DNS Wireformat-formato difinita en RFC1035 (senditaj per la POST kaj GET HTTP-metodoj), aŭ en JSON-formato (uzante la GET HTTP-metodon). Por mi persone, la ideo fari DNS-petojn per HTTP-petoj ŝajnis neatendita, sed estas racia grajno en ĝi: tia peto trapasos multajn trafikajn filtrilsistemojn, analizi respondojn estas sufiĉe simpla, kaj generi petojn estas eĉ pli facila. La kutimaj bibliotekoj kaj protokoloj respondecas pri sekureco.

Petu ekzemplojn, rekte el la dokumentaro:

GET peto en DNS Wireformat formato

$ 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-peto en DNS Wireformat-formato

$ 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

Same sed uzante JSON

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

Estas evidente, ke malofta (se almenaŭ unu) hejma enkursigilo povas funkcii kun DNS tiamaniere, sed tio ne signifas, ke subteno ne aperos morgaŭ - kaj, interese, ĉi tie ni povas tute efektivigi laboradon kun DNS en nia. aplikaĵo (kiel jam tuj faros Mozilon, nur sur Cloudflare-serviloj).

DNS super TLS

Defaŭlte, DNS-demandoj estas elsenditaj sen ĉifrado. DNS super TLS estas maniero sendi ilin per sekura konekto. Cloudflare subtenas DNS super TLS sur norma haveno 853 kiel preskribite RFC7858. Ĉi tio uzas atestilon eldonitan por la gastiganto cloudflare-dns.com, TLS 1.2 kaj TLS 1.3 estas subtenataj.

Establi konekton kaj labori laŭ la protokolo iras kiel ĉi tio:

• Antaŭ establi DNS-konekton, la kliento stokas base64-kodigitan SHA256-haŝiŝon de la TLS-atestilo de cloudflare-dns.com (nomita SPKI)
• DNS-kliento establas TCP-konekton al cloudflare-dns.com:853
• DNS-kliento iniciatas TLS-manpremon
• Dum la TLS-manpremprocezo, la gastiganto de cloudflare-dns.com prezentas sian TLS-atestilon.
• Post kiam TLS-konekto estas establita, la DNS-kliento povas sendi DNS-petojn per sekura kanalo, kiu malhelpas petojn kaj respondojn esti subaŭskultitaj kaj falsitaj.
• Ĉiuj DNS-demandoj senditaj per TLS-konekto devas konformi al la sendante DNS super TCP.

Ekzemplo de peto per DNS super TLS:

$ 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

Ĉi tiu opcio ŝajnas funkcii plej bone por lokaj DNS-serviloj servantaj la bezonojn de loka reto aŭ ununura uzanto. Vere, kun la subteno de la normo ne estas tre bona, sed - ni esperu!

Du vortoj de klarigo pri kio temas la konversacio

La mallongigo DNS signifas Domain Name Service (do diri "DNS-servo" estas iom superflua, la mallongigo jam enhavas la vorton "servo"), kaj estas uzata por solvi simplan taskon - por kompreni kian IP-adreson havas aparta gastiga nomo. Ĉiufoje kiam persono alklakas ligon aŭ enmetas adreson en la adresbreto de la retumilo (ekzemple, io kiel "https://habrahabr.ru/post/346430/"), la homa komputilo provas eltrovi kiun servilon sendi peton por ricevi la enhavon de la paĝo. En la kazo de habrahabr.ru, la respondo de DNS enhavos indikon pri la IP-adreso de la retservilo: 178.248.237.68, kaj tiam la retumilo jam provos kontakti la servilon kun la specifita IP-adreso.

Siavice, la DNS-servilo, ricevinte la peton "kio estas la IP-adreso de la gastiganto nomata habrahabr.ru?", determinas ĉu ĝi scias ion pri la specifita gastiganto. Se ne, ĝi faras peton al aliaj DNS-serviloj en la mondo, kaj, paŝo post paŝo, provas eltrovi la respondon al la demandita demando. Kiel rezulto, trovinte la finan respondon, la trovitaj datumoj estas senditaj al la kliento ankoraŭ atendanta ilin, krome ĝi estas konservita en la kaŝmemoro de la DNS-servilo mem, kio permesos al vi respondi similan demandon multe pli rapide venontfoje.

Ofta problemo estas ke, unue, la DNS-demanddatenoj estas elsenditaj en klara (kiu donas al iu ajn kun aliro al la trafikfluo la kapablon izoli la DNS-demandojn kaj la respondojn kiujn ili ricevas kaj poste analizi ilin por siaj propraj celoj; tio donas la kapablo celi reklamojn kun precizeco por DNS-kliento, kio estas sufiĉe multe!). Due, iuj ISP-oj (ni ne montros fingrojn, sed ne la plej malgrandajn) emas montri reklamojn anstataŭ unu aŭ alia petita paĝo (kiu estas efektivigata tute simple: anstataŭ la specifita IP-adreso por demando de la habranabr.ru). gastiga nomo, hazarda persono Tiel, la adreso de la retservilo de la provizanto estas resendita, kie la paĝo enhavanta la reklamon estas servata). Trie, ekzistas provizantoj de Interreta aliro, kiuj efektivigas mekanismon por plenumi la postulojn por blokado de individuaj retejoj anstataŭigante la ĝustajn DNS-respondojn pri la IP-adresoj de blokitaj retresursoj per la IP-adreso de sia servilo enhavanta stumppaĝojn (kiel rezulto, aliro al tiaj retejoj rimarkeble pli komplikaj), aŭ al la adreso de via prokura servilo, kiu plenumas filtradon.

Ĉi tio verŝajne estu bildo de la retejo. http://1.1.1.1/, uzata por priskribi la konekton al la servo. La verkintoj ŝajnas esti sufiĉe certaj pri la kvalito de sia DNS (tamen, estas malfacile atendi ion alian de Cloudflare):

Oni povas plene kompreni Cloudflare, la kreinton de la servo: ili gajnas sian panon konservante kaj disvolvante unu el la plej popularaj CDN-retoj en la mondo (kiuj funkcioj inkluzivas ne nur distribuadon de enhavo, sed ankaŭ gastigadon de DNS-zonoj), kaj, pro la deziro de tiuj, kiu ne estas bone sperta, instruu tiujn kiujn ili ne konas, al tio kien iri en la tutmonda reto, sufiĉe ofte suferas de blokado de la adresoj de siaj serviloj de ni ne diru kiu - do havi DNS kiu ne estas tuŝita de "krioj, fajfoj kaj skribaĉoj" por la firmao signifas malpli da damaĝo al ilia komerco. Kaj teknikaj avantaĝoj (malgravaj, sed belaj: precipe por klientoj de la senpaga DNS Cloudflare, ĝisdatigi la DNS-rekordojn de rimedoj gastigitaj en la DNS-serviloj de la kompanio estos tuja) igas uzi la servon priskribitan en la afiŝo eĉ pli interesa.

Nur registritaj uzantoj povas partopreni la enketon. Ensaluti, bonvolu.

Ĉu vi uzos la novan servon?

• Jes, simple specifante ĝin en la OS kaj/aŭ sur la enkursigilo

• Jes, kaj mi uzos novajn protokolojn (DNS per HTTPs kaj DNS per TLS)

• Ne, mi havas sufiĉe da nunaj serviloj (ĉi tio estas publika provizanto: Google, Yandex, ktp.)

• Ne, mi eĉ ne scias, kion mi uzas nun

• Mi uzas mian rekursivan DNS kun SSL-tunelo al ili

693 uzantoj voĉdonis. 191 uzanto sindetenis.

fonto: www.habr.com