Open Stack

Currently Designate does not support DNS views (split-horizon), so
there is no way to tag records as internal vs. external. This is a
widely requested enhancement.

As Jeremy mentioned, there is a specification and proposed code for a
version of split-horizon, though I'm not sure it meets your use case
(This is a current stream of discussion on the patch). The current
proposed patch requires the operator to define the internal and
external IP address ranges. These are not user configurable.

I think there is more design discussion needed on this topic and I
plan to include it in our PTG agenda.

For now, please feel free to review and comment on the existing patch.

As an interim solution, you could create zones for the various
purposes and manage them directly in Designate, it just wouldn't
provide much automation.

Michael

On Thu, Mar 18, 2021 at 7:04 AM Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2021-03-18 10:46:59 +0100 (+0100), Christian Rohmann wrote:
> [...]
> > is there any way to allow users to add their own records which
> > then only resolve internally?
> [...]
> > Looking at the Designate API
> > https://docs.openstack.org/api-ref/dns/?expanded=create-zone-detail#create-zone
> > is does not seem to be an option to mark a zone as "internal" or
> > "private". But maybe there is another way to add records to the
> > internal zone?
> >
> > I am thinking of an only internally resolvable / valid DNS zone
> > carrying records for i.e. service discovery / cluster forming.
> [...]
>
> The traditional term for what you're describing is "split-horizon
> DNS" (implemented via things like BIND's "views" mechanism). I see
> there's a split_view zone type which is proposed in this spec:
>
> https://specs.openstack.org/openstack/designate-specs/specs/ussuri/split-view.html
>
> Poking in code review, it looks like it may be in progress:
>
> https://review.opendev.org/q/topic:bug/1875939
>
> If this is of interest to you, please do help review and test the
> feature to make sure it will meet your requirements.
> --
> Jeremy Stanley