Пересылка DNS на DNS-over-TLS Cloudflare через CoreDNS - PullRequest
Новая
       38

Пересылка DNS на DNS-over-TLS Cloudflare через CoreDNS

1 голос
/ 08 апреля 2019

Я использую этот образ Docker в качестве примера, чтобы попытаться настроить безопасную пересылку DNS по TLS для распознавателей CloudFlare.Я использую CoreDNS 1.5.0 (последняя версия), и моя конфигурация такая: 

# CoreDNS Configuration

.:53 {
  forward . tls://1.1.1.1 tls://1.0.0.1 {
    tls_servername tls.cloudflare-dns.com
    policy sequential
    health_check 5s
  }

  log
}

Я делаю запросы примерно так: 

root@8ef125545369:/# dig @127.0.0.1 google.com

; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> @127.0.0.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49802
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 090b0d7fadcdd8bb (echoed)
;; QUESTION SECTION:
;google.com.                    IN      A

;; Query time: 24 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Apr 08 19:29:30 UTC 2019
;; MSG SIZE  rcvd: 51

Я не получаю ответы.Журналы CoreDNS выглядят так: 

missioncontrol    | 2019-04-08T19:29:30.778Z [INFO] 127.0.0.1:39615 - 49802 "A IN google.com. udp 51 false 4096" NOERROR - 0 5.02365452s
missioncontrol    | 2019-04-08T19:29:35.759Z [INFO] 127.0.0.1:39615 - 49802 "A IN google.com. udp 51 false 4096" NOERROR - 0 5.00549558s

Ясно, что CoreDNS получает запросы, но я не могу определить, почему это не удается.Мой образ ubuntu:bionic и ca-certificates установлен.Я также могу использовать openssl s_client для подключения к 1.1.1.1:443 без проблем.

Есть ли что-то, чего мне не хватает для настройки пересылки DNS-over-TLS из CoreDNS в распознаватели CloudFlare?

EDIT

Я проверил это на моей операционной системе за пределами контейнера Docker, и я вижу ту же функциональность, а именно то, что она не работает.

1 Ответ

0 голосов
/ 10 апреля 2019

Я снова проверил это, запустив его в Travis CI, и это сработало;очевидно, мой корпоративный брандмауэр не любит DNS-over-TLS.

Я смог проверить это, установив knot-dnsutils (в Ubuntu 18.04) и попытавшись напрямую запросить Cloudflare: 

$ kdig -d @1.0.0.1 +tls-ca +tls-host=cloudflare-dns.com google.com
;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(1.0.0.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 133 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: V6zes8hHBVwUECsHf7uV5xGM7dj3uMXIS9//7qC8+jU=
;; 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.
;; WARNING: TLS, handshake failed (Error in the pull function.)

Это то, что произошло при запросах внутри корпоративной сети.Из Travis CI я увидел: 

;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 133 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: V6zes8hHBVwUECsHf7uV5xGM7dj3uMXIS9//7qC8+jU=
;; 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: 59442
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1452 B; ext-rcode: NOERROR
;; PADDING: 69 B
;; QUESTION SECTION:
;; google.com.              IN  A
;; ANSWER SECTION:
google.com.             156 IN  A   172.217.5.14
;; Received 128 B
;; Time 2019-04-09 22:03:18 UTC
;; From 1.1.1.1@853(TCP) in 12.8 ms

Очевидно, что корпоративный брандмауэр, к сожалению, блокирует этот доступ.

...