[DRIVERS-2057] Determine how drivers should handle trailing dots in SRV results Created: 27/Mar/19  Updated: 31/Mar/22

Status: Backlog
Project: Drivers
Component/s: Initial DNS Seedlist Discovery
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Jeremy Mikola Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to DRIVERS-2058 Test two part hostname with trailing ... Backlog
is related to SERVER-31965 Mongo Shell does not handle FQDN from... Closed
is related to CDRIVER-3043 valid_hostname() should not rejects s... Closed
is related to DRIVERS-2087 Test parsing of hosts with trailing dots Backlog
is related to DRIVERS-2123 Add justification for host/domain req... Backlog
Driver Changes: Needed

 Description   

Per SPEC-1264, drivers will test that trailing dots are permitted in host names. As this relates to initial DNS seedlist discovery, we should permit trailing dots in SRV results but must also decide how, if at all, trailing dots factor in to matching domain suffixes between the original service (host is URI string) and SRV results.

In SERVER-31965, a fix for the mongo shell's validation of certificates entailed stripping a trailing dots from SRV results; however, I'm not sure if that's relevant to domain suffix matching for drivers.



 Comments   
Comment by ADAM Martin (Inactive) [ 28/Mar/19 ]

Spencer's assessment appears to be correct.

Comment by Spencer Jackson [ 28/Mar/19 ]

1) All SRV results are fully qualified. SRV results implicitly have a dot at the end. Drivers probably should be able to accept dots at the end of connection string hosts.
2) Yes, but this is less scary than it sounds. CAs sign certificates for names that they observe within some namespace. Clients opening connections to some name will observe a certificate. If the client's original DNS lookup obtains a name from the global namespace, there's no problem with CA having issued a certificate for a global name without a dot. If the client's DNS lookup obtains a name from a non-global scope, then for the certificate to be valid, the client and the CA have to have been using names from the same scope.
If the client intended to connect to a global name, but due to a lack of qualification actually wound up connecting to a name from a scope, AND was given a valid certificate, then the CA colluded with the DNS operator and the host. But, CAs are by definition trusted.
3a) In your example, I believe that if you perform an SRV lookup on <foo.example.com.>, the result <a.example.com> should match, because all SRV results are fully qualified.
3b) In the case where you perform a lookup on an unqualified name, I believe it is fine to accept the results in either case, because the results are always qualified. You are relying on your CA's view of the DNS topology to enforce that both names are in the same namespace.

CC adam.martin who implemented this in the shell, and has feelings about DNS RFCs. Does this response sound right?

Comment by Jeremy Mikola [ 28/Mar/19 ]

oleg.pudeyev: Thanks for the link. This definitely seems related to this issue, as well as SPEC-1264 (for general connection string parsing).

spencer.jackson: Can you chime in on this issue and answer a few outstanding questions?

  • Would drivers do well to accept trailing dots in connection string hosts and SRV results (assuming they do not today)?
  • Assuming drivers do accept trailing dots, would they need a similar solution as SERVER-31965 as it relates to certificate validation?
  • Are the comparison examples and reasoning in my previous comment sound?
  • Are there any other security concerns we may be missing in this conversation? I don't want to run afoul of SECURITY-488.
Comment by Oleg Pudeyev (Inactive) [ 28/Mar/19 ]

jmikola There is also https://jira.mongodb.org/browse/SPEC-1228?filter=25987 which may be relevant to the work here.

Comment by Jeremy Mikola [ 28/Mar/19 ]

If we ensure that drivers allow a trailing dot in host names, this will likely require some changes to the current logic for enforcing a common suffix between the service host name and SRV results. In the case of libmongoc, which doesn't yet permit trailing dots (CDRIVER-3043), a suffix is extracted from the service as the substring following the second-to-last dot through the end of the string. If libmongoc were to start allowing trailing dots, this could lead to .com. being parsed as the suffix for foo.example.com. when we would actually want to use .example.com..

Therefore, drivers may need to alter their suffix extraction logic to account for the optional trailing dot. With that addressed, I think the following logic would apply:

  • Service with trailing dot: foo.example.com.
    • SRV result a.example.com does not match (without trailing dot, resolution may add a suffix from the DNS searchlist)
    • SRV result a.example.com. does match
  • Service without trailing dot: foo.example.com
    • SRV result a.example.com does match. While unlikely, we can't be certain if resolution will add a suffix from the DNS searchlist to either the service or SRV result. We also can't be sure that the same suffix will be used for both hosts. That said, this is the most common case and we should attempt to match as-is.
    • SRV result a.example.com. does not match
Generated at Thu Feb 08 08:24:37 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.