DNSSEC errors


#1

I’ve been using Cloudflare and Quad9 DNS on my pfSense box (latest v2.4.3), using unbound with DNSSEC enabled and ssl-upstream set to ‘yes’. When Quad9 is primary, everything works great. Queries are DNSSEC verified and SSL is working as expected. When I set Cloudflare (1.0.0.1) as primary however, I get some messages about DNSSEC and insecure answers.

I ran through GRC.com DNS spoof check as well as Verisign’s DNSSEC checker. The former says DNSSEC is not valid for Cloudflare, and the latter says that 1.1.1.in-addr.arpa has errors. “Either the zone is not signed with DNSSEC, or the zone maintainer neglected to include the DNSKEY records before signing it”.

I’ve gone back to Quad9 for now as I don’t know enough about the matter to make an informed decision. When I ran tests using unbound-host on my Linux box the queries returned as (SECURE) but I’d like some feedback if possible. Cloudflare is twice as fast as other public DNS servers for me (mostly thanks to a very local server it seems), so I’m keen to switch back. Thanks in advance.


#2

Hi, can you tell me which domain names failed to validate?


#3

1.1.1.in-addr.arpa. doesn’t have errors*. It’s just not signed. “Not using DNSSEC” is a completely valid setup. DNSSEC monitors understandably don’t love it, but it’s not invalid.

* The delegation and authoritative NS records are inconsistent, but they all work.


#4

GRC doesn’t report knot-resolver as DNSSEC-capable. That’s possibly because knot-resolver doesn’t send +DO in domains that are insecure. (I didn’t find a description how GRC detects this.)


#5

Apologies for the delay. Unfortunately despite an exceptionally low ping and response time (originally), I can’t use Cloudflare DNS at the moment. I’m just getting errors about TLS failure using both 1.0.0.1 and 1.1.1.1 (Stubby, macOS). My pfSense box is falling back to Quad9 as well so I guess my local server is having issues.

[22:00:50.451441] STUBBY: Read config from file /Applications/StubbyManager.app/Contents/MacOS/stubby.yml

[22:00:50.452655] STUBBY: Starting DAEMON…
[22:01:05.291237] STUBBY: 9.9.9.9 : Conn opened: TLS - Strict Profile
[22:01:24.444798] STUBBY: 9.9.9.9 : Conn closed: TLS - Resps= 451, Timeouts = 0, Curr_auth =Success, Keepalive(ms)= 10000
[22:01:24.444877] STUBBY: 9.9.9.9 : Upstream : TLS - Resps= 451, Timeouts = 0, Best_auth =Success
[22:01:24.444916] STUBBY: 9.9.9.9 : Upstream : TLS - Conns= 1, Conn_fails= 0, Conn_shuts= 0, Backoffs = 0
[22:01:24.477069] STUBBY: 9.9.9.9 : Conn opened: TLS - Strict Profile
[22:01:36.495368] STUBBY: Read config from file /Applications/StubbyManager.app/Contents/MacOS/stubby.yml
[22:01:36.496466] STUBBY: Starting DAEMON…
[22:01:39.423989] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:01:39.464709] STUBBY: 1.1.1.1 : Conn closed : Transport=TLS - Failure
[22:01:39.464815] STUBBY: FAILURE no valid transports or upstreams available!
[22:01:39.465043] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = None, Keepalive(ms)= 0
[22:01:39.465164] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = None
[22:01:39.465247] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 0, Conn_fails= 1, Conn_shuts= 0, Backoffs = 0
[22:01:39.774068] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:01:39.817766] STUBBY: 1.1.1.1 : Conn closed : Transport=TLS - Failure
[22:01:39.817914] STUBBY: FAILURE no valid transports or upstreams available!
[22:01:39.818068] STUBBY: 1.1.1.1 : Conn closed : Transport=TLS - Failure
[22:01:39.818123] STUBBY: FAILURE no valid transports or upstreams available!
[22:01:39.818242] STUBBY: 1.1.1.1 : Conn closed : Transport=TLS - Failure
[22:01:39.818296] STUBBY: FAILURE no valid transports or upstreams available!
[22:01:39.818408] STUBBY: 1.1.1.1 : Conn closed : Transport=TLS - Failure
[22:01:39.819412] STUBBY: FAILURE no valid transports or upstreams available!
[22:01:39.820080] STUBBY: 1.1.1.1 : Conn closed: TLS - Resps= 0, Timeouts = 0, Curr_auth = None, Keepalive(ms)= 0
[22:01:39.820243] STUBBY: 1.1.1.1 : Upstream : TLS - Resps= 0, Timeouts = 0, Best_auth = None
[22:01:39.820363] STUBBY: 1.1.1.1 : Upstream : TLS - Conns= 0, Conn_fails= 2, Conn_shuts= 0, Backoffs = 0
[22:01:39.820513] STUBBY: 1.1.1.1 : !Backing off this upstream - Will retry again in 2s at Mon Apr 9 22:01:41 2018
[22:01:39.820948] STUBBY: 1.1.1.1 : No valid upstreams… promoting this backed-off upstream for re-try…
[22:01:39.821187] STUBBY: 1.1.1.1 : Conn opened: TLS - Strict Profile
[22:01:39.867570] STUBBY: 1.1.1.1 : Conn closed : Transport=TLS - Failure
[22:01:39.867705] STUBBY: FAILURE no valid transports or upstreams available!
[22:01:39.867889] STUBBY: 1.1.1.1 : Conn closed : Transport=TLS - Failure


