Add standard for DNS

[markus-hentsch]

No description provided.

[horazont]

We should discuss how to handle clouds where provider networks use different root zones.

An example scenario: An on-premise setup where one provider network is connected to the internet (and uses the public root zone) has a second provider network which is connected to the company intranet. That intranet is isolated from the internet and uses an alt-root for internal name resolution.

Here, it is not obvious how a value for dnsmasq_dns_server should look like to allow resolution of names relevant to the respective network could work.

We need to discuss:

• Whether such setups are in scope, and
• if they are: how to address this.

[horazont]

This still needs some discussion, has that happened in some meeting I wasn't part of or should we schedule something for that? @markus-hentsch @fkr

[horazont]

Don't mention DNS-over-HTTPS, as it provides no significant benefits over DNS-over-TLS, but needlessly exposes an HTTP parser to the internet.

[artificial-intelligence]

The security aspect has merit but DNS over HTTPS has significant different advantages over DNS over TLS, especially with regards to privacy and simplicity of configuration (e.g. port 443 is almost always no problem to connect to, good luck with DNSoTLS with some network middleboxes.)

[horazont]

Which privacy advantages does DoH have that DoTLS does not have?

[artificial-intelligence]

It's usage is harder to detect than DoT, this is why every browser implements DoH instead of DoT. This might or might not be a concern for our usecase though (I think it is the latter, but I didn't really analyze this in detail).

Specifically DoT uses Port 853 which makes it very easy to detect and block.

:edit: see e.g. https://dnsprivacy.org/the_solutions/#dns-over-tls-dot for some external references.

The web is full with content around this controversy, e.g. there where some panels regarding this at some FOSDEM dns dev rooms in the past with quite some good arguments for both "sides", see e.g. this blog post which has more links:

https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem

[horazont]

Right, none of that matters for a recursor running locally in a datacenter. I'd argue even DoTLS is overkill for that, but that's not a hill I'm willing to die on.

[markus-hentsch]

Based on the latest findings of SovereignCloudStack/issues#229 I made the following changes/additions:

• only make the dns driver mandatory (not dns_domain_ports); this should be more then sufficient for internal DNS
• for infrastructures offering DNSaaS (Designate), instead make dns_domain_ports mandatory and subnet_dns_published_fixed_ip recommended

[markus-hentsch]

I implemented a test script that verifies the existence of the API extensions as mandated by the current standard draft.
The script queries the Neutron Extensions API and relies on the information it provides.

However, due to https://bugs.launchpad.net/neutron/+bug/2063669 the test will succeed in any OVN-based setup since the DNS extensions are always reported as being available even if none of them actually are.

Upstream needs to fix this for the test script to actually report accurate results ...

[anjastrunk]

LGTM, beside missing two explanations for "OVM" and "OVS".

[markus-hentsch]

LGTM, beside missing two explanations for "OVM" and "OVS".

Thanks for pointing that out! This is quite important. I've added them to the glossary.

[artificial-intelligence]

I need to review this in more detail later.
I'm only somewhat competent in the DNS RFCs as I happened to run, architect and maintain some dns infrastructure in the past.

DNS is a very complicated topic and I need some more time to read the standard very carefully, thanks.

[artificial-intelligence]

The security aspect has merit but DNS over HTTPS has significant different advantages over DNS over TLS, especially with regards to privacy and simplicity of configuration (e.g. port 443 is almost always no problem to connect to, good luck with DNSoTLS with some network middleboxes.)

[artificial-intelligence]

imho the standard should mandate RFC compliant DNS Servers that should be made available to the customer, given the fact there are a lot of non compliant dns servers out there.

[horazont]

imho the standard should mandate RFC compliant DNS Servers that should be made available to the customer, given the fact there are a lot of non compliant dns servers out there.

Good idea. Do you have a list of RFCs a good recursor should adhere to? I'm not sure if we need to list the RFCs of all RRs which we expect to be supported or whether that's something any base-RFC-compliant recursor MUST handle correctly anyway (even though history has shown they don't always).

[markus-hentsch]

(this comment was misplaced and moved to the corresponding issue here)

[markus-hentsch]

I demoted some of the guidelines in this standard from MUST to SHOULD as a result of the recent CSP discussion (see here).

As a result, the API tests I implemented for the conformance tests are not applicable anymore and I removed them. They wouldn't have worked properly with Neutron's current implementation anyway.