allow custom dns query

[datianshi]

What does this PR do? / Related Issues / Jira

Checklist

• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have tested the functionality against gcp / aws, it doesn't cause any regression
• I have added execution results to the PR's readme

Reviewer's Checklist

• (This needs to be done after technical review) I've run the branch on my local, verified that the functionality is ok

How to test this PR locally / Special Instructions

Logs

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign rafael-azevedo for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @datianshi. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[abyrne55]

/ok-to-test

[openshift-ci]

@datianshi: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 25.08%. Comparing base (8024971) to head (b7a3628).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #258      +/-   ##
==========================================
+ Coverage   24.85%   25.08%   +0.22%     
==========================================
  Files          23       24       +1     
  Lines        1738     1802      +64     
==========================================
+ Hits          432      452      +20     
- Misses       1284     1327      +43     
- Partials       22       23       +1     

Files	Coverage Δ
pkg/verifier/aws/aws_verifier.go	35.94% <ø> (ø)

... and 5 files with indirect coverage changes

[abyrne55]

Hi @datianshi, thanks for the PR! My understanding of these OSD/ROSA docs is that users must not use custom DNS resolvers during cluster installation (but they can set them up after cluster installation completes, if they wish). IOW, a cluster's bootstrap/control-plane nodes can only use "AmazonProvidedDNS" a.k.a. Route53 Resolver until cluster installation is complete.

osd-network-verifier's goals include simulating a "mid-cluster-install bootstrap/control-plane node" as closely as possible while still complying with OSD/ROSA docs. It would seem that this PR does not serve that goal, as it would give the verifier the power to do something (make queries to a custom DNS resolver) that the OSD/ROSA docs say a cluster's nodes cannot do — at least, not during cluster installation/in-flight checks, which is when the temporary security group that this PR modifies would be used.

I'll note that the network verifier can use existing security groups if specified using the --security-group-ids flag or SecurityGroupIDs field of the ValidateEgressInput struct. You could accomplish what appears to be the goal of this PR by creating a security group that allows egress to port 53/udp, and then run the verifier like the following:

./osd-network-verifier egress --subnet-id=[your-target-subnet-id] --security-group-ids=[the-port-53-security-group-id] --force-temp-security-group

(I added --force-temp-security-group because otherwise the verifier doesn't create any security groups when an existing one is specified)

Of course, I'm open to discussion 🙂. Please let me know if I'm misunderstanding the linked docs or the goals of this PR

[datianshi]

@michaelryanmcneill

[michaelryanmcneill]

@abyrne55 after today's discussion in the MCS call, our documentation is being updated to properly reflect that it is supported to use custom DHCP options. As such, I think this fix is acceptable and would ensure we are catching any sort of DNS resolution related problems for customers operating with custom DHCP options.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale