strib
commented
5 years ago @maxtaco know anything about our dnssec records?
Closed lmlsna closed 5 years ago
strib
commented
5 years ago @maxtaco know anything about our dnssec records?
pzduniak
commented
5 years ago Thank you for your report! Unfortunately we do not support DNSSEC on our domains due to our provider's restrictions (AWS Route53) - so if you're enforcing DNSSEC on all DNS requests coming out from your resolver, it will fail on all of our domains, just like it fails on amazon.com and other non-DNSSEC domains.
Effectively what DNSSEC protects from is DNS server hijacking (such as the MyEtherWallet hack), which given AWS' security is not that far away in its complexity from performing a BGP hijack on EC2 itself (which would hijack our IPs rather the DNS servers).
Thankfully Keybase's security model protects the users from such attacks! The protocol is built in such a way that the app will know when the server is not being honest. You can read more about how that works here.
Avamander
commented
5 years ago @pzduniak It might be worth reading this output:
api-0.core.keybaseapi.com/A: A query for api-0.core.keybaseapi.com results in a NOERROR response, while a query for its ancestor, core.keybaseapi.com, returns a name error (NXDOMAIN), which indicates that subdomains of core.keybaseapi.com, including api-0.core.keybaseapi.com, don't exist. (205.251.193.211, 205.251.195.20, 205.251.196.173, 205.251.199.75, 2600:9000:5301:d300::1, 2600:9000:5303:1400::1, 2600:9000:5304:ad00::1, 2600:9000:5307:4b00::1, UDP_-_EDNS0_4096_D_K)It's not a DNSSEC issue but rather a general DNS error, core.keybaseapi.com should not return NXDOMAIN.
lmlsna
commented
5 years ago FWIW, I have allow-downgrade set, so I can resolve domains that don't provide DNSSEC, but it's throwing an error because core.keybaseapi.com has no records pointing to where to resolve the next level up (*.core.keybaseapi.com). Which is also why I think it validates when resolved from the top down, but not the bottom up.
I think adding the same amazon NS records for the core subdomain would fix it (it being minor usability, not security, issue).
pzduniak
commented
5 years ago Huh, that's weird, I haven't ran into this before. Can you please check if you can resolve test.doesntexist.oakmail.io using your configuration? It's set up in such a way that test.doesntexist.oakmail.io and oakmail.io resolve, whereas doesntexist.oakmail.io doesn't.
lmlsna
commented
5 years ago @pzduniak I get NXDOMAIN responses for both, and as far as I can tell, there is no A/AAAA record for test.doesntexist.oakmail.io, so might not be a 1:1 comparison.
I get a SERVFAIL when trying to resolve either of the sub-sub-domans myself using recursion from the root nameservers (using the systemd resolver with the DNSSEC=allow-downgrade option set):
; <<>> DiG 9.11.5-P1-1ubuntu2-Ubuntu <<>> +recurse test.doesntexist.oakmail.io doesntexist.oakmail.io api-0.core.keybaseapi.com core.keybaseapi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21690
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;test.doesntexist.oakmail.io. IN A
;; Query time: 135 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 01 12:10:21 PST 2019
;; MSG SIZE rcvd: 56
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 272
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;doesntexist.oakmail.io. IN A
;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 01 12:10:21 PST 2019
;; MSG SIZE rcvd: 51
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51061
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;api-0.core.keybaseapi.com. IN A
;; Query time: 9 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 01 12:10:21 PST 2019
;; MSG SIZE rcvd: 54
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27484
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;core.keybaseapi.com. IN A
;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 01 12:10:21 PST 2019
;; MSG SIZE rcvd: 48However, if I get A records for api-0.core.keybaseapi.com and NXDOMAIN responses for the others if I disable DNSSEC completely and run top down query like most people probably do:
; <<>> DiG 9.11.5-P1-1ubuntu2-Ubuntu <<>> +topdown test.doesntexist.oakmail.io doesntexist.oakmail.io api-0.core.keybaseapi.com core.keybaseapi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64933
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;test.doesntexist.oakmail.io. IN A
;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 01 12:14:57 PST 2019
;; MSG SIZE rcvd: 56
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8645
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;doesntexist.oakmail.io. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 01 12:14:57 PST 2019
;; MSG SIZE rcvd: 51
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30980
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;api-0.core.keybaseapi.com. IN A
;; ANSWER SECTION:
api-0.core.keybaseapi.com. 43 IN A 52.205.52.74
api-0.core.keybaseapi.com. 43 IN A 52.201.110.180
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 01 12:14:57 PST 2019
;; MSG SIZE rcvd: 86
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3008
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;core.keybaseapi.com. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Mar 01 12:14:57 PST 2019
;; MSG SIZE rcvd: 48So this actually may be an implementation error (or unhelpful over-strictness) issue with the systemd resolver, but I don't see the same errors on dnsviz for the two examples:
¯\_(ツ)_/¯
lmlsna
commented
5 years ago Yeah, wow, looks like it's probably a systemd-resolve bug https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1650877. Occam's razor is not always helpful I guess. Apologies.
Avamander
commented
5 years ago @lmlsna If you look at the dnsviz output it too complains about the non-standard response. It's just systemd-resolved errors on it (because it's not actually valid). It would still be nice if that warning/error would be fixed.
pzduniak
commented
5 years ago Ahh, I moved that domain I posted to Google DNS while the change was on Route 53, oops! I added the A record on my domain in gcloud and the error is not shown in dnsviz there, it looks like this is a Route 53 issue (or rather not adhering to some spec? haven't heard anything about such a restriction).
The warning is on a Route 53 domain, so feel free to report it to them. The error is, I think, dnsviz simply getting confused - I haven't seen anything in the spec that would disallow configuring domains without A records.
Avamander
commented
5 years ago it looks like this is a Route 53 issue (or rather not adhering to some spec? haven't heard anything about such a restriction).
The error is, I think, dnsviz simply getting confused - I haven't seen anything in the spec that would disallow configuring domains without A records.
@pzduniak core.keybaseapi.com is not Route 53's, is it? It would probably suffice just to create the zone without any records (except glue) to make it resolvable top-down.
Avamander
commented
5 years ago FYI it's not also just dnsviz, other tools online also fail to resolve it top-down: http://www.webdnstools.com/dnstools/domain_check And RIPE's tool: https://dnscheck.ripe.net/test/99738d5a22ccdfec
Avamander
commented
5 years ago This is how a domain should look like at RIPE's DNS scanner: https://dnscheck.ripe.net/test/7a78e87f39df1096
pzduniak
commented
5 years ago The zone is keybaseapi.com, it's using Route 53. If the behaviour is not adhering to the spec, it's Amazon's fault. They should indeed return an empty NOERROR packet for core.keybaseapi.com rather than a NXDOMAIN, but my guess is this is an optimization of the lookup process.
Avamander
commented
5 years ago @pzduniak You are correct, Route53 seems to be non-standard: https://forums.aws.amazon.com/thread.jspa?threadID=260905
It seems that just adding a TXT record to core.keybaseapi.com would make it work according to the spec, could that be done to make RFC-enforcing resolvers work?
pzduniak
commented
5 years ago 
Done.
Avamander
commented
5 years ago @lmlsna Can you test, does systemd-resolved now resolve it?
lmlsna
commented
5 years ago Confirmed! Working just fine now:
dig +dnssec api-0.core.keybaseapi.com core.keybaseapi.com -t any
; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> +dnssec api-0.core.keybaseapi.com core.keybaseapi.com -t any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58958
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;api-0.core.keybaseapi.com. IN A
;; ANSWER SECTION:
api-0.core.keybaseapi.com. 24 IN A 52.205.52.74
api-0.core.keybaseapi.com. 24 IN A 52.201.110.180
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Mar 05 20:36:04 PST 2019
;; MSG SIZE rcvd: 86
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62023
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;core.keybaseapi.com. IN ANY
;; ANSWER SECTION:
core.keybaseapi.com. 299 IN TXT "keybase core services"
;; Query time: 56 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Mar 05 20:36:04 PST 2019
;; MSG SIZE rcvd: 82Much thanks.
Regular DNSSEC validation is failing. This issue prevents those enforcing DNSSEC from logging into the app, and does not provide much insight into what the issue is. I have included the output of
dig, as well as dnssec-analyzer, and dnsviz to confirm this issue is not just on my end.I believe this issued started happening a few days ago. Turning off DNSSEC validation fixes the issue. While regular DNSSEC validation is failing due to missing RRSIG records, top-down validation appears to be working, for what that's worth.
dig . DNSKEY @8.8.8.8 | grep -Ev '^($|;)' | tee /tmp/root.keysdig +additional +besteffort +crypto +dnssec +nofail +identify +question +recurse +sigchase +trace +trusted-key=/tmp/root.keys +topdown api-0.core.keybaseapi.com @8.8.8.8Top down validation is working however:
dig +additional +besteffort +crypto +dnssec +nofail +identify +question +recurse +sigchase +trace +trusted-key=/tmp/root.keys +topdown api-0.core.keybaseapi.com @8.8.8.8dnsviz:
dnssec-analyzer:
systemd-resolve logs