Cloudflare cég nyilvános DNS a következő címeken:
- 1.1.1.1
- 1.0.0.1
- 2606: 4700: 4700 :: 1111
- 2606: 4700: 4700 :: 1001
Azt állítják, hogy az „Adatvédelem mindenekelőtt” irányelvet alkalmazzák, így a felhasználók megnyugodhatnak kérelmeik tartalmát illetően.
A szolgáltatás azért érdekes, mert a megszokott DNS mellett technológiák használatára is lehetőséget ad DNS-over-TLS и DNS-HTTPS felett, ami nagymértékben megakadályozza, hogy a szolgáltatók lehallgathassák az Ön kéréseit a kérés útján – és statisztikákat gyűjtsenek, figyeljenek és kezeljenek hirdetéseket. A Cloudflare azt állítja, hogy a bejelentés dátumát (1. április 2018. vagy amerikai jelöléssel 04. 01.) nem véletlenül választották: az év melyik másik napján mutatják be a „négy egységet”?
Mivel Habr közönsége technikailag hozzáértő, a hagyományos „miért van szükségünk a DNS-re?” szakasz. A poszt végére teszem, itt pedig felvázolok még gyakorlatilag hasznos dolgokat:
Hogyan kell használni az új szolgáltatást?
A legegyszerűbb, ha megadja a fenti DNS-kiszolgáló címeit a DNS-kliensben (vagy upstreamként a használt helyi DNS-kiszolgáló beállításaiban). Van értelme a megszokott értékeket lecserélni? (8.8.8.8 stb.), vagy valamivel kevésbé gyakori (77.88.8.8 és hasonlók) a Cloudflare szervereire – ők döntenek helyetted, de ez egy kezdőért beszél válaszok sebessége, amely szerint a Cloudflare gyorsabban működik, mint az összes versenytárs (világosítom: a méréseket harmadik féltől származó szolgáltatás végezte, és az adott ügyfél sebessége természetesen eltérő lehet).
Sokkal érdekesebb olyan új módokkal dolgozni, amelyekben a kérés titkosított kapcsolaton keresztül repül a szerverhez (sőt, a válasz is ezen keresztül érkezik vissza), az említett DNS-over-TLS és DNS-over-HTTPS. Sajnos ezek nem támogatottak (a szerzők úgy vélik, hogy ez „még”), de munkájuk megszervezése a szoftverben (vagy akár a hardveren) nem nehéz:
DNS HTTP-n keresztül (DoH)
Ahogy a neve is sugallja, a kommunikáció HTTPS-csatornán keresztül történik, ami azt is jelenti
- leszállási pont (végpont) jelenléte - a helyen található És
- olyan ügyfél, aki kéréseket küldhet és válaszokat kaphat.
A kérések a következőben meghatározott DNS-vezetékes formátumban lehetnek (a POST és GET HTTP metódusokkal küldve), vagy JSON formátumban (a GET HTTP metódussal). Személy szerint számomra váratlannak tűnt a DNS-lekérdezések HTTP-kéréseken keresztüli létrehozásának gondolata, de van benne egy racionális elem: egy ilyen kérés sok forgalomszűrő rendszeren átmegy, a válaszok elemzése meglehetősen egyszerű, a kérések generálása pedig még egyszerűbb. A biztonságért az ismerős könyvtárak és protokollok felelnek.
Példa lekérdezések, közvetlenül a dokumentációból:
GET kérés DNS Wireformat formátumban
$ 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
0000031POST-kérés DNS vezetékes formátumban
$ 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
Ugyanaz, csak JSON használatával
$ 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"
}
]
}Nyilvánvalóan kevés otthoni router tud így működni (ha van ilyen) DNS-sel, de ez nem jelenti azt, hogy holnap ne jelenne meg a támogatás – és érdekes módon itt könnyedén megvalósíthatjuk a DNS-sel való munkát az alkalmazásunkban (ahogyan már , csak a Cloudflare szervereken).
DNS TLS-en keresztül
Alapértelmezés szerint a DNS-lekérdezések titkosítás nélkül kerülnek elküldésre. A TLS-n keresztüli DNS egy módja annak, hogy biztonságos kapcsolaton keresztül küldje el őket. A Cloudflare az előírásoknak megfelelően támogatja a DNS-t TLS-n keresztül a szabványos 853-as porton . Ez a cloudflare-dns.com gazdagéphez kiadott tanúsítványt használ, a TLS 1.2 és TLS 1.3 támogatott.
A kapcsolat létrehozása és a protokollal való munka a következőképpen zajlik:
- A DNS-kapcsolat létrehozása előtt az ügyfél eltárolja a cloudflare-dns.com TLS-tanúsítványának base64 kódolású SHA256 hash-jét (úgynevezett SPKI-t).
- A DNS-ügyfél TCP-kapcsolatot hoz létre a cloudflare-dns.com:853 webhelyhez
- A DNS-ügyfél elindítja a TLS-kézfogási eljárást
- A TLS-kézfogás során a cloudflare-dns.com gazdagép bemutatja TLS-tanúsítványát.
- A TLS-kapcsolat létrehozása után a DNS-kliens biztonságos csatornán keresztül küldhet DNS-lekérdezéseket, ami megakadályozza a lehallgatást és a kérések és válaszok hamisítását.
- Minden TLS-kapcsolaton keresztül küldött DNS-kérelemnek meg kell felelnie a specifikációnak .
Példa egy kérésre DNS-en keresztül TLS-en keresztül:
$ 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Úgy tűnik, hogy ez az opció jobban megfelel a helyi DNS-kiszolgálóknak, amelyek helyi hálózat vagy egyetlen felhasználó igényeit szolgálják ki. Igaz, a szabvány támogatottsága nem túl jó, de reménykedjünk!
Két szó magyarázat arra, amiről beszélünk
A DNS rövidítés a Domain Name Service (Domainnév-szolgáltatás) rövidítése (tehát a „DNS-szolgáltatás” kifejezés némileg redundáns; a mozaikszó már tartalmazza a „szolgáltatás” szót), és egy egyszerű feladat megoldására szolgál – egy adott gazdagépnév IP-címének megértésére. Valahányszor egy személy rákattint egy linkre, vagy beír egy címet a böngésző címsorába (pl."), egy személy számítógépe megpróbálja kitalálni, hogy melyik szerverre küldjön kérést egy oldal tartalmának fogadására. A habrahabr.ru esetében a DNS válasza tartalmazza a webszerver IP-címének jelzését: 178.248.237.68, majd a böngésző megpróbál kapcsolatba lépni a szerverrel a megadott IP-címmel.
A DNS-kiszolgáló viszont, miután megkapta a „mi a habrahabr.ru nevű gazdagép IP-címe?” kérést, megállapítja, hogy tud-e valamit a megadott gazdagépről. Ha nem, akkor lekérdezi a világ többi DNS-kiszolgálóját, és lépésről lépésre megpróbálja kitalálni a választ a feltett kérdésre. Ennek eredményeként a végső válasz megtalálásakor a talált adatok elküldésre kerülnek a még várakozó kliensnek, valamint magának a DNS-kiszolgálónak a gyorsítótárában tárolódnak, ami lehetővé teszi, hogy legközelebb sokkal gyorsabban válaszoljon egy hasonló kérdésre.
Gyakori probléma, hogy először is a DNS-lekérdezési adatok törlésben kerülnek elküldésre (amivel bárki, aki hozzáfér a forgalmi adatfolyamhoz, elkülönítse a DNS-lekérdezéseket és a kapott válaszokat, majd elemezze őket saját céljaira; ez lehetővé teszi a hogy pontosan célozza meg a hirdetéseket a DNS-kliens számára, és ez elég sok!). Másodszor, egyes internetszolgáltatók (nem fogunk ujjal mutogatni, de a legkisebbek sem) hajlamosak hirdetést megjeleníteni egy-egy kért oldal helyett (ami nagyon egyszerűen megvalósítható: a megadott IP-cím helyett a gazdagépnév kérésére habranabr.ru egy véletlenszerű személynek Ily módon a szolgáltató webszerverének címe kerül visszaadásra, ahol a hirdetést tartalmazó oldalt kiszolgálják). Harmadszor, vannak olyan internet-hozzáférési szolgáltatók, amelyek olyan mechanizmust valósítanak meg az egyes webhelyek blokkolására vonatkozó követelmények teljesítésére, amelyek a blokkolt webes erőforrások IP-címére vonatkozó helyes DNS-válaszokat a csonkoldalakat tartalmazó szerverük IP-címére cserélik (ennek eredményeként a az ilyen webhelyek észrevehetően bonyolultabbá válnak), vagy a szűrést végző proxyszerver címére.
Valószínűleg ide kellene tenni egy képet a honlapról , amely a szolgáltatáshoz való kapcsolódás leírására szolgál. A szerzők láthatóan teljesen biztosak DNS-ük minőségében (a Cloudflare-től azonban nehéz mást várni):
Teljesen érthető a Cloudflare, a szolgáltatás létrehozója: a világ egyik legnépszerűbb CDN-hálózatának támogatásával és fejlesztésével keresik kenyerüket (amelynek funkciói közé nem csak a tartalomterjesztés, hanem a DNS-zónák hosztolása is tartozik), ill. azok vágya miatt, aki nem sokat tud, tanítsd meg azokat akiket nem ismernek, ahhoz hová menjen a globális hálózaton gyakran szenved a szervercímek blokkolása miatt nem mondjuk ki - így egy olyan DNS-sel, amelyet nem befolyásolnak a „kiáltások, füttyök és firkálások”, kevesebb kárt okoz a vállalkozásnak egy vállalat számára. A technikai előnyök pedig (apróság, de szép: különösen az ingyenes DNS Cloudflare ügyfelei számára a cég DNS szerverein tárolt erőforrások DNS rekordjainak frissítése azonnali lesz) még érdekesebbé teszik a bejegyzésben leírt szolgáltatás használatát. .
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Használja majd az új szolgáltatást?
-
Igen, csak az operációs rendszerben és/vagy az útválasztón megadva
-
Igen, és új protokollokat fogok használni (DNS HTTP-n keresztül és DNS TLS-n keresztül)
-
Nem, van elég jelenlegi szerverem (ez egy nyilvános szolgáltató: Google, Yandex stb.)
-
Nem, nem is tudom, mit használok most
-
Saját rekurzív DNS-t használok, előttük egy SSL alagúttal
693 felhasználó szavazott. 191 felhasználó tartózkodott.
Forrás: will.com