Enabling DNSSEC prevents access to bank.barclays.co.uk

[UniverseXXX]

Hi, I’m running stubby on Lede/OpenWRT. Once the DNSSEC is enabled in config, I cannot access bank.barclays.co.uk (in web browser or using native Barclays iOS app) anymore. Please advise if there is something needs to be done or that’s a bug? Thanks.

resolution_type:GETDNS_RESOLUTION_STUB

dns_transport_list:
  - GETDNS_TRANSPORT_TLS

tls_authentication: GETDNS_AUTHENTICATION_REQUIRED

tls_query_padding_blocksize: 256

edns_client_subnet_private : 0

idle_timeout: 10000

dnssec_return_status: GETDNS_EXTENSION_TRUE
#dnssec_trust_anchors: "/etc/unbound/getdns-root.key"

listen_addresses:
  - 127.0.0.1@5453
  -  0::1@5453

round_robin_upstreams: 0

upstream_recursive_servers:

#------CloudFlare----------------------------------------------------
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"

  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

#------QUAD 9-------------------------------------------------------
# # Quad 9 IPv6
  - address_data: 2620:fe::fe
    tls_auth_name: "dns.quad9.net"

# # Quad 9 IPv4
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"

#------SurfNet/Sinodun-----------------------------------------------
# The Surfnet/Sinodun servers
  - address_data: 145.100.185.15
    tls_auth_name: "dnsovertls.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=

  - address_data: 145.100.185.16
    tls_auth_name: "dnsovertls1.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=

#------GetDNSAPI-----------------------------------------------------
# # The getdnsapi.net server
  - address_data: 185.49.141.37
    tls_auth_name: "getdnsapi.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=

#------SecureDNS.eu--------------------------------------------------
# # Securedns.eu
  - address_data: 146.185.167.43
    tls_auth_name: "securedns.eu"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 2EfbwDyk2zSnAbBJSpCSWZKKGUD+a6p/yg2bxdC+x2A=

#------NS DNS Privacy------------------------------------------------
  - address_data: 94.130.110.185
    tls_auth_name: "ns1.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY=
  - address_data: 94.130.110.178
    tls_auth_name: "ns2.dnsprivacy.at"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg=

[wtoorop]

bank.barclays.co.uk. is a CNAME to bank.glbaa.barclays.com. The nameservers of bank.glbaa.barclays.com. can only be discovered when following delegations since they appear to be quite broken (i.e. don't respond to anything else besides A and AAAA queries and respond quite badly to different EDNS0 options as well.

;; AUTHORITY SECTION:
glbaa.barclays.com. 900 IN  NS  ns22.barclays.net.
glbaa.barclays.com. 900 IN  NS  ns21.barclays.com.
glbaa.barclays.com. 900 IN  NS  ns24.barclays.net.
glbaa.barclays.com. 900 IN  NS  ns23.barclays.com.

;; ADDITIONAL SECTION:
ns24.barclays.net.  600 IN  A   157.83.126.246
ns23.barclays.com.  900 IN  A   157.83.126.245
ns21.barclays.com.  900 IN  A   157.83.102.245
ns22.barclays.net.  600 IN  A   157.83.102.246

For Stubby, as a stub trying to do DNSSEC from the leaf up to the root (instead of an iterative recursive which would iterate from the root down to the leaf) this is (currently) hampering getting the validation chain. A slightly different approach to chasing DNSSEC would overcome this particular problem. Stubby (or the underlying getdns) should query for DS and DNSKEY of the top-level and the second level domain immediately (it already does for the root). Then it would have discovered that barclays.com. is insecure and would have stopped pursuing.

It is also possible to provide negative trust anchor (put this in your trust anchor file:)

glbaa.barclays.com. DNSKEY  257 3 0 Aa==

However, this still schedules the DS lookup for glbaa.barclays.com. so you have to wait for the timeout and then you do get the answer (but too late probably). This is a bug which needs to be fixed.

You could also let an unbound forward to stubby, and let unbound do DNSSEC validation and get caching as an extra as well. This setup is quite popular. In theory it should be possible to do this wiring within stubby too (because it has access to libunbound), but that also we still have to make.

[UniverseXXX]

thanks @wtoorop I'm already using unbound with dnssec option enabled. Then, I will disable it in stubby until it's fixed.

[ArchangeGabriel]

@UniverseXXX There is no point in having DNSSEC in Stubby if you use Unbound, you’re only slowing your DNS resolution, that’s all. ;)

[hanvinke]

Even with Unbound as only DNS resolver I also have issues with the website.

"An error occurred during a connection to bank.barclays.co.uk. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP "

According to a similar website it can be solved by allowing Firefox (or other browser) to fallback to TLS1.0 or otherwise force TLS 1.0 (i.e. set the maximum to 1.0) :

In order to change your Firefox Configuration please do the following steps :+1:

1. In the Location bar, type about:config and press Enter. The about:config "This might void your warranty!" warning page may appear.
   2. Click I'll be careful, I promise! to continue to the about:config page.
   3. Change security.tls.version.fallback-limit = 1

[ArchangeGabriel]

@hanvinke This is not the default value, you forced it to not accept TLS1.0 in the first place.

[hanvinke]

According to http://kb.mozillazine.org/Security.tls.version.* security.tls.version.fallback-limit = 1 means: TLS 1.0 is the minimum required / maximum supported encryption protocol. So as far as I understand it does not force the browser to not accept TLS 1.0.

