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

DNAME occlusion #1361

Open
Habbie opened this issue Apr 11, 2014 · 5 comments
Open

DNAME occlusion #1361

Habbie opened this issue Apr 11, 2014 · 5 comments

Comments

@Habbie
Copy link
Member

Habbie commented Apr 11, 2014

From regression-tests/zones/test.com:

d               IN      DNAME   d2.test2.com.
a.d             IN      A       192.168.7.1

When queried for a.d, we return the A, while we should be synthesising a CNAME.

Tasks:

  1. add to check-zone
  2. optional: rework packethandler to do this right
@Habbie Habbie added this to the auth-4.1.0 milestone Dec 15, 2015
@Habbie Habbie modified the milestones: auth-helpneeded, former-auth-4.1.0 Mar 7, 2017
@klaus3000
Copy link

I am just hit by this bug. Any chance this gets fixed some time?

Also the description of "dname-processing" confuses me:
"Synthesise CNAME records from DNAME records as required. This approximately doubles query load. Do not combine with DNSSEC!"
So, does this option activate DNAME handling inthe first place, or does it only control the CNAME synthesizing?

@Habbie
Copy link
Member Author

Habbie commented Oct 25, 2019

I am just hit by this bug. Any chance this gets fixed some time?

As it only occurs when there is garbage in the database, it does not have a super high priority.

"Synthesise CNAME records from DNAME records as required. This approximately doubles query load. Do not combine with DNSSEC!"

The 'Do not combine with DNSSEC' remark surprises me!

So, does this option activate DNAME handling inthe first place, or does it only control the CNAME synthesizing?

Those are the same thing. DNAME processing -is- CNAME synthesis.

@klaus3000
Copy link

In my tests with Auth 4.1.5 DNAME does not work without dname-processing=yes. Hence, the name of the option is correct, the description make me thing this is only needed for CNAME synthesis but it is needed always for DNAME to work - even without subordinate labels.

@Habbie
Copy link
Member Author

Habbie commented Oct 25, 2019

only needed for CNAME synthesis but it is needed always for DNAME to work

Again, those are the same thing. I'm confused - it looks like you are saying 'in 4.1.5, DNAME works, except it does not generate CNAMEs'. In that case, what part of DNAME is working?

@Habbie Habbie closed this as completed Oct 29, 2019
@Habbie Habbie reopened this Oct 29, 2019
@klaus3000
Copy link

Sorry for the confusion. Indeed there 3 issues:

  1. dname-processing=yes must be set to serve DNAME at all
  2. If the zone has sub-lables below DNAME, pdns serves the sublabel instead of the DNAME
  3. DNAME responses are unsigned for presigned zones - at least the DNAMEs RRSIG should be served. (I have not tested online-signed zones)

@Habbie Habbie modified the milestones: auth-helpneeded, auth-4.5.0 Nov 18, 2020
@Habbie Habbie modified the milestones: auth-4.5.0, auth-4.6.0 Apr 26, 2021
@Habbie Habbie modified the milestones: auth-4.6.0, auth-4.7.0 Dec 3, 2021
@Habbie Habbie modified the milestones: auth-4.7.0, auth-4.8.0 Sep 8, 2022
@Habbie Habbie modified the milestones: auth-4.8.0, auth-4.9.0 Apr 14, 2023
@Habbie Habbie modified the milestones: auth-4.9.0, auth-5 Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants