[designate] Proposal to deprecate the agent framework and agent based backends

Michael Johnson johnsomor at gmail.com
Tue Jan 17 00:52:26 UTC 2023


TLDR: The Designate team would like to deprecate the backend agent
framework and the agent based backends due to lack of development and
design issues with the current implementation. The following backends
would be deprecated: Bind9 (Agent), Denominator, Microsoft DNS
(Agent), Djbdns (Agent), Gdnsd (Agent), and Knot2 (Agent).

Designate includes many backend DNS server drivers[1], many of which
are "native" (also known as xfr type backends) backend
implementations. In addition to the "native" backends, Designate has
an agent backend[2] that supports other backends via an agent process.

To quote the agent backend documentation[2]:
    This backend uses an extension[3] of the DNS protocol itself to
send management requests
    to the remote agent processes, where the requests will be actioned.
    The rpc traffic between designate and the agent is both
unauthenticated and unencrypted.
    Do not run this traffic over unsecured networks.

Here are the reasons we are proposing to deprecate the agent framework now:
1. The agent protocol used by Designate is using an "unassigned"[4][5]
DNS opcode (14) that is causing problems with the dnspython library >=
2.3.0 which is now validating the opcode when building DNS messages.
It is a bad practice to use "unassigned" values as they may be
officially assigned at any time, likely with an incompatible message
format.
2. The agent backends are not tested in the OpenStack jobs[1].
3. Many of the agent backends have been marked as "Experimental" since
2016 with no additional contributions beyond general repository code
maintenance.
4. The protocol between the Designate worker process and the agent
process is unauthenticated and unencrypted.
5. We do not know of a development resource to rewrite the agent
framework protocol to address issue #1 and #4 above.
6. The introduction of catalog zones[6] may eliminate the need for
some of the agent based backend drivers.

By marking the agent framework and agent based backends "deprecated"
in the Antelope cycle, we would remove the code no earlier than the
"C" release of OpenStack (per the OpenStack deprecation policy[7]). In
the meantime, issue #1 has been worked around by overriding the
dnspython opcode validation[7] as needed in the Designate code
(similar to a monkey patch). This is not a sustainable long term
solution.

The following backend agent based drivers would be marked "deprecated"
in addition to the agent framework itself:
Bind9 (Agent)
Denominator
Microsoft DNS (Agent)
Djbdns (Agent)
Gdnsd (Agent)
Knot2 (Agent)

We plan to propose patches for the deprecation over the next week, but
will not merge them until at least January 24th to allow time for
comment from the community.

If you have concerns about this deprecation plan or are interested in
rewriting the agent framework protocol to address the above issues,
please reply to this announcement.

Michael

[1] https://docs.openstack.org/designate/latest/admin/support-matrix.html
[2] https://docs.openstack.org/designate/latest/admin/backends/agent.html
[3] https://github.com/openstack/designate/blob/master/designate/backend/private_codes.py
[4] https://www.rfc-editor.org/rfc/rfc6895.html#section-2.2
[5] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-5
[6] https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-08.txt
[7] https://docs.openstack.org/project-team-guide/deprecation.html
[8] https://review.opendev.org/c/openstack/designate/+/870678



More information about the openstack-discuss mailing list