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

AXFR garbage in zone with eccentric RRtypes #7446

Closed
mdavids opened this issue Feb 4, 2019 · 7 comments

Comments

Projects
None yet
2 participants
@mdavids
Copy link

commented Feb 4, 2019

  • Program: Authoritative
  • Issue type: Bug report

Short description

SIDN Labs runs a so called DNS workbench.

One of the zone files in that workbench contains a range of different RRtypes. We managed to load it successfully in PowerDNS by slaving it with a sqlite3 back-end (and earlier attempt to do it with a bind backend resulted in #7437)

The zone appears to work, but an AXFR fails:

dig AXFR types.wb.sidnlabs.nl @powerdns.sidnlabs.nl
;; Got bad packet: bad compression pointer

Environment

  • Operating system: Ubuntu 18.04
  • Software version: pdns-server 4.1.1-1 package
  • Software source: Operating system repository

Steps to reproduce

  1. dig AXFR types.wb.sidnlabs.nl @powerdns.sidnlabs.nl
  2. dig AXFR types-signed.wb.sidnlabs.nl @powerdns.sidnlabs.nl

Expected behaviour

Successful zone transfer

Actual behaviour

; <<>> DiG 9.13.3 <<>> AXFR types.wb.sidnlabs.nl @powerdns.sidnlabs.nl
;; global options: +cmd
types.wb.sidnlabs.nl. 86400 IN SOA bind9.sidnlabs.nl. hostmaster.sidnlabs.nl. 1549195009 3600 600 1814400 3600
;; Got bad packet: bad compression pointer
3790 bytes

@mdavids

This comment has been minimized.

Copy link
Author

commented Feb 4, 2019

mdavids added a commit to SIDN/workbench that referenced this issue Feb 4, 2019

@omoerbeek

This comment has been minimized.

Copy link
Member

commented Mar 22, 2019

This seems to happen at least with MR and MG records. e.g.

dig MR mr.types.wb.sidnlabs.nl @powerdns.sidnlabs.nl

Is enough to trigger the issue.

How did you import the zone? Via a slave copy, db import using the sqlite tool, zone2sql or maybe another method?

@omoerbeek

This comment has been minimized.

Copy link
Member

commented Mar 22, 2019

I can reproduce using 4.1.x, but this is fixed in 4.2, which will be released soon.

Please confirm using https://downloads.powerdns.com/autobuilt_browser/#/auth/4.2.0-rc1

See #6377 (although this PR does not seem to fix the MR case, it is fixed as well in my testing).

IMO this is not worth the trouble to backport since the record types are deprecated anyway.

@omoerbeek omoerbeek self-assigned this Mar 22, 2019

@omoerbeek

This comment has been minimized.

Copy link
Member

commented Apr 2, 2019

@mdavids I'd appreciate some feedback. Thanks.

@mdavids

This comment has been minimized.

Copy link
Author

commented Apr 2, 2019

Unable to verify this on the short term, sorry.
Will try to do this a.s.a.p.
Feel free to close the ticket, I have great confidence in your claims.
Totally agree with the 'no backporting' view.

@mdavids

This comment has been minimized.

Copy link
Author

commented Apr 2, 2019

How did you import the zone? Via a slave copy, db import using the sqlite tool, zone2sql or maybe another method?

We load it in PowerDNS by slaving it with a sqlite3 backend (an earlier attempt to do it with a bind backend resulted in #7437).

@omoerbeek

This comment has been minimized.

Copy link
Member

commented Apr 2, 2019

OK, I'm closing this and next will take a look at #7437

@omoerbeek omoerbeek closed this Apr 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.