[GH-ISSUE #594] Configuration File v3 #195

New issue

Closed

opened 2026-02-26 04:34:20 +03:00 by kerem · 3 comments

kerem commented

2026-02-26 04:34:20 +03:00

Owner

Originally created by @mageddo on GitHub (Nov 6, 2024).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/594

Summary & Motivation

After some features added, it's time to remodel and introduce a new version of the configuration file aiming a cleaner structure.
Proposed configuration below
Suggestions are welcome until: 2024-11-30

Goals

Cleaner, easier to understand configuration file
To create a structure object oriented like
Propose a model which will be reflected to the YAML (#243) and Env (#577) Configurations

Description

Blocks:

#243
#577

Scope

Structure Domain Model config.Config as proposed in section "New Modeling Propose" #614
Model a "single" (using factory, strategy design pattern) parser which is capable to convert JSON, YAML and ENV configs to config.Config
- The parser must be dynamic
Create JSON v3 configuration
Deprecate ConfigJson Object: Only exists to parse v1 and v2 JSON file
Only the terminal will stay with an dedicated mapper and receive new feature flags
JSON v2 and The Legacy Env will remain supported, will have a dedicated mapper but won't receive new flags, only the JSON v3 will

New Modeling Propose

I'm proposing the following model, JSON Configuration example, the same will be made for YAML, etc.

{
  "version": 3,
  "server": {
    "dns": {
      "port": 53,
      "noEntriesResponseCode": 3
    },
    "web": {
      "port": 5380
    },
    "protocol": "UDP_TCP"
  },
  "solver": {
    "remote": {
      "active": true,
      "dnsServers": [
        "8.8.8.8", "4.4.4.4:53"
      ],
      "circuitBreaker": {
        "name": "STATIC_THRESHOLD"
      }
    },
    "docker": {
      "registerContainerNames": false,
      "domain": "docker",
      "hostMachineFallback": true,
      "dpsNetwork": {
        "name": "dps",
        "autoCreate": false,
        "autoConnect": false
      },
      "networks": {
        "preferredNetworkNames": [
          "a", "b", "c"
        ]
      },
      "dockerDaemonUri": null
    },
    "system": {
      "hostMachineHostname": "host.docker"
    },
    "local": {
      "activeEnv": "",
      "envs": [
        {
          "name": "",
          "hostnames": [
            {
              "type": "A",
              "hostname": "github.com",
              "ip": "192.168.0.1",
              "ttl": 255
            }
          ]
        }
      ]
    },
    "stub": {
      "domainName": "stub"
    }
  },
  "defaultDns": {
    "active": true,
    "resolvConf": {
      "paths": "/host/etc/systemd/resolved.conf,/host/etc/resolv.conf,/etc/systemd/resolved.conf,/etc/resolv.conf",
      "overrideNameServers": true
    }
  },
  "log": {
    "level": "DEBUG",
    "file": "console"
  }
}

Originally created by @mageddo on GitHub (Nov 6, 2024). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/594 ## Summary & Motivation * After some features added, it's time to remodel and introduce a new version of the configuration file aiming a cleaner structure. * Proposed configuration below * Suggestions are welcome until: `2024-11-30` ## Goals * Cleaner, easier to understand configuration file * To create a structure object oriented like * Propose a model which will be reflected to the YAML (#243) and Env (#577) Configurations ## Description Blocks: * #243 * #577 ### Scope * [x] Structure Domain Model `config.Config` as proposed in section "New Modeling Propose" #614 * [x] Model a "single" (using factory, strategy design pattern) parser which is capable to convert JSON, YAML and ENV configs to `config.Config` * The parser must be dynamic * [x] Create JSON v3 configuration * [x] Deprecate ConfigJson Object: Only exists to parse v1 and v2 JSON file * [x] Only the terminal will stay with an dedicated mapper and receive new feature flags * [x] JSON v2 and The Legacy Env will remain supported, will have a dedicated mapper but **won't** receive new flags, only the JSON v3 will ### New Modeling Propose I'm proposing the following model, JSON Configuration example, the same will be made for YAML, etc. ```json { "version": 3, "server": { "dns": { "port": 53, "noEntriesResponseCode": 3 }, "web": { "port": 5380 }, "protocol": "UDP_TCP" }, "solver": { "remote": { "active": true, "dnsServers": [ "8.8.8.8", "4.4.4.4:53" ], "circuitBreaker": { "name": "STATIC_THRESHOLD" } }, "docker": { "registerContainerNames": false, "domain": "docker", "hostMachineFallback": true, "dpsNetwork": { "name": "dps", "autoCreate": false, "autoConnect": false }, "networks": { "preferredNetworkNames": [ "a", "b", "c" ] }, "dockerDaemonUri": null }, "system": { "hostMachineHostname": "host.docker" }, "local": { "activeEnv": "", "envs": [ { "name": "", "hostnames": [ { "type": "A", "hostname": "github.com", "ip": "192.168.0.1", "ttl": 255 } ] } ] }, "stub": { "domainName": "stub" } }, "defaultDns": { "active": true, "resolvConf": { "paths": "/host/etc/systemd/resolved.conf,/host/etc/resolv.conf,/etc/systemd/resolved.conf,/etc/resolv.conf", "overrideNameServers": true } }, "log": { "level": "DEBUG", "file": "console" } } ```

kerem

2026-02-26 04:34:20 +03:00

closed this issue
added the
feature

feature-request
labels

kerem commented

2026-02-26 04:34:21 +03:00

Author

Owner

@defung commented on GitHub (Nov 7, 2024):

I love the grouping, makes the configs more readable!

Curious, does solver.docker.networks.preferredNetworkNames make my feature request redundant?

Also, what's solver.docker.dpsNetwork? Does it make DPS only resolve IPs from the dps network?

@defung commented on GitHub (Nov 7, 2024): I love the grouping, makes the configs more readable! Curious, does `solver.docker.networks.preferredNetworkNames` make [my feature request](https://github.com/mageddo/dns-proxy-server/issues/595) redundant? Also, what's `solver.docker.dpsNetwork`? Does it make DPS only resolve IPs from the `dps` network?

kerem commented

2026-02-26 04:34:21 +03:00

Author

Owner

@mageddo commented on GitHub (Nov 7, 2024):

Curious, does solver.docker.networks.preferredNetworkNames make https://github.com/mageddo/dns-proxy-server/issues/595 redundant?

I'm considering #595 will be already implemented when this feature get done.

Also, what's solver.docker.dpsNetwork? Does it make DPS only resolve IPs from the dps network?

DPS Network and DPS Network Auto Connect features

@mageddo commented on GitHub (Nov 7, 2024): > Curious, does solver.docker.networks.preferredNetworkNames make https://github.com/mageddo/dns-proxy-server/issues/595 redundant? I'm considering #595 will be already implemented when this feature get done. > Also, what's solver.docker.dpsNetwork? Does it make DPS only resolve IPs from the dps network? [`DPS Network` and `DPS Network Auto Connect`][1] features [1]: https://mageddo.github.io/dns-proxy-server/latest/en/3-configuration/#dps-network

kerem commented

2026-02-26 04:34:21 +03:00

Author

Owner

@mageddo commented on GitHub (Dec 17, 2025):

Beta is out 5.0.3-snapshot, see the docs.

@mageddo commented on GitHub (Dec 17, 2025): Beta is out [5.0.3-snapshot](https://github.com/mageddo/dns-proxy-server/releases/tag/5.0.3-snapshot), see the [docs](https://mageddo.github.io/dns-proxy-server/5.0/en/3-configuration/).

kerem referenced this issue

2026-02-26 04:34:53 +03:00

[PR #195] [CLOSED] Add config/environment/cli options to configure docker socket URL #331