feat(NODE-6289): allow valid srv hostnames with less than 3 parts

[aditi-khare-mongoDB]

Description

Downstream changes for DRIVERS-2922 (PR).

What is changing?

• Remove logic asserting that SRV URIs need 3 parts
• When we check if a returned address matches its parent SRV, an SRV with <3 parts must assert that the returned address contains an additional domain level
• Add in prose tests.

Is there new documentation needed for these changes?

No

What is the motivation for this change?

Do not throw an error on valid URI formats pre-DNS resolution, and require stricter domain matching post-DNS resolution.

Release Highlight

Allow SRV hostnames with less than three . separated parts

In an effort to make internal networking solutions easier to use like deployments using kubernetes, the client now accepts SRV hostname strings with one or two . separated parts.

await new MongoClient('mongodb+srv://mongodb.local').connect();

For security reasons, the returned addresses of SRV strings with less than three parts must end with the entire SRV hostname and contain at least one additional domain level. This is because this added validation ensures that the returned address(es) are from a known host. In future releases, we plan on extending this validation to SRV strings with three or more parts, as well.

// Example 1: Validation fails since the returned address doesn't end with the entire SRV hostname
'mongodb+srv://mySite.com' => 'myEvilSite.com' 

// Example 2: Validation fails since the returned address is identical to the SRV hostname
'mongodb+srv://mySite.com' => 'mySite.com' 

// Example 3: Validation passes since the returned address ends with the entire SRV hostname and contains an additional domain level
'mongodb+srv://mySite.com' => 'cluster_1.mySite.com' 

Double check the following

• Ran npm run check:lint script
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[dariakp]

@aditi-khare-mongoDB @W-A-James Can we confirm the failing tests are all accounted for?

[aditi-khare-mongoDB]

@dariakp Seems like the two red failing tests are flaky. I doubt the purple failures would contain any failures if they weren't system failures. For example, 5.0-node-latest-server fails but not 4.0-node-latest or 6.0-node-latest, which makes me assume 5.0-node-latest would pass if not for the CI issues.

[W-A-James]

Failing tests are unrelated known flaky tests

[dariakp]

LGTM with respect to my comments

LGTM was given by this reviewer