#6

Some further information about the above, in case it helps:

Cloudflare:

$ openssl s_client -connect 1.1.1.1:853
CONNECTED(00000003)
140735852045256:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s23_lib.c:124:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 0 bytes and written 318 bytes

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated

Quad9:

$ openssl s_client -connect 9.9.9.9:853
CONNECTED(00000003)
depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0

Certificate chain
0 s:/CN=dns.quad9.net
i:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
1 s:/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3

Server certificate
-----BEGIN CERTIFICATE-----
MIIFEDCCA/igAwIBAgISBPB8Mw8Nc7R9gSXhW3J0eaM8MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODAxMjkxODI0MjdaFw0x
ODA0MjkxODI0MjdaMBgxFjAUBgNVBAMTDWRucy5xdWFkOS5uZXQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD2P6Z7vQHzML7NetGPlDZLsUqxF3rDpAQ5
QV1LNwwurijSs+ZUl5s9I5BWSjuU4Yddwzowxeg4WfZnwcAKV5iYDy/0OCUR5c4b
vOtF4hb9dPG4InW1bWpDiQNJ3M9M8ncCdLzE3+Dxhx+V9Da3wjrqM1LChnuHV1ol
btwr0HgKZ8JP6IrpcZ+cgOaWZH6p0YsS7zWRjZ4AOUNBajgx+kEjNKp3nNVQZaW3
tcjjLuT+dBstzLbZ6lMVwacIpkPgVc0IITgVKEWkh7bQydxBK5cINjwJYuBBRIvz
StQ4Psod/BtXlss82ZcoDkxV3Ob2tHKxmuEEEgfH7V1QrKsuqb5jAgMBAAGjggIg
MIICHDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFF78BAcRVZoB0AgBJryyTCMZCDb1
MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEBBGMw
YTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0Lm9y
ZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0Lm9y
Zy8wKwYDVR0RBCQwIoINZG5zLnF1YWQ5Lm5ldIIRZG5zLnJyZG5zLnBjaC5uZXQw
gf4GA1UdIASB9jCB8zAIBgZngQwBAgEwgeYGCysGAQQBgt8TAQEBMIHWMCYGCCsG
AQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCBqwYIKwYBBQUHAgIw
gZ4MgZtUaGlzIENlcnRpZmljYXRlIG1heSBvbmx5IGJlIHJlbGllZCB1cG9uIGJ5
IFJlbHlpbmcgUGFydGllcyBhbmQgb25seSBpbiBhY2NvcmRhbmNlIHdpdGggdGhl
IENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL2xldHNlbmNyeXB0
Lm9yZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEABA8dQoYadPBHz6GN
Bv+ntf/kXBvvBJaD6WglKDMp7RHEofTURD8u0Rb6Jtxr09q+1R2UcO8NqG0l4o9E
+eqUzB0kq+bR6iuKwXYXLyBoAJvEMesN3feekxlea6JIUbzx3kDqWjXuFIoReecX
gPovwnHLwvT8Yk1aPCjm/DD6rW2Ab8JIjruaOVDEhhG1RLFrRDjuIKzmkjPyhJWm
0v9pQ0Uo1ma27IXRIr97rp/jUlioypt+s8BnoUI5iDc4aL82v1CiTLMSpjlKfLT1
ytLPi3TOBZ7iupAy8PjJbLD/zG51CiRJFjpBaISJ5ZP0kYVznBIeZHSP3MJJa+aK
grOPpQ==
-----END CERTIFICATE-----
subject=/CN=dns.quad9.net
issuer=/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3

