Itinataas namin ang aming DNS-over-HTTPS server

Ang iba't ibang aspeto ng pagpapatakbo ng DNS ay paulit-ulit na nahawakan ng may-akda sa ilang mga Artikulo nai-publish bilang bahagi ng blog. Kasabay nito, ang pangunahing diin ay palaging sa pagpapabuti ng seguridad ng pangunahing serbisyo sa Internet na ito.

Itinataas namin ang aming DNS-over-HTTPS server

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 pagpapalakas ng proteksyon nito, 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 nakasaad tungkol sa mga planong paganahin ang mode ng suporta bilang default DNS-over-HTTPS (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 RFC8484 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. RFC1035 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 intact

Bigyang-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 H2O, tungkol sa kung saan naisulat na ng may-akda nang maikli (tingnan ang "Mataas na Pagganap ng H2O Web Server").

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 mruby. 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 kasalukuyan sa mga FreeBSD port. Gayunpaman, hindi mahirap idagdag ito sa anumang nakaraang bersyon sa pamamagitan ng pag-clone ng repositoryo Mga library ng socket 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: [email protected]

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.rb

Ang 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: [email protected]

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 walang tali 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 [email protected]
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 kernel

Ang 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.

Itinataas namin ang aming DNS-over-HTTPS server

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

Magdagdag ng komento