New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checking domains rather than just hosts #2

Closed
jimfenton opened this Issue Nov 19, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@jimfenton

DNSSEC Name-and-Shame purports to be checking domains for DNSSEC usage, but as far as I can tell it's checking hosts, not domains, because it's just looking at A and AAAA records.

A better way to fulfill the promise of checking domains would be, at least in the absence of A/AAAA records, check whether the SOA record for the domain is signed, and report a positive result if it is.

Unfortunately, I haven't done any work in NodeJS; otherwise I'd submit this as a pull request instead. It appears to be a very simple code change, along the lines of:

                function stripDNSLookupObjectForFrontend(records) {
                    var IsRecSecure = hasSecureRecordOfType(records, getdns.RRTYPE_A) || hasSecureRecordOfType(records, getdns.RRTYPE_AAAA) || hasSecureRecordOfType(records, getdns.RRTYPE_SOA),
                        result = {
                            isSecure: IsRecSecure
                        };

                    return result;
                }
@joelpurra

This comment has been minimized.

Show comment
Hide comment
@joelpurra

joelpurra Nov 22, 2015

Owner

@jimfenton: yes, checking SOA would be a broader DNSSEC check. I'll restructure the code a little bit in order to not only check for A/AAAA.

In that case I'd like to also differentiate between a broader range of records. Perhaps SOA, A, AAAA, CNAME, MX? If all of those records (which are present) are secure, then the domain is secure, as far as https://dnssec-name-and-shame.com/ is concerned. Sounds good?

Oh, and will have to investigate CNAMEs; see GETDNS_REDIRECTS_FOLLOW

I'll probably forget to update the documentation/website once the patch is done. Please check and remind me. Thanks!

Owner

joelpurra commented Nov 22, 2015

@jimfenton: yes, checking SOA would be a broader DNSSEC check. I'll restructure the code a little bit in order to not only check for A/AAAA.

In that case I'd like to also differentiate between a broader range of records. Perhaps SOA, A, AAAA, CNAME, MX? If all of those records (which are present) are secure, then the domain is secure, as far as https://dnssec-name-and-shame.com/ is concerned. Sounds good?

Oh, and will have to investigate CNAMEs; see GETDNS_REDIRECTS_FOLLOW

I'll probably forget to update the documentation/website once the patch is done. Please check and remind me. Thanks!

@jimfenton

This comment has been minimized.

Show comment
Hide comment
@jimfenton

jimfenton Nov 23, 2015

You might want to check me on this, but since DNSSEC signing is done at the zone level, if the SOA is signed then the A and AAAA records for that same name must also be signed. If SOA doesn't exist (perhaps because it's a hostname), then it makes sense to check A and AAAA (although any good signature again should indicate that all record types for that host are also signed).

CNAME and MX records are a separate problem. Since they point to other hostnames that need to be looked up, it's possible that those hostnames are in zones that are unsigned. So it always makes sense to look for those and check the hostname they resolve to. I get lots of warnings on my DNSSEC-checking caching server as a result of CNAMEs to unsigned places. Unfortunately, it's not in general possible to find all the CNAMEs for a domain, so you can't guarantee that this won't happen.

You might want to check me on this, but since DNSSEC signing is done at the zone level, if the SOA is signed then the A and AAAA records for that same name must also be signed. If SOA doesn't exist (perhaps because it's a hostname), then it makes sense to check A and AAAA (although any good signature again should indicate that all record types for that host are also signed).

CNAME and MX records are a separate problem. Since they point to other hostnames that need to be looked up, it's possible that those hostnames are in zones that are unsigned. So it always makes sense to look for those and check the hostname they resolve to. I get lots of warnings on my DNSSEC-checking caching server as a result of CNAMEs to unsigned places. Unfortunately, it's not in general possible to find all the CNAMEs for a domain, so you can't guarantee that this won't happen.

@joelpurra joelpurra closed this in 056a6c8 Apr 27, 2016

@joelpurra

This comment has been minimized.

Show comment
Hide comment
@joelpurra

joelpurra Apr 27, 2016

Owner

@jimfenton: it's tricky indeed! Finally got back to this and deployed a patch.

Not sure how much more "advanced" this website should be -- it's not a proper security tool, just something of a DNSSEC deployment indicator.

  • Wrote code to check A, AAAA, CNAME, MX and SOA separately.
  • Missing records are ignored. If all replies are secure, then the result will be shown as secure.
  • Per-record type results are presented separately, if details are expanded by the user.
  • CNAME records are followed by getdns (GETDNS_REDIRECTS_FOLLOW), potentially affecting all record types (right?).
  • MX records are not followed.
  • Didn't yet fix the GUI for lookups without any (matching) records, which also means non-existing domains look weird.

An interesting example is www.paypal.com, which as an insecure A record (when CNAME-resolved all the way to Akamai), but a secure CNAME record (because paypal signs their own zone). The distinction isn't obvious, but at least it's indicated in some way.

  • Could it be improved?
  • Should CNAMEs (always) be followed?

Example lookups

Examples of live, raw JSON results and their reported results (most are examples are secure).

Owner

joelpurra commented Apr 27, 2016

@jimfenton: it's tricky indeed! Finally got back to this and deployed a patch.