No client certificate CA names sent

SSL handshake has read 2984 bytes and written 444 bytes

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: D58BE1832927FAFE5DC88BF0537D3EE8F96AD113D4BF9313EEA2FBC4F21DD2D4
Session-ID-ctx:
Master-Key: EE848E91C7D53A27B6CCC336100A51043F2060889F4963869F3E16B23C35B377FB3F7E13DEAD011671BC376137D298D6
Start Time: 1523324851
Timeout : 300 (sec)
Verify return code: 0 (ok)

closed


#7
Hey there,

Are you open to do some further debugging ?

Can we get the output of following commands

traceroute 1.1.1.1
traceroute 1.0.0.1
dig @1.1.1.1 id.server CH TXT
dig @1.0.0.1 id.server CH TXT
dig +tcp @1.1.1.1 id.server CH TXT
dig +tcp @1.0.0.1 id.server CH TXT
openssl s_client -connect 1.1.1.1:853
openssl s_client -connect 1.0.0.1:853
curl -Lvs http://1.0.0.1/
curl -Lvs http://1.1.1.1/
curl -v 'https://1.1.1.1/dns-query?ct=application/dns-json&name=cloudflare.com'
curl -v 'https://1.0.0.1/dns-query?ct=application/dns-json&name=cloudflare.com'
curl -v http://www.cloudflare.com/cdn-cgi/trace

#8

Hi,

Yes, no problem. Please find the outputs of your requested commands on Pastebin here. I have further appended some of the same commands directed at Quad9 for reference. You can see, for example, that SSL handshakes fine with them - which hopefully helps rule out an issue at my end.

FYI, the second hop on the traceroutes (10.x.x.x) is my ISP’s CMTS. They use local IPs in the network. I am not running two routers/firewalls/networks locally.

Thanks in advance. :slight_smile:


#9

Thanks for the quick response. Everything except 1.1.1.1:853 seems to be working. I will check if there are any issues with 1.1.1.1 port 853 on the POP you are hitting. Meanwhile it seems 1.0.0.1:853 works fine, can you try that out in stubby ?


#10

We have verified that 1.1.1.1 port 853 is responding correctly with the certificate on our side.

Can you try few more commands ?

dig +tcp @1.1.1.1 -p 853 www.cloudflare.com
echo '\r\n' | nc 1.1.1.1 853

on terminal #1
sudo tcpdump -i <interface conected to internet> -nn -s0 -vv net 1.1.1.1 or icmp

on terminal #2
openssl s_client -connect 1.1.1.1:853

on terminal #1   
CTRL + C  and copy the output of tcpdump

#11

New PasteBin here.


#12

Thanks.

Still not sure why only 1.1.1.1:853 is not working.

One thing I noticed is routing path to 1.1.1.1 is via GTT while 1.0.0.0.1 is direct. We are working with Virgin Media to improve the routing such that both prefixes take the same path towards Cloudflare.

In the meanwhile can you use 1.0.0.1 which seems to work as suggested by our earlier debugging.