BTW the given solution worked for me, here is a screenshot of the website reloading after the change: Had to do a refresh twice, due to cookies policy of barclays website.

nmap shows only TLS 1.0 cipher support:

Here is result from https://www.ssllabs.com/ssltest/analyze.html?d=bank.barclays.co.uk: TLS 1.2 also supported according to ssllabs.

Default in Firefox is '3' which states that TLS 1.2 is the minimum required / maximum supported encryption protocol.

Most probably cause of the problem is, in my opinion, the TLS_FALLBACK_SCSV support on their website. When using a newer version of Firefox (50 and up) and if for some reason it is unable to connect with TLS 1.2, the browser cannot fallback to TLS 1.0.

@ UniverseXXX Blame barclays for their limited protocol support, I hope my solution works for you.

[UniverseXXX]

Thanks a lot, @hanvinke I’m now using unbound DNSSEC only and it seems working fine for me (in Safari and application).

[hanvinke]

Nice, BTW the screenshot from the bank was taken with Unbound as caching server and Stubby running. Should work also. After accepting new cookie it even accepted the default setting of security.tls.version.fallback-limit = 3

[UniverseXXX]

I’ve updated getdns to 1.4.1-2 yesterday and it seems that the issue has gone. I’m now able to resolve the address in both browser and the app. Not sure what exactly was fixed as couldn’t find release notes.

[wtoorop]

@UniverseXXX The issue is not gone. I've not created a workaround yet and the ns2[1-4].barclays.com nameservers are still broken. It must be something different in your environment.

[UniverseXXX]

@wtoorop I haven’t changed anything else. Will continue testing than.

[hanvinke]

I can confirm that the website is up. Probably this morning it worked because of cached records coming from old servers. MXToolbox.com gave earlier the error message: Bad Glue Detected. Now it says everything is OK.

[hanvinke]

For the record: bank.barclays.co.uk does not have DNSSEC support. But missing glue records can even cause name resolution failure. Since all other websites without DNSSEC support cause no error with the same settings in stubby.yml, maybe there isn't any problem with Stubby at all.

[wtoorop]

@hanvinke it is a problem with getdns (an thus Stubby). getdns does DNSSEC chasing (instead of iterating from the root up like a recursor would). Where a DNSSEC iterator would have discovered that barclays.com is insecure and would have stopped pursuing DNSSEC status, getdns starts at the authoritative nameservers for glbaa.barclays.com. which do not respond to anything besides A or AAAA queries and even then you're not allowed to use some edns0 options.

This is caused by some non-standards compliant middle-ware box (DNS load-balancer or so). This is quite commonly seen, but not at the top-level domain level (because then they would have broken normal recursive resolvers too), so the best workaround is to do the DS query from getdns for the second-level domain immediately (when chasing), and stop if proof of insecurity can be determined at that level already.

In fact, since the CNAME from bank.barclays.co.uk. to bank.glbaa.barclays.com. was already insecure, there was no reason for getdns to chase the target of that CNAME either. DNSSEC chasing could have stopped earlier even without the method described above.

I will tend to this issue soonish. I have discovered some other DNSSEC issues too (introduced when working on CVE-2017-15105 mitigation) and can take along this issue at the same time.

[hanvinke]

@ wtoorop Thank you very much, that is a very clear explanation. As I understand with my limited knowledge, getdns does not ask the DNSSEC data via the DO bit ?! So when 'dnssec_return_status: GETDNS_EXTENSION_TRUE' is enabled in the config I suppose that a query is automatically sent with an AD bit (to express getdns' interest in the value of the AD bit in the response). But apparently the value for 'getdns.BAD_DNS_CNAME_IN_TARGET' in the extention 'getdns.EXTENSION_TRUE' is somehow not set. Maybe because it is not getting the result back it is expecting (=with DNSSEC data) it treats the result as BOGUS data instead of concluding that there is no DNSSEC support at all? Just a wild guess, I hope it has nothing to do with the way getdns treats BOGUS data. (I am trying to be helpful here, but most probably wasting your time, sorry)

[hanvinke]

@ wtoorop I initially thought of a different cause. Maybe because the bank decided to add some extra servers, to balance their load. And issued an IP-change to ICANN. But their name-servers take time for that. So the bank knows of course that the IP-address has changed but not the rest of the world yet. The bank also decided to redirect all the traffic to the new server. That is no problem as long as there is no additional ip-check. With bad glue the IP-address is wrong (the correct new one not yet known to all nameservers). So the CNAME is not the problem, but the associated ip-address. Without DNSSEC-check the resolver does not matter been redirected to another IP-address. But with an additional DNSSEC check it detects been connected to the wrong IP-address and disconnects and retries. So any resolver with DNSSEC gets trapped in a loop.

[eccgecko]

@ArchangeGabriel Would that be the same if I am using pihole (dnsmasq) with the stubby resolver? When setting up, I assumed that for DNSSEC to work correctly I had to enable it on both the stubby resolver and in the pihole settings. Are you saying I should disable DNSSEC in the config stubby.yml file, and DNSSEC will still work correctly?

[ArchangeGabriel]

@eccgecko Yes, DNSSEC in Stubby is for Stubby use only (i.e. Stubby will do additional queries to validate answers with DNSSEC). Anything using Stubby and doing DNSSEC on its own will do the relevant queries through Stubby and will work.

[eccgecko]

@ArchangeGabriel Great, thanks for the tip! 😃

[wtoorop]

Fixed in the getdns-1.4.2 release