freeipa

#9158 Internal error when setting dnsconfig or dnsforwardzone forwarders.
Closed: fixed by frenaud. Opened by rjeffman.

Closed: fixed
Reopen Issue

Issue

When setting a forwarder, in a DNS forward zone, if providing the port to connect to, the forwarder is set, but an internal error occurs and the result is that the command failed.

[root@server ~]# ipa dnsforwardzone-mod example.com --forwarder="1.1.1.1 port 53"
Server will check DNS forwarder(s).
This may take some time, please wait ...
ipa: ERROR: no modifications to be performed
[root@server ~]# ipa dnsforwardzone-show example.com
  Zone name: example.com.
  Active zone: TRUE
  Zone forwarders: 1.1.1.1 port 53
  Forward policy: first

The same behavior has been observed when setting a forwarder in DNS config:

[root@server ~]# ipa dnsconfig-mod --forwarder="1.1.1.1 port 53"
Server will check DNS forwarder(s).
This may take some time, please wait ...
ipa: ERROR: an internal error has occurred
[root@server ~]# ipa dnsconfig-show
  Global forwarders: 1.1.1.1 port 53
  Forward policy: only
  Allow PTR sync: TRUE
  IPA DNS servers: server.ipa.test

This behavior was first noticed it ansible-freeipa pipelines. An exception is being raised by IPA API where no error was reported before.

Steps to Reproduce

Please, see issue description.

Actual behavior

The forwarders are set, but an error is raised and the CLI command fails (exit code is 1).

Expected behavior

Either the forwarders are not set, or the command returns no error.

Version/Release/Distribution

Fedora 36

  • freeipa-server-4.9.9-1.fc36.x86_64
  • freeipa-client-4.9.9-1.fc36.x86_64
  • 389-ds-base-2.1.1-1.fc36.x86_64
  • package pki-ca is not installed
  • krb5-server-1.19.2-9.fc36.x86_64

A relevant package is: python3-dns-2.2.0-1.fc36.noarch

Additional info:

This issue is only reproducible in Fedora 36, as it has dnspython (python3-dns) version 2.2.0 which changed the behavior when setting the nameservers property of dns.resolve.Resolver objects. On this version of dnspython, the nameservers IP are verified, and if the value contains the port, as in "1.1.1.1 port 53", it is not a valid IP address, so setting the property value fails with an exception.

I tracked the failure down to ipalib.util._resolve_record (res.nameservers = [nameserver_ip]).

Metadata Update from @twoerner:
- Issue priority set to: important

Metadata Update from @rjeffman:
- Issue assigned to rjeffman

Metadata Update from @rjeffman:
- Issue assigned to rjeffman

dnspython 2.2.0 changed the way property Resolver.nameserver works, by validating every IP address that is given to the property. FreeIPA function ipalib.util._resolve_record() sets this property with the value provided by some client code.

In the case of dnsconfig and dnsforwardzone, the value passed as IP address, for the forwarders, might be 192.168.17.253 port 8053 for a DNS server not running in the default DNS port. This whole string is then given to ipalib.util._resolve_record() and passed as a nameserver addres. As it clearly is not an IP address, a ValueError is raised.

As far as I can see, these are the only cases were an invalid IP address is provided.

Metadata Update from @rjeffman:
- Issue priority set to: None (was: important)

The dnspython rationale for this behavior change, or enforcement, can be found in this comment.

PR: https://github.com/freeipa/freeipa/pull/6269

Previous PR was dropped in favor of https://github.com/freeipa/freeipa/pull/6408

Metadata Update from @rjeffman:
- Assignee reset

Metadata Update from @twoerner:
- Issue assigned to twoerner

master:

  • 77803587d6e15b41a66fc0ee0a87ad55ee196dfe DNSResolver: Fix use of nameservers with ports

ipa-4-9:

  • 5e2e4664aec641886923c2bec61ce25b96edb62a DNSResolver: Fix use of nameservers with ports

ipa-4-10:

  • 6c5530c509793f66a162ed4153d5425a0eda02d6 DNSResolver: Fix use of nameservers with ports

Metadata Update from @frenaud:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.