0

RFC 6698 states that a TLSA record should be ignored unless it can be verified with DNSSEC. For clients using a built-in stub resolver, that means checking the AD bit on the response (and trusting that the administrator has pointed the resolver at a non-compromised DNSSEC capable resolver).

However, in many organizations that resolver also hosts internal views of the organization's own zones and will reply with an AA flag (and no AD flag). Does that mean that it is useless to put a TLSA record in such a zone because clients are prohibited from trusting them? Or can I expect that the client (browser) will do its own DNSSEC validation for TLSA records, using non-recursive queries and treating the local resolver as any other authoritative server?

(In the specific case I'm looking at we are trying to access an external service using an internal name, and for business reasons we cannot add the internal name to the TLS certificate on the external server).

Running a full caching resolver on all client machines would be a solution, but not feasible for us. I am aware that TLSA checking is not even active in most browsers, but I'd like to be prepared for when it is.

LHMathies
  • 113
  • 4
  • This related https://serverfault.com/questions/546829/bypass-dnssec-for-local-stub-zones may help. – Patrick Mevzek Dec 04 '17 at 16:39
  • The RFC is clear that bogus or missing DNSSEC validation means the application needs to refrain to use the TLSA record, hence it is useless to publish it. I fear you can not expect the client to do its own DNSSEC validation, in the sense that it would be hard to guarantee this for all browsers in all versions and all OS you need to use. Even if they did it means you need to have internal DNSSEC enabled zones too... Can't you instead proxy the external service internally and set TLS termination there? – Patrick Mevzek Dec 04 '17 at 16:48
  • Also note section 9.3 of the RFC: `For this reason, DNSSEC validation is best performed on-host, even when a secure path to an external validator is available.` – Patrick Mevzek Dec 04 '17 at 16:51
  • @PatrickMevzek, thanks for the comments. I am aware of the discussion in section 8.3, but with the autoritative+resolving DNS server under our own administrative control and on our internal network, if it was compromised we would have more serious problems. – LHMathies Dec 05 '17 at 12:52
  • As to the linked answer, it's out of date because BIND now has negative trust anchor -- and it so happens that the DNS server in my case is on Windows Server 2012, however. (I think the analysis is wrong too). – LHMathies Dec 05 '17 at 13:49
  • Also I think you are right, with the uptake of TLSA in browsers seemingly at a standstill it is sort of pointless to look for a technical fix for the DNSSEC question -- the most feasible solution would be to point the internal record at a proxy and configure it to demand the certificate that the real server actually sends. That still leaves the problem of external access, where DNSSEC should work but the browsers would ignore TLSA anyway. – LHMathies Dec 05 '17 at 14:03

0 Answers0