DRIVERS-3329: Configurable DNS domain validation for SRV records

[sleepyStick]

Please complete the following before merging:

• Is the relevant DRIVERS ticket in the PR title?

• Update changelog.
• Test changes in at least one language driver.
  Python PR: PYTHON-5814 Configurable DNS domain validation for SRV records mongo-python-driver#2868
• Test these changes against all server versions and topologies (including standalone, replica set, and sharded
  clusters).

[rozza]

It looks good, I have one comment about if an invalid srvAllowedHostsSuffix should throw an error explicitly? (if so should we update the yml?)

Also the yml and json has diverged for srvAllowedHostsSuffix-without_dot_pass - which is probably the lint error.

[rozza]

Just to clarify, if a host is invalid eg: ..example.com should this error or just return an empty list of hosts?

[sleepyStick]

oh good question, my current implementation has it eventually erroring (with a configuration error) when the driver goes to validate the SRV hosts -- i didn't add a new "check valid host" type of function. (though this probably wouldn't be too hard with some regex? if you think it'd be beneficial to add something like this.) My initial thought process was this new parameter is just a user configurable way to denote what the domain should be (as opposed to the previous, now default, logic) -- they should know what they're doing if they're using this param and if they happened to make a typo / silly mistake, the existing "invalid SRV host" error message that occurs when there is an invalid host given the previous logic would still apply.

[rozza]

I think the eventually error part will cover this, so no need for a regex. I can never understand regexes and someone always seems to find a usecase where the regex fails where it shouldn't!

[matthewdale]

Optional: Consider linking to the Querying DNS section, which is where the DNS validation is described.

[sleepyStick]

added! thanks!

[codeowners-service-app]

Assigned vector-of-bool for team dbx-spec-maintainers-connection-string because aclark4life is out of office.

[matthewdale]

Looks good! 👍

[aclark4life]

Looks like the convention in yml is no quotes around uri

[aclark4life]

Missing space

[aclark4life]

Also a convention apparently is new lines at the end of yaml files.

[aclark4life]

Pending nit fixes LGTM

[ajcvickers]

Setting srvAllowedHostsSuffix to a public suffix neuters SRV anti-spoofing, turning mongodb+srv:// into an unbounded DNS redirect. A merely broad private domain doesn't make it unbounded, but widens the redirect to anywhere under that domain. There is no PSL/minimum-label guard to prevent either. Example:

Preconditions:

• Misconfiguration. App sets a too-broad suffix:
  mongodb+srv://mycluster.mongodb.example.com/?srvAllowedHostsSuffix=.com
• Attacker runs a malicious/compromised resolver, or poisons the cache. (DNSSEC is not enforced per SECURITY-488).
• Attacker obtains a CA-valid cert for a domain they own.

Step-by-step:

• Client SRV-queries _mongodb._tcp.mycluster.mongodb.example.com.
• Attacker forges the SRV response: target db1.attacker-evil.com:27017.
• Suffix validation passes (db1.attacker-evil.com ends in .com).
• mongodb+srv forces TLS; the client validates the cert against the SRV-returned name (db1.attacker-evil.com), not the typed name (mycluster.mongodb.example.com).
• Attacker owns that name and holds a valid cert → TLS verification passes → client connects to the attacker's server.

[ajcvickers]

I think the parsing needs to be much better specified and tested. It's important to understand what DNS entries allow and how to safely handle these things. These should be specified at the spec level, so all drivers will get the parsing correct. For example, most of these are not specified or tested:

• DNS is case-insensitive. (Also, ASCII-only case-folding.)
• SRV targets often return trailing dots. For example: host.citi.net. These must be normalized.
• IDN / punycode / homographs. Don't compare raw Unicode.
• Probably more... (I'm not an expert, but the above are the obvious ones.)

There needs to be much better test coverage here.

[ajcvickers]

• When the suffix is set, does the "fewer than three parts" means "at least one more domain level" still apply?
• SRV polling reuses the same domain-matching and is not touched by this PR, nor mentioned in the decision doc. This seems fundamentally broken.
• How does setting the new option Interact with srvMaxHosts or a custom srvServiceName?

[ajcvickers]

From going through the history here, it seems we have acknowledged the security concerns but consciously accepted them and shifted the risk to the customer to meet customer demand. This is a weak security posture: it puts a lot of responsibility on the customer to get everything right, and rejects the safer alternatives (CNAMEs, RFC 4985 SANs).

If we are going to do this, then the risks I have highlighted need to be made front and center so that anyone opting into this is aware that it relaxes the naming-layer anti-spoofing defense and considerably increases their attack surface.

Beyond this, I think there needs to be a product-level guard against the worst misconfigurations (e.g. rejecting public-suffix values) and a fully specified safe-configuration recipe, so "the customer's responsibility" is achievable rather than a trap.