Ang iba't ibang aspeto ng pagpapatakbo ng DNS ay paulit-ulit na nahawakan ng may-akda sa ilang mga nai-publish bilang bahagi ng blog. Kasabay nito, ang pangunahing diin ay palaging sa pagpapabuti ng seguridad ng pangunahing serbisyo sa Internet na ito.
Hanggang kamakailan, sa kabila ng halatang kahinaan ng trapiko ng DNS, na sa karamihan, ay ipinadala sa malinaw, sa mga nakakahamak na aksyon sa bahagi ng mga provider na naglalayong pataasin ang kanilang kita sa pamamagitan ng pag-embed ng advertising sa nilalaman, mga ahensya ng seguridad ng gobyerno at censorship, pati mga kriminal lang, ang proseso , sa kabila ng pagkakaroon ng iba't ibang teknolohiya tulad ng DNSSEC/DANE, DNScrypt, DNS-over-TLS at DNS-over-HTTPS, ay natigil. At kung ang mga solusyon sa server, at ang ilan sa mga ito ay umiral na sa loob ng mahabang panahon, ay malawak na kilala at magagamit, ang kanilang suporta mula sa software ng kliyente ay nag-iiwan ng maraming kailangan.
Sa kabutihang palad, nagbabago ang sitwasyon. Sa partikular, ang mga developer ng sikat na Firefox browser tungkol sa mga planong paganahin ang mode ng suporta bilang default (DoH) sa lalong madaling panahon. Dapat itong makatulong na protektahan ang trapiko ng DNS ng gumagamit ng WWW mula sa mga banta sa itaas, ngunit maaaring magpakilala ng mga bago.
1. Mga problema sa DNS-over-HTTPS
Sa unang sulyap, ang simula ng malawakang pagpapakilala ng DNS-over-HTTPS sa Internet software ay nagdudulot lamang ng positibong reaksyon. Gayunpaman, ang diyablo, tulad ng sinasabi nila, ay nasa mga detalye.
Ang unang problema na naglilimita sa saklaw ng malawakang paggamit ng DoH ay ang pagtutok lamang nito sa trapiko sa web. Sa katunayan, ang HTTP protocol at ang kasalukuyang bersyon nito na HTTP/2, kung saan nakabatay ang DoH, ang batayan ng WWW. Ngunit ang Internet ay hindi lamang web. Maraming sikat na serbisyo, tulad ng email, iba't ibang instant messenger, file transfer system, multimedia streaming, atbp., na hindi gumagamit ng HTTP. Kaya, sa kabila ng pang-unawa ng marami sa DoH bilang isang panlunas sa lahat, lumalabas na hindi ito naaangkop nang walang karagdagang (at hindi kinakailangang) pagsisikap para sa anumang bagay maliban sa mga teknolohiya ng browser. Sa pamamagitan ng paraan, ang DNS-over-TLS ay mukhang isang mas karapat-dapat na kandidato para sa tungkuling ito, na nagpapatupad ng encapsulation ng karaniwang trapiko ng DNS sa secure na karaniwang TLS protocol.
Ang pangalawang problema, na posibleng mas makabuluhan kaysa sa una, ay ang aktwal na pag-abandona sa likas na desentralisasyon ng DNS ayon sa disenyo pabor sa paggamit ng isang server ng DoH na tinukoy sa mga setting ng browser. Sa partikular, iminumungkahi ng Mozilla ang paggamit ng isang serbisyo mula sa Cloudflare. Ang isang katulad na serbisyo ay inilunsad din ng iba pang mga kilalang numero sa Internet, sa partikular na Google. Lumalabas na ang pagpapatupad ng DNS-over-HTTPS sa anyo kung saan ito ay kasalukuyang iminungkahi ay nagpapataas lamang ng pagtitiwala ng mga end user sa pinakamalaking serbisyo. Hindi lihim na ang impormasyong maibibigay ng pagsusuri ng mga query sa DNS ay maaaring makakolekta ng higit pang data tungkol dito, pati na rin ang pagtaas ng katumpakan at kaugnayan nito.
Kaugnay nito, ang may-akda ay naging at nananatiling tagasuporta ng malawakang pagpapatupad hindi ng DNS-over-HTTPS, ngunit ng DNS-over-TLS kasama ang DNSSEC/DANE bilang isang unibersal, ligtas at hindi nakakatulong sa higit pang sentralisasyon ng paraan ng Internet para sa pagtiyak ng seguridad ng trapiko ng DNS. Sa kasamaang palad, para sa malinaw na mga kadahilanan, hindi maaaring asahan ang isang mabilis na pagpapakilala ng mass support para sa mga alternatibong DoH sa software ng kliyente, at ito pa rin ang domain ng mga mahilig sa teknolohiya ng seguridad.
Ngunit dahil mayroon na tayong DoH, bakit hindi ito gamitin pagkatapos makatakas sa potensyal na pagsubaybay ng mga korporasyon sa pamamagitan ng kanilang mga server sa sarili nating DNS-over-HTTPS server?
2. DNS-over-HTTPS protocol
Kung titingnan mo ang pamantayan na naglalarawan sa DNS-over-HTTPS protocol, makikita mo na ito ay, sa katunayan, isang web API na nagbibigay-daan sa iyong i-encapsulate ang isang karaniwang DNS package sa HTTP/2 protocol. Ito ay ipinatupad sa pamamagitan ng mga espesyal na HTTP header, pati na rin ang conversion ng binary na format ng ipinadalang data ng DNS (tingnan ang. at kasunod na mga dokumento) sa isang form na nagbibigay-daan sa iyong ipadala at matanggap ang mga ito, pati na rin magtrabaho kasama ang kinakailangang metadata.
Ayon sa pamantayan, HTTP/2 lang at secure na TLS na koneksyon ang sinusuportahan.
Ang pagpapadala ng kahilingan sa DNS ay maaaring gawin gamit ang karaniwang GET at POST na pamamaraan. Sa unang kaso, ang kahilingan ay binago sa base64URL-encoded string, at sa pangalawa, sa pamamagitan ng katawan ng POST na kahilingan sa binary form. Sa kasong ito, ginagamit ang isang espesyal na uri ng data ng MIME sa panahon ng kahilingan at tugon ng DNS application/dns-message.
root@eprove:~ # curl -H 'accept: application/dns-message' 'https://my.domaint/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' -v
* Trying 2001:100:200:300::400:443...
* TCP_NODELAY set
* Connected to eprove.net (2001:100:200:300::400) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=my.domain
* start date: Jul 22 00:07:13 2019 GMT
* expire date: Oct 20 00:07:13 2019 GMT
* subjectAltName: host "my.domain" matched cert's "my.domain"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* 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 0x801441000)
> GET /dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE HTTP/2
> Host: eprove.net
> User-Agent: curl/7.65.3
> accept: application/dns-message
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< server: h2o/2.3.0-beta2
< content-type: application/dns-message
< cache-control: max-age=86274
< date: Thu, 12 Sep 2019 13:07:25 GMT
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< content-length: 45
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 45)
* stopped the pause stream!
* Connection #0 to host eprove.net left intactBigyang-pansin din ang pamagat kontrol ng cache: sa tugon mula sa web server. Sa parameter max-edad naglalaman ng halaga ng TTL para sa tala ng DNS na ibinabalik (o ang pinakamababang halaga kung ibinabalik ang isang hanay ng mga ito).
Batay sa itaas, ang paggana ng isang server ng DoH ay binubuo ng ilang mga yugto.
- Tumanggap ng kahilingan sa HTTP. Kung ito ay isang GET pagkatapos ay i-decode ang packet mula sa base64URL encoding.
- Ipadala ang packet na ito sa DNS server.
- Kumuha ng tugon mula sa DNS server
- Hanapin ang pinakamababang halaga ng TTL sa mga natanggap na tala.
- Magbalik ng tugon sa kliyente sa pamamagitan ng HTTP.
3. Ang iyong sariling DNS-over-HTTPS server
Ang pinakasimpleng, pinakamabilis at pinakaepektibong paraan upang patakbuhin ang iyong sariling DNS-over-HTTPS server ay ang paggamit ng HTTP/2 web server , tungkol sa kung saan naisulat na ng may-akda nang maikli (tingnan ang "").
Ang pagpipiliang ito ay sinusuportahan ng katotohanan na ang lahat ng code ng iyong sariling server ng DoH ay maaaring ganap na maipatupad gamit ang interpreter na isinama sa H2O mismo . Bilang karagdagan sa mga karaniwang aklatan, upang makipagpalitan ng data sa DNS server, kailangan mo ang (mrbgem) Socket library, na, sa kabutihang palad, ay kasama na sa kasalukuyang bersyon ng pag-unlad ng H2O 2.3.0-beta2 sa mga FreeBSD port. Gayunpaman, hindi mahirap idagdag ito sa anumang nakaraang bersyon sa pamamagitan ng pag-clone ng repositoryo sa catalog /deps bago ang compilation.
root@beta:~ # uname -v
FreeBSD 12.0-RELEASE-p10 GENERIC
root@beta:~ # cd /usr/ports/www/h2o
root@beta:/usr/ports/www/h2o # make extract
===> License MIT BSD2CLAUSE accepted by the user
===> h2o-2.2.6 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by h2o-2.2.6 for building
===> Extracting for h2o-2.2.6.
=> SHA256 Checksum OK for h2o-h2o-v2.2.6_GH0.tar.gz.
===> h2o-2.2.6 depends on file: /usr/local/bin/ruby26 - found
root@beta:/usr/ports/www/h2o # cd work/h2o-2.2.6/deps/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # git clone https://github.com/iij/mruby-socket.git
Клонирование в «mruby-socket»…
remote: Enumerating objects: 385, done.
remote: Total 385 (delta 0), reused 0 (delta 0), pack-reused 385
Получение объектов: 100% (385/385), 98.02 KiB | 647.00 KiB/s, готово.
Определение изменений: 100% (208/208), готово.
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # ll
total 181
drwxr-xr-x 9 root wheel 18 12 авг. 16:09 brotli/
drwxr-xr-x 2 root wheel 4 12 авг. 16:09 cloexec/
drwxr-xr-x 2 root wheel 5 12 авг. 16:09 golombset/
drwxr-xr-x 4 root wheel 35 12 авг. 16:09 klib/
drwxr-xr-x 2 root wheel 5 12 авг. 16:09 libgkc/
drwxr-xr-x 4 root wheel 26 12 авг. 16:09 libyrmcds/
drwxr-xr-x 13 root wheel 32 12 авг. 16:09 mruby/
drwxr-xr-x 5 root wheel 11 12 авг. 16:09 mruby-digest/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-dir/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-env/
drwxr-xr-x 4 root wheel 9 12 авг. 16:09 mruby-errno/
drwxr-xr-x 5 root wheel 14 12 авг. 16:09 mruby-file-stat/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-iijson/
drwxr-xr-x 5 root wheel 11 12 авг. 16:09 mruby-input-stream/
drwxr-xr-x 6 root wheel 11 12 авг. 16:09 mruby-io/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-onig-regexp/
drwxr-xr-x 4 root wheel 10 12 авг. 16:09 mruby-pack/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-require/
drwxr-xr-x 6 root wheel 10 12 сент. 16:10 mruby-socket/
drwxr-xr-x 2 root wheel 9 12 авг. 16:09 neverbleed/
drwxr-xr-x 2 root wheel 13 12 авг. 16:09 picohttpparser/
drwxr-xr-x 2 root wheel 4 12 авг. 16:09 picotest/
drwxr-xr-x 9 root wheel 16 12 авг. 16:09 picotls/
drwxr-xr-x 4 root wheel 8 12 авг. 16:09 ssl-conservatory/
drwxr-xr-x 8 root wheel 18 12 авг. 16:09 yaml/
drwxr-xr-x 2 root wheel 8 12 авг. 16:09 yoml/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # cd ../../..
root@beta:/usr/ports/www/h2o # make install clean
...Karaniwang pamantayan ang configuration ng web server.
root@beta:/usr/ports/www/h2o # cd /usr/local/etc/h2o/
root@beta:/usr/local/etc/h2o # cat h2o.conf
# this sample config gives you a feel for how h2o can be used
# and a high-security configuration for TLS and HTTP headers
# see https://h2o.examp1e.net/ for detailed documentation
# and h2o --help for command-line options and settings
# v.20180207 (c)2018 by Max Kostikov http://kostikov.co e-mail: max@kostikov.co
user: www
pid-file: /var/run/h2o.pid
access-log:
path: /var/log/h2o/h2o-access.log
format: "%h %v %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i""
error-log: /var/log/h2o/h2o-error.log
expires: off
compress: on
file.dirlisting: off
file.send-compressed: on
file.index: [ 'index.html', 'index.php' ]
listen:
port: 80
listen:
port: 443
ssl:
cipher-suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
cipher-preference: server
dh-file: /etc/ssl/dhparams.pem
certificate-file: /usr/local/etc/letsencrypt/live/eprove.net/fullchain.pem
key-file: /usr/local/etc/letsencrypt/live/my.domain/privkey.pem
hosts:
"*.my.domain":
paths: &go_tls
"/":
redirect:
status: 301
url: https://my.domain/
"my.domain:80":
paths: *go_tls
"my.domain:443":
header.add: "Strict-Transport-Security: max-age=15768000; includeSubDomains; preload"
paths:
"/dns-query":
mruby.handler-file: /usr/local/etc/h2o/h2odoh.rbAng tanging exception ay ang URL handler /dns-query kung saan ang aming DNS-over-HTTPS server, na nakasulat sa mruby at tinawag sa pamamagitan ng opsyon sa handler, ay talagang responsable mruby.handler-file.
root@beta:/usr/local/etc/h2o # cat h2odoh.rb
# H2O HTTP/2 web server as DNS-over-HTTP service
# v.20190908 (c)2018-2019 Max Kostikov https://kostikov.co e-mail: max@kostikov.co
proc {|env|
if env['HTTP_ACCEPT'] == "application/dns-message"
case env['REQUEST_METHOD']
when "GET"
req = env['QUERY_STRING'].gsub(/^dns=/,'')
# base64URL decode
req = req.tr("-_", "+/")
if !req.end_with?("=") && req.length % 4 != 0
req = req.ljust((req.length + 3) & ~3, "=")
end
req = req.unpack1("m")
when "POST"
req = env['rack.input'].read
else
req = ""
end
if req.empty?
[400, { 'content-type' => 'text/plain' }, [ "Bad Request" ]]
else
# --- ask DNS server
sock = UDPSocket.new
sock.connect("localhost", 53)
sock.send(req, 0)
str = sock.recv(4096)
sock.close
# --- find lowest TTL in response
nans = str[6, 2].unpack1('n') # number of answers
if nans > 0 # no DNS failure
shift = 12
ttl = 0
while nans > 0
# process domain name compression
if str[shift].unpack1("C") < 192
shift = str.index("x00", shift) + 5
if ttl == 0 # skip question section
next
end
end
shift += 6
curttl = str[shift, 4].unpack1('N')
shift += str[shift + 4, 2].unpack1('n') + 6 # responce data size
if ttl == 0 or ttl > curttl
ttl = curttl
end
nans -= 1
end
cc = 'max-age=' + ttl.to_s
else
cc = 'no-cache'
end
[200, { 'content-type' => 'application/dns-message', 'content-length' => str.size, 'cache-control' => cc }, [ str ] ]
end
else
[415, { 'content-type' => 'text/plain' }, [ "Unsupported Media Type" ]]
end
}Pakitandaan na ang lokal na server ng caching ay responsable para sa pagproseso ng mga DNS packet, sa kasong ito mula sa karaniwang pamamahagi ng FreeBSD. Mula sa pananaw ng seguridad, ito ang pinakamainam na solusyon. Gayunpaman, walang pumipigil sa iyo na palitan localhost sa ibang DNS address na balak mong gamitin.
root@beta:/usr/local/etc/h2o # local-unbound verison
usage: local-unbound [options]
start unbound daemon DNS resolver.
-h this help
-c file config file to read instead of /var/unbound/unbound.conf
file format is described in unbound.conf(5).
-d do not fork into the background.
-p do not create a pidfile.
-v verbose (more times to increase verbosity)
Version 1.8.1
linked libs: mini-event internal (it uses select), OpenSSL 1.1.1a-freebsd 20 Nov 2018
linked modules: dns64 respip validator iterator
BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl
root@eprove:/usr/local/etc/h2o # sockstat -46 | grep unbound
unbound local-unbo 69749 3 udp6 ::1:53 *:*
unbound local-unbo 69749 4 tcp6 ::1:53 *:*
unbound local-unbo 69749 5 udp4 127.0.0.1:53 *:*
unbound local-unbo 69749 6 tcp4 127.0.0.1:53 *:*Ang natitira na lang ay i-restart ang H2O at tingnan kung ano ang nanggagaling dito.
root@beta:/usr/local/etc/h2o # service h2o restart
Stopping h2o.
Waiting for PIDS: 69871.
Starting h2o.
start_server (pid:70532) starting now...4. Pagsubok
Kaya, suriin natin ang mga resulta sa pamamagitan ng pagpapadala muli ng kahilingan sa pagsubok at pagtingin sa trapiko ng network gamit ang utility tcpdump.
root@beta/usr/local/etc/h2o # curl -H 'accept: application/dns-message' 'https://my.domain/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE'
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
...
root@beta:~ # tcpdump -n -i lo0 udp port 53 -xx -XX -vv
tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
16:32:40.420831 IP (tos 0x0, ttl 64, id 37575, offset 0, flags [none], proto UDP (17), length 57, bad cksum 0 (->e9ea)!)
127.0.0.1.21070 > 127.0.0.1.53: [bad udp cksum 0xfe38 -> 0x33e3!] 43981+ A? example.com. (29)
0x0000: 0200 0000 4500 0039 92c7 0000 4011 0000 ....E..9....@...
0x0010: 7f00 0001 7f00 0001 524e 0035 0025 fe38 ........RN.5.%.8
0x0020: abcd 0100 0001 0000 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01 mple.com.....
16:32:40.796507 IP (tos 0x0, ttl 64, id 37590, offset 0, flags [none], proto UDP (17), length 73, bad cksum 0 (->e9cb)!)
127.0.0.1.53 > 127.0.0.1.21070: [bad udp cksum 0xfe48 -> 0x43fa!] 43981 q: A? example.com. 1/0/0 example.com. A 93.184.216.34 (45)
0x0000: 0200 0000 4500 0049 92d6 0000 4011 0000 ....E..I....@...
0x0010: 7f00 0001 7f00 0001 0035 524e 0035 fe48 .........5RN.5.H
0x0020: abcd 8180 0001 0001 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01c0 0c00 mple.com........
0x0040: 0100 0100 0151 8000 045d b8d8 22 .....Q...].."
^C
2 packets captured
23 packets received by filter
0 packets dropped by kernelAng output ay nagpapakita kung paano ang kahilingan upang malutas ang address example.com ay natanggap at matagumpay na naproseso ng DNS server.
Ngayon ang natitira na lang ay i-activate ang aming server sa Firefox browser. Upang gawin ito, kailangan mong baguhin ang ilang mga setting sa mga pahina ng pagsasaayos tungkol sa: config.
Una, ito ang address ng aming API kung saan hihilingin ng browser ang impormasyon ng DNS network.trr.uri. Inirerekomenda din na tukuyin ang domain IP mula sa URL na ito para sa secure na IP resolution gamit ang browser mismo nang hindi ina-access ang DNS network.trr.bootstrapAddress. At sa wakas, ang parameter mismo network.trr.mode kabilang ang paggamit ng DoH. Ang pagtatakda ng value sa "3" ay pipilitin ang browser na gumamit ng eksklusibong DNS-over-HTTPS para sa paglutas ng pangalan, habang ang mas maaasahan at secure na "2" ay magbibigay ng priyoridad sa DoH, na iniiwan ang karaniwang DNS lookup bilang isang fallback na opsyon.
5. KITA!
Nakatulong ba ang artikulo? Kung gayon, mangyaring huwag mahiya at suportahan ng pera sa pamamagitan ng form ng donasyon (sa ibaba).
Pinagmulan: www.habr.com