Not sure how much more "advanced" this website should be -- it's not a proper security tool, just something of a DNSSEC deployment indicator.

  • Wrote code to check A, AAAA, CNAME, MX and SOA separately.
  • Missing records are ignored. If all replies are secure, then the result will be shown as secure.
  • Per-record type results are presented separately, if details are expanded by the user.
  • CNAME records are followed by getdns (GETDNS_REDIRECTS_FOLLOW), potentially affecting all record types (right?).
  • MX records are not followed.
  • Didn't yet fix the GUI for lookups without any (matching) records, which also means non-existing domains look weird.

An interesting example is www.paypal.com, which as an insecure A record (when CNAME-resolved all the way to Akamai), but a secure CNAME record (because paypal signs their own zone). The distinction isn't obvious, but at least it's indicated in some way.

  • Could it be improved?
  • Should CNAMEs (always) be followed?

Example lookups

Examples of live, raw JSON results and their reported results (most are examples are secure).

@jimfenton

This comment has been minimized.

Show comment
Hide comment
@jimfenton

jimfenton May 10, 2016

I played with the new version a bit, and it's much improved. I looked through some of the logs for my caching name server for some good domains to try. truste.com was interesting because they seem to have RRSIG records, but there don't seem to be any DS records for the domain. I wonder how they expect that to work.

With respect to CNAME: There seem to be lots of DNSSEC-supporting domains that CNAME to other domains that aren't. But that isn't universally true: www.ietf.org CNAMEs to something in cloudflare-dnssec.net, which is also DNSSEC-protected (yay). There seems to be a "winking acceptance" of CNAMEs that go to unsigned domains, but I think it would be better if we could give only half credit for that since it isn't really secure. The same goes for MX records pointing elsewhere.

I played with the new version a bit, and it's much improved. I looked through some of the logs for my caching name server for some good domains to try. truste.com was interesting because they seem to have RRSIG records, but there don't seem to be any DS records for the domain. I wonder how they expect that to work.

With respect to CNAME: There seem to be lots of DNSSEC-supporting domains that CNAME to other domains that aren't. But that isn't universally true: www.ietf.org CNAMEs to something in cloudflare-dnssec.net, which is also DNSSEC-protected (yay). There seems to be a "winking acceptance" of CNAMEs that go to unsigned domains, but I think it would be better if we could give only half credit for that since it isn't really secure. The same goes for MX records pointing elsewhere.

@joelpurra

This comment has been minimized.

Show comment
Hide comment
@joelpurra

joelpurra May 10, 2016

Owner

I played with the new version a bit, and it's much improved.

Glad to hear!

I looked through some of the logs for my caching name server for some good domains to try. truste.com was interesting because they seem to have RRSIG records, but there don't seem to be any DS records for the domain. I wonder how they expect that to work.

Have a similar problem for joelpurra.com and joelpurra.se -- they are using the same registrar, but only .se is properly signed. Guess both truste.com and I should change registrar...

With respect to CNAME: There seem to be lots of DNSSEC-supporting domains that CNAME to other domains that aren't. But that isn't universally true: www.ietf.org CNAMEs to something in cloudflare-dnssec.net, which is also DNSSEC-protected (yay).

Yup -- www.ietf.org is now un-shamed =)

There seems to be a "winking acceptance" of CNAMEs that go to unsigned domains, but I think it would be better if we could give only half credit for that since it isn't really secure.

I'd rather shame them. The current implementation shames such domains, and at least gives an indication why. Are there any corner-cases? Do you know of a good article about this? Could write something and link to it.

The same goes for MX records pointing elsewhere.

Do you think it would be worth looking up the MX address as well? Can see this add a bunch of complexity, if it's not pointing directly to an MX address but to a chain of CNAMEs. This might also be something which needs to be explained in the UI, perhaps displaying the full chain -- and that sounds like it might be out of scope. Is there another tool doing this?

Owner

joelpurra commented May 10, 2016

I played with the new version a bit, and it's much improved.

Glad to hear!

I looked through some of the logs for my caching name server for some good domains to try. truste.com was interesting because they seem to have RRSIG records, but there don't seem to be any DS records for the domain. I wonder how they expect that to work.

Have a similar problem for joelpurra.com and joelpurra.se -- they are using the same registrar, but only .se is properly signed. Guess both truste.com and I should change registrar...

With respect to CNAME: There seem to be lots of DNSSEC-supporting domains that CNAME to other domains that aren't. But that isn't universally true: www.ietf.org CNAMEs to something in cloudflare-dnssec.net, which is also DNSSEC-protected (yay).

Yup -- www.ietf.org is now un-shamed =)

There seems to be a "winking acceptance" of CNAMEs that go to unsigned domains, but I think it would be better if we could give only half credit for that since it isn't really secure.

I'd rather shame them. The current implementation shames such domains, and at least gives an indication why. Are there any corner-cases? Do you know of a good article about this? Could write something and link to it.

The same goes for MX records pointing elsewhere.

Do you think it would be worth looking up the MX address as well? Can see this add a bunch of complexity, if it's not pointing directly to an MX address but to a chain of CNAMEs. This might also be something which needs to be explained in the UI, perhaps displaying the full chain -- and that sounds like it might be out of scope. Is there another tool doing this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment