Optimize network configuration for lower verbosity

When we look at a more complicated configuration, for example our ODVR, the network section is unnecessarily verbose. We should make it more concise...

Note: issue changed topic due to a developing discussion. The previous topic was recreated under #46 (moved)

assigned to @amrazek

Well, there is some instance-specific magic done with lua to detect different systemd instances and configure them separately (at least for network interfaces), but here you go: https://gitlab.nic.cz/knot/knot-resolver-odvr/-/blob/master/roles/knot-resolver/templates/kresd.conf.j2

According to the current model, the declarative configuration of ODVR looks like this.

Click to expand

---
server:
  nsid: odvr.nic.cz
  workers: 3
  watchdog:
    qname: nic.cz
    qtype: A
network:
  interfaces:
    - listen:
        ip: 127.0.0.1
    - listen:
        ip: ::1
    - listen:
        ip: 192.0.2.1
    - listen:
        ip: 2001:db8::1
    # DNS over TLS, default port is 853
    - listen:
        ip: 127.0.0.1
      kind: dot
    - listen:
        ip: ::1
      kind: dot
    - listen:
        ip: 192.0.2.1
      kind: dot
    - listen:
        ip: 2001:db8::1
      kind: dot
    # DNS over HTTPS/2, default port is 443
    - listen:
        ip: 127.0.0.1
      kind: doh
    - listen:
        ip: ::1
      kind: doh
    - listen:
        ip: 192.0.2.1
      kind: doh
    - listen:
        ip: 2001:db8::1
      kind: doh
  tls:
    cert-file: /etc/ssl/nic-certs/odvr.nic.cz/odvr.nic.cz.chained.crt
    key-file: /etc/ssl/nic-certs/odvr.nic.cz/odvr.nic.cz.key
options:
  prediction: true
cache:
  size-max: 500M
logging:
  level: debug
  dnstap:
    unix-socket: /tmp/dnstap.sock
    log-queries: true
    log-responses: true
    log-tcp-rtt: true
  debugging:
    assertion-abort: true
monitoring:
  statistics: true

I think the network/interfaces section is a bit unnecessarily complicated and it would be good to reduce it.

examples of improvement

example1

network:
  listen:
    - ip: 127.0.0.1
    - ip: ::1
    - ip: 192.0.2.1
    - ip: 2001:db8::1
    # DNS over TLS, default port is 853
    - ip: 127.0.0.1
      kind: dot
    - ip: ::1
      kind: dot
    - ip: 192.0.2.1
      kind: dot
    - ip: 2001:db8::1
      kind: dot
    # DNS over HTTPS/2, default port is 443
    - ip: 127.0.0.1
      kind: doh
    - ip: ::1
      kind: doh
    - ip: 192.0.2.1
      kind: doh
    - ip: 2001:db8::1
      kind: doh

example2

network:
  listen:
    - ip: [127.0.0.1, ::1, 192.0.2.1, 2001:db8::1]
    # DNS over TLS, default port is 853
    - ip: [127.0.0.1, ::1, 192.0.2.1, 2001:db8::1]
      kind: dot
    # DNS over HTTPS/2, default port is 443
    - ip: [127.0.0.1, ::1, 192.0.2.1, 2001:db8::1]
      kind: doh

I like the second example. I'd just use interfaces instead of listen

I realized that repetition could also get cut down without changing any code. An implementation for example2 would also accept:

network:
  listen:
    - ip: &IPs [127.0.0.1, ::1, 192.0.2.1, 2001:db8::1]
    - ip: *IPs
      kind: dot
    - ip: *IPs
      kind: doh

Just in case someone really had a long list. The anchor+alias feature might more likely find use cases around policies and other rules.

The problem is that when used with @port it doesn't make sense.

The anchor I wrote is just for the list of addresses. I am already using it locally with overridden ports, though your Draft MR has a little different schema. (Maybe I didn't get your meaning right.)

Yes, it makes sense for a list of addresses. I wanted to indicate that when using address@port list, you can't use it for another kinds.

The following example is invalid because ports for the other kinds is taken from the original list.

network:
  listen:
    - ip-address: &IPs [127.0.0.1@5353, ::1@5353, 192.0.2.1@5353, 2001:db8::1@5353]
    - ip-address: *IPs
      kind: dot
    - ip-address: *IPs
      kind: doh

An extreme approach might be like:

#network: etc. or details
  listen:
    - ip: [127.0.0.1, ::1, 192.0.2.1, 2001:db8::1]
      kind: [dns, dot, doh]

I find this interesting, as to me it seems likely to be relatively common use case to have a similar simple cartesian product between addresses and protocols (even just because v4+v6).

In your extreme approach, I see a problem with defining ports.

The extreme approach could only be used if the default port number for each kind is used. In other cases, it is confusing and inconsistent in my opinion. It might be possible to use a list of ports, but I already see this as extremely complicated.

listen:
  - ip: [127.0.0.1, ::1, 192.0.2.1, 2001:db8::1]
    port: [5353, 5354, 5355] # [dns-port, dot-port, doh-port]
    kind: [dns, dot, doh]

Agreed. The port list seems too much.

It would also complicate any sort of kind-specific configuration

To be clear, I didn't mean it as mandatory, only as extending the possibilities. You could still be more verbose and use multiple direct children of listen with each being "simpler", e.g. use exactly the same as example2.

I'd rather stick to simpler auto-magic conversion and cartesian product certainly isn't one of them.

However, simpler stuff like supporting both list and a single value in ip should be fine:

- ip: [127.0.0.1, 192.0.2.1]
- ip: 127.0.0.1
  kind: doh

changed title from Add integration test with some complex configuration to Optimize network configuration for lower verbosity

mentioned in issue #46 (moved)

changed the description

mentioned in commit f1926b13

created merge request !19 (closed) to address this issue

mentioned in merge request !19 (closed)

mentioned in merge request !20 (closed)

mentioned in commit 5f144996

closed

moved to knot-resolver#703 (closed)

mentioned in issue knot-resolver#707