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

AXFRDDNS: Integration test failing #1913

Closed
tlimoncelli opened this issue Jan 3, 2023 · 1 comment
Closed

AXFRDDNS: Integration test failing #1913

tlimoncelli opened this issue Jan 3, 2023 · 1 comment

Comments

@tlimoncelli
Copy link
Contributor

cc @hnrgrgr

I'm taking the liberty of opening this issue to track the A record issue you found. Thanks for taking a look into this issue!

Cite: #1905 (comment)

=== RUN   TestDNSProviders/example.com/04:TypeChange:Change_back_to_CNAME
    integration_test.go:223: DDNS UPDATES to 'example.com' (primary master: '172.27.82.2:53'). Changes:
        CREATE CNAME foo.example.com google2.com. ttl=300
        DELETE A foo.example.com 1.2.3.4 ttl=300
        
    integration_test.go:242: Expected 0 corrections on second run, but found 1.
    integration_test.go:244: UNEXPECTED #0: DDNS UPDATES to 'example.com' (primary master: '172.27.82.2:53'). Changes:
        CREATE CNAME foo.example.com google2.com. ttl=300
hnrgrgr added a commit to hnrgrgr/dnscontrol that referenced this issue Mar 27, 2023
The integration tests do not fail when executed with a `bind` server,
but they fail when executedwith a `knot` server.

It looks like knot is buggy and does not allow to replace a `CNAME`
record by a `A` record in a single batched update.

This patch adds an option `buggy-cname` in `creds.json` for splitting
such request in two DDNS updates. This option is deactivated by
default, since the update is not atomic anymore.
hnrgrgr added a commit to hnrgrgr/dnscontrol that referenced this issue Mar 30, 2023
The integration tests do not fail when executed with a `bind` server,
but they fail when executedwith a `knot` server.

It looks like knot is buggy and does not allow to replace a `CNAME`
record by a `A` record in a single batched update.

This patch adds an option `buggy-cname` in `creds.json` for splitting
such request in two DDNS updates. This option is deactivated by
default, since the update is not atomic anymore.
@tlimoncelli
Copy link
Contributor Author

@hnrgrgr Please close this issue if the PRs resolved the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant