-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
Use Case
As a... Node.js Driver Developer
I want... to refactor the driver's DNS layer to rely on the generic dns.promises.resolve(hostname, rrtype) method.
So that... I can delete the disparate logic handling specific methods (resolveSrv, resolveTxt, resolve4, resolve6) and support future "Pluggable I/O" providers with a significantly smaller API surface.
User Experience
- Code Reduction: The driver's internal DNSProvider interface simplifies from having 5+ methods to essentially 2:
-
- resolve(name, type): Handles SRV, TXT, and explicit A/AAAA queries via the network.
- lookup(name): Handles the initial connection address resolution (respecting OS hosts file).
Dependencies
- This is a direct prerequisite for Milestone 1 (Pluggable I/O). The defined NetworkInterface in the design document relies on this unified DNS shape.
Risks/Unknowns
- Node.js resolve(name, 'A') is not equivalent to lookup(name). The former ignores the OS hosts file; the latter respects it. Read more here
- Risk: If we blindly replace lookup() with resolve(..., 'A'), local development setups (e.g., mapping db.local in /etc/hosts) will break.
- Mitigation: The unified interface must still distinguish between "System Resolution" (lookup) and "Network Resolution" (resolve), OR we must implement a fallback mechanism.
Acceptance Criteria
Implementation Requirements
- Identify all usages of resolveSrv, resolveTxt, resolve4, and resolve6.
- Replace them with the generic dns.promises.resolve(hostname, rrtype).
- Ensure that errors thrown by the generic resolve method are caught and handled consistently (Node.js generic resolve might return different error codes than specific helper methods in some edge cases).
Example: Change resolveSrv(name) to resolve(name, 'SRV').
Testing Requirements
- All tests pass.
Documentation Requirements
- Release note
Follow Up Requirements
- N/A