0

When setting a DNS SRV record like _service._proto.example.com. IN SRV 0 0 443 service.example.com., why has the TLS certificate name on service.example.com:443 to be example.com and not service.example.com?

I've read on what names for TLS certificates when using SRV records that it's to prevent man in the middle attacks but I'm not sure to understand why: MITM attacks on the DNS would be prevented using DNSSEC.

The problem whith this design is the following. Consider one has the following DNS SRV records:

_service1._proto.example.com. IN  SRV 0 0 443 service1.example.com.
_service2._proto.example.com. IN  SRV 0 0 443 service2.example.com.
_service3._proto.example.com. IN  SRV 0 0 443 service.provider.com.

One has to give a TLS certificate which name is example.com to the teams managing service1 and service2 and to the external service provider's team. This way, a compromise of any of the services can lead to the compromise of all the services.

This seems like a flaw in the design of DNS SRV records. Is it?

Yann
  • 1
  • 1

1 Answers1

0

this could be implementation dependent answer. But in general it would work based on the options used for the "redirection" in DNS :

  • CNAME : The client's request is redirected - the originally requested FQDN would be presented in the destination certificate as the redirection is done during the original request.

  • SRV record (the use case you are asking) - there WOULD be subsequent query to the destination provided in SRV record so only final destination (FQDN from SRV record) would be requested in the cert as it is not the same request and subsequent request target directly the new FQDN.

This behaviour can be seen for example in case of autodiscovery feature on Exchange server. In case you have several domains hosted on one Exchange, once the autodiscovery feature is set up using SRV record only own FQDN is required in the cert on the server (so not list of all hosted domains).

The DNSSEC "requirements" here is due to this behaviour - as there is subsequent query once the attacker can pass the own SRV record in the DNS answer the destination can be any FQDN so the attacker can easily get proper trusted certificate for own domain pointed by the injected SRV record.

In case of not fully correct implementation the client side can use the information from SRV just to discover the endpoint for the query (like CNAME record) and keep original FQDN in the request. In that case the original FQDN could be needed - the present of the original FQDN in the cert on the destination system is just workaround to cover improper implementation of SRV record on the client side...

Kamil J
  • 1,767