-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(NODE-6289): allow valid srv hostnames with less than 3 parts #4197
base: main
Are you sure you want to change the base?
Conversation
bda0451
to
586f7c0
Compare
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
test/integration/initial-dns-seedlist-discovery/initial_dns_seedlist_discovery.prose.test.ts
Outdated
Show resolved
Hide resolved
@aditi-khare-mongoDB @W-A-James Can we confirm the failing tests are all accounted for? |
@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. |
@@ -127,8 +127,11 @@ export class SrvPoller extends TypedEventEmitter<SrvPollerEvents> { | |||
|
|||
const finalAddresses: dns.SrvRecord[] = []; | |||
for (const record of srvRecords) { | |||
if (matchesParentDomain(record.name, this.srvHost)) { | |||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find a kickoff document for this work, so I am not sure if this is something that has already been discussed, but how frequently is this function invoked? Is it in the hot path for anything? This construction, while cleaner, is less performant (since try catch is more expensive than a simple if/then, and the additional function call for the no-op may or may not get optimized).
src/utils.ts
Outdated
normalizedAddress.split('.').length <= normalizedSrvHost.split('.').length | ||
) { | ||
// TODO(NODE-3484): Replace with MongoConnectionStringError | ||
throw new MongoAPIError('Server record does not have least one more domain than parent URI'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the grammar on this needs some adjustment - could you double check the wording? I think it was probably meant to be Server record does not have at least one more domain level than parent URI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch!
src/utils.ts
Outdated
throw new MongoAPIError('Server record does not have least one more domain than parent URI'); | ||
} | ||
if (!addressDomain.endsWith(srvHostDomain)) { | ||
// TODO(NODE-3484): Replace with MongoConnectionStringError |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NODE-3484 is about MongoParseError specifically, is that the right ticket for this work and do we definitely want a more specific error here? Even if so, I am not sure that we'd want to call it "MongoConnectionString", since, if I understand correcty. we are testing resolved records and not something that is specified in the connection string itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed the TODO, it's a remanent from when this function was first implemented, and the ticket has sat in the backlog for years at this point. More importantly, it wouldn't be a connection string error technically, more of a 'SRV resolution returns invalid values' error, so i think MongoAPIError is sufficient here.
import { topologyWithPlaceholderClient } from '../../tools/utils'; | ||
|
||
describe('Initial DNS Seedlist Discovery (Prose Tests)', () => { | ||
context('1. When running validation on an SRV string before DNS resolution', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For easy audit purposes (e.g. in evg), we should match the number and title of the prose test in the context block and capture the full instructions text in comments.
@@ -939,7 +939,7 @@ describe('driver utils', function () { | |||
}); | |||
}); | |||
|
|||
describe('matchesParentDomain()', () => { | |||
describe('checkParentDomainMatch()', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we add analogous tests for what happens when we have a trailing dot on a 2- or 1- part srv?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! Just added them in
src/utils.ts
Outdated
// Remove trailing dot if exists on either the resolved address or the srv hostname | ||
const normalizedAddress = address.endsWith('.') ? address.slice(0, address.length - 1) : address; | ||
const normalizedSrvHost = srvHost.endsWith('.') ? srvHost.slice(0, srvHost.length - 1) : srvHost; | ||
|
||
const allCharacterBeforeFirstDot = /^.*?\./; | ||
const srvIsLessThanThreeParts = srvHost.split('.').length < 3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the correct check? I would think we are interested in checking whether the normalized host has fewer than 3 parts, since I don't think we want to consider the trailing dot on a 2- part host any differently, if I understand correctly. If you agree, could you make sure that there are new tests in the unit test section that fail with the code as it currently is and pass when the code is updated to check the normalized part count instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, you're right, I've added in a new test that would have failed otherwise (the 'extra domain level' one) and fixed a typo in these section.
cdc2501
to
79f41e4
Compare
d17f346
to
eafaf61
Compare
Description
Downstream changes for DRIVERS-2922 (PR).
What is changing?
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 partsThe client now accepts SRV hostname strings with one or two
.
separated parts.For example, the following code no longer throws an error.
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.
Double check the following
npm run check:lint
scripttype(NODE-xxxx)[!]: description
feat(NODE-1234)!: rewriting everything in coffeescript