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

pdnsutil add-record (A) always adds zone to specified value, even when trailing dot is specified in value #8595

Open
KoffieNu opened this issue Nov 28, 2019 · 2 comments · May be fixed by #14984

Comments

@KoffieNu
Copy link

  • Program: Authoritative
  • Issue type: Bug report

Short description

When adding an A record to a zone with pdnsutil add-record, the environment always adds zone to specified value, even when trailing dot is specified in value.

We need to build a domain tree, scripted, from the ground up to test within air-gapped environments. This includes providing root DNS services. To be able to build a complete DNS structure, the delegating of subdomains with a domain requires glue records to get this working.
The way to enter these glue records is to specify a trailing dot.

Environment

  • Operating system: Operating system: CentOS 7.7
  • Software version: pdns-4.1.11-1.el7.x86_64 (+ mysql backend)
  • Software source: EPEL

Steps to reproduce

  1. pdnsutil add-record example.com ns1.subdomain.example.com. A 3600 1.2.3.4

Expected behaviour

I would expect to see ns1.subdomain.example.com. as an A record in example.com (glue record for NS records higher up in the tree that service the domain)

Actual behaviour

I see ns1.subdomain.example.com.example.com as an A record in example.com

Other information

I would expect the record to be extended with the zone name when no trailing dot was given in the name, but when a trailing dot was specified, the value would be stored as provided.

@Habbie
Copy link
Member

Habbie commented Nov 28, 2019

Thank you for your report. This is not a bug, but I'll leave this open as a feature request/enhancement request. I do agree the behaviour is a bit unexpected.

ukleinek added a commit to ukleinek/pdns that referenced this issue Dec 17, 2024
…th .

If a NAME ends with a . it is to be understood as an absolute name and
appending the zone is not intuitive then.

Closes: PowerDNS#8595
ukleinek added a commit to ukleinek/pdns that referenced this issue Dec 18, 2024
…th .

If a NAME ends with a . it is to be understood as an absolute name and
appending the zone is not intuitive then.

Closes: PowerDNS#8595
ukleinek added a commit to ukleinek/pdns that referenced this issue Dec 18, 2024
…th .

If a NAME ends with a . it is to be understood as an absolute name and
appending the zone is not intuitive then.

Note this changes behaviour for calls like:

	pdnsutil --config-dir=configs/auth add-record example.net . NS 1.2.3.4

which added the NS record to the zone's apex before and is likely an
error now.

Closes: PowerDNS#8595
@ukleinek
Copy link
Contributor

While discussing my PR #14984 that implements this feature request, we stumbled over a usage in the test cases of regression-tests.auth-py/test_GSSTSIG.py:

$PDNSUTIL [...] add-record example.net . SOA 3600 'ns1.example.net otto.example.net 2022010403 10800 3600 604800 3600'"

That test now fails because the behaviour of this command changed. While it added a SOA record for example.net before it now adds a SOA for the root zone (which probably doesn't belong into the example.net zone).

I tend to prefer the new behaviour, but I also see the danger here to break existing scripts.

ukleinek added a commit to ukleinek/pdns that referenced this issue Dec 18, 2024
…th .

If a NAME ends with a . it is to be understood as an absolute name and
appending the zone is not intuitive then.

Note this changes behaviour for calls like:

	pdnsutil --config-dir=configs/auth add-record example.net . NS 1.2.3.4

which added the NS record to the zone's apex before and is likely an
error now.

Closes: PowerDNS#8595
ukleinek added a commit to ukleinek/pdns that referenced this issue Jan 13, 2025
…th . or ZONE

If a NAME ends with a . it is to be understood as an absolute name and
appending the zone is not intuitive then.

Note this changes behaviour for calls like:

	pdnsutil --config-dir=configs/auth add-record example.net . NS 1.2.3.4

which added the NS record to the zone's apex before and is likely an
error now.

Also make both

	pdnsutil --config-dir=configs/auth add-record example.net www.example.net A 1.2.3.5
	pdnsutil --config-dir=configs/auth add-record example.net www A 1.2.3.5

add www.example.net. to the example.net zone.

Closes: PowerDNS#8595
ukleinek added a commit to ukleinek/pdns that referenced this issue Jan 13, 2025
…th . or ZONE

If a NAME ends with a . it is to be understood as an absolute name and
appending the zone is not intuitive then.

Note this changes behaviour for calls like:

	pdnsutil --config-dir=configs/auth add-record example.net . NS 1.2.3.4

which added the NS record to the zone's apex before and is likely an
error now.

Also make both

	pdnsutil --config-dir=configs/auth add-record example.net www.example.net A 1.2.3.5
	pdnsutil --config-dir=configs/auth add-record example.net www A 1.2.3.5

add www.example.net. to the example.net zone.

Closes: PowerDNS#8595
ukleinek added a commit to ukleinek/pdns that referenced this issue Jan 13, 2025
…th . or ZONE

If a NAME ends with a . it is to be understood as an absolute name and
appending the zone is not intuitive then.

Note this changes behaviour for calls like:

	pdnsutil --config-dir=configs/auth add-record example.net . NS 1.2.3.4

which added the NS record to the zone's apex before and is likely an
error now.

Also make both

	pdnsutil --config-dir=configs/auth add-record example.net www.example.net A 1.2.3.5
	pdnsutil --config-dir=configs/auth add-record example.net www A 1.2.3.5

add www.example.net. to the example.net zone.

Closes: PowerDNS#8595
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants