Skip to content
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

Bug 1851541: Correctly handle requests for ipv4/ipv6 records #1870

Conversation

cybertron
Copy link
Member

Previously the ingress record was hard-coded to be an A record, which
does not work when deploying with an ipv6 ingress VIP. While fixing
that, an issue with the api and api-int records was also exposed.

According to RFC 4074, when a query for a record comes in that asks
for the wrong type of record (i.e. asking for an A record when only
a AAAA record exists), the server should return NOERROR with an
empty list of records. This indicates to the client resolver that
a record of that name exists, but not with that type.

For our purposes, it was necessary to convert all of the records to
use the template plugin in order to get this behavior. The hosts
plugin previously used for the api records does not correctly handle
requests for the wrong record type, at least with the fallthrough
option that we also need. The file plugin, which does correctly
handle requests for the wrong record type, has a different issue.
We want to allow external records in the same subdomain (and this is
necessary for development purposes), but there is no way to make
the file plugin forward requests it can't handle.

To make the template plugin behave correctly, two entries are needed
for each record: one with the correct type and the appropriate answer,
and one with the incorrect type and an empty answer. This gets us
RFC-compliant behavior while still allowing fallthrough for requests
that are not present in the local server.

This change requires new fields from baremetal-runtimecfg that are
added in openshift/baremetal-runtimecfg#60.

- What I did

- How to verify it

- Description for the changelog

Previously the ingress record was hard-coded to be an A record, which
does not work when deploying with an ipv6 ingress VIP. While fixing
that, an issue with the api and api-int records was also exposed.

According to RFC 4074, when a query for a record comes in that asks
for the wrong type of record (i.e. asking for an A record when only
a AAAA record exists), the server should return NOERROR with an
empty list of records. This indicates to the client resolver that
a record of that name exists, but not with that type.

For our purposes, it was necessary to convert all of the records to
use the template plugin in order to get this behavior. The hosts
plugin previously used for the api records does not correctly handle
requests for the wrong record type, at least with the fallthrough
option that we also need. The file plugin, which does correctly
handle requests for the wrong record type, has a different issue.
We want to allow external records in the same subdomain (and this is
necessary for development purposes), but there is no way to make
the file plugin forward requests it can't handle.

To make the template plugin behave correctly, two entries are needed
for each record: one with the correct type and the appropriate answer,
and one with the incorrect type and an empty answer. This gets us
RFC-compliant behavior while still allowing fallthrough for requests
that are not present in the local server.

This change requires new fields from baremetal-runtimecfg that are
added in openshift/baremetal-runtimecfg#60.
@openshift-ci-robot
Copy link
Contributor

@cybertron: No Bugzilla bug is referenced in the title of this pull request.
To reference a bug, add 'Bug XXX:' to the title of this pull request and request another bug refresh with /bugzilla refresh.

In response to this:

Correctly handle requests for ipv4/ipv6 records

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/test-infra repository.

@kikisdeliveryservice
Copy link
Contributor

/retest

@cybertron cybertron changed the title Correctly handle requests for ipv4/ipv6 records Bug 1851541: Correctly handle requests for ipv4/ipv6 records Jun 30, 2020
@openshift-ci-robot openshift-ci-robot added the bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. label Jun 30, 2020
@openshift-ci-robot
Copy link
Contributor

@cybertron: This pull request references Bugzilla bug 1851541, which is valid. The bug has been updated to refer to the pull request using the external bug tracker.

6 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.5.0) matches configured target release for branch (4.5.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)
  • dependent bug Bugzilla bug 1820785 is in the state ON_QA, which is one of the valid states (MODIFIED, ON_QA, VERIFIED)
  • dependent Bugzilla bug 1820785 targets the "4.6.0" release, which is one of the valid target releases: 4.6.0, 4.6.z
  • bug has dependents

In response to this:

Bug 1851541: Correctly handle requests for ipv4/ipv6 records

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/test-infra repository.

@openshift-ci-robot openshift-ci-robot added the bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. label Jun 30, 2020
@cybertron
Copy link
Member Author

/hold

This needs openshift/baremetal-runtimecfg#69

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 30, 2020
@sdodson
Copy link
Member

sdodson commented Jun 30, 2020

/hold cancel
/retest
openshift/baremetal-runtimecfg#69 has merged

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 30, 2020
@kikisdeliveryservice
Copy link
Contributor

/assign @celebdor

@runcom
Copy link
Member

runcom commented Jul 1, 2020

/approve
/skip

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 1, 2020
@bcrochet
Copy link
Member

bcrochet commented Jul 1, 2020

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jul 1, 2020
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bcrochet, cybertron, runcom

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

The pull request process is described here

Needs approval from an approver in each of these files:

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

@sdodson sdodson added the cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. label Jul 1, 2020
@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Jul 1, 2020

@cybertron: The following test failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
ci/prow/e2e-aws-scaleup-rhel7 c8a2610 link /test e2e-aws-scaleup-rhel7

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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/test-infra repository. I understand the commands that are listed here.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-merge-robot openshift-merge-robot merged commit 3608783 into openshift:release-4.5 Jul 1, 2020
@openshift-ci-robot
Copy link
Contributor

@cybertron: All pull requests linked via external trackers have merged: openshift/machine-config-operator#1870, openshift/baremetal-runtimecfg#69. Bugzilla bug 1851541 has been moved to the MODIFIED state.

In response to this:

Bug 1851541: Correctly handle requests for ipv4/ipv6 records

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/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants