[GH-ISSUE #386] Option to not comment out existing nameservers from resolv.conf

kerem commented

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

Owner

Originally created by @Sajito on GitHub (Mar 20, 2023).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/386

Originally assigned to: @mageddo on GitHub.

What is expected

I'd like to ask for an option, to disable the behavior of disabling existing nameservers. If that option is enabled, it should simply add itself without disabling the other options.

What is Happening

Currently when dps is started and the file "/etc/resolv.conf" is used, it will comment out any existing nameserver and add itself as single nameserver to the file.

What I want to achieve

When using my networks dns I can reach other devices in the same network by their hostname. When using dps locally, this ability gets lost.
I could add my networks dns to the "remoteDnsServers" list, but as I'm often in different networks, I'd have to always add the new dns ip addresses to that list.
This should simply work when adding dps as first nameserver in the resolv.conf without disabling all other nameservers.

Originally created by @Sajito on GitHub (Mar 20, 2023). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/386 Originally assigned to: @mageddo on GitHub. ### What is expected I'd like to ask for an option, to disable the behavior of disabling existing nameservers. If that option is enabled, it should simply add itself without disabling the other options. ### What is Happening Currently when dps is started and the file "/etc/resolv.conf" is used, it will comment out any existing nameserver and add itself as single nameserver to the file. ### What I want to achieve When using my networks dns I can reach other devices in the same network by their hostname. When using dps locally, this ability gets lost. I could add my networks dns to the "remoteDnsServers" list, but as I'm often in different networks, I'd have to always add the new dns ip addresses to that list. This should simply work when adding dps as first nameserver in the resolv.conf without disabling all other nameservers.

kerem

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

closed this issue
added the
feature
label

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Mar 21, 2023):

Sounds good to me, would you prefer to do the configuration by command line, json or env?

@mageddo commented on GitHub (Mar 21, 2023): Sounds good to me, would you prefer to do the configuration by command line, json or env?

kerem commented

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

Author

Owner

@Sajito commented on GitHub (Mar 21, 2023):

I like to use the json, so I'd prefer the option there

@Sajito commented on GitHub (Mar 21, 2023): I like to use the json, so I'd prefer the option there

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Mar 22, 2023):

This feature will depends on #392 otherwise won't work as expected

@mageddo commented on GitHub (Mar 22, 2023): This feature will depends on #392 otherwise won't work as expected

kerem commented

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

Author

Owner

@Sajito commented on GitHub (Mar 23, 2023):

I think when we have this option, it is enabled and there is at least one other nameserver in the resolv.conf, then dps maybe should not use the remote solver, as it should be handled by the other nameservers. What do you think?

@Sajito commented on GitHub (Mar 23, 2023): I think when we have this option, it is enabled and there is at least one other nameserver in the resolv.conf, then dps maybe should not use the remote solver, as it should be handled by the other nameservers. What do you think?

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Mar 23, 2023):

I would add a specific option for that, introduce --no-remote-servers.

@mageddo commented on GitHub (Mar 23, 2023): I would add a specific option for that, introduce `--no-remote-servers`.

kerem commented

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

Author

Owner

@Sajito commented on GitHub (Mar 23, 2023):

Sounds good for me 👍

@Sajito commented on GitHub (Mar 23, 2023): Sounds good for me 👍

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Apr 5, 2023):

Just released 3.15.10-snapshot see the docs for the new option resolvConfOverrideNameServers . No remote servers option will be released in the sequence.

@mageddo commented on GitHub (Apr 5, 2023): Just released ` 3.15.10-snapshot` [see the docs][1] for the new option `resolvConfOverrideNameServers` . No remote servers option will be released in the sequence. [1]: http://mageddo.github.io/dns-proxy-server/3.15/en/3-configuration/

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Apr 7, 2023):

Finally released 3.15.11-snapshot see the docs for the new option (No Remote Servers).

Can you check the released features? Then we can close this issue @Sajito.

@mageddo commented on GitHub (Apr 7, 2023): Finally released `3.15.11-snapshot` [see the docs](http://mageddo.github.io/dns-proxy-server/3.15/en/3-configuration/) for the new option (No Remote Servers). Can you check the released features? Then we can close this issue @Sajito.

kerem commented

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

Author

Owner

@Sajito commented on GitHub (Apr 7, 2023):

I've tested both features using this docker-compose config. I know the MG_RESOLVCONF is not needed, as it's detected automatically. But since my system uses systemd-resolved, it would be required to restart the systemd-resolved service. Using the /etc/resolv.conf directly does not require the system restart.

version: '3.6'

services:
  dns:
    image: defreitas/dns-proxy-server:3.15.11-snapshot
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc:/host/etc
    environment:
      MG_RESOLVCONF_OVERRIDE_NAMESERVERS: false
      MG_RESOLVCONF: /host/etc/resolv.conf
      MG_DPS_NETWORK: true
      MG_DPS_NETWORK_AUTO_CONNECT: true
      NO_REMOTE_SERVERS: true
      MG_LOG_LEVEL: DEBUG
    command: --no-remote-servers
    ports:
      - "5380:5380"

The NO_REMOTE_SERVERS environment variable does not seem to work. When adding only that variable, remote servers are still used. When using the cli option, it works fine.

The two features work as requested, but unfortunately the intended use-case still does not work. In fact, using both features together results in no external domains being resolved.
From my understanding that's the case, because DPS returns NXDOMAIN, when it has no result. NXDOMAIN from any nameserver causes the clients to stop trying any other nameserver (see https://superuser.com/a/1713739).

I'm not sure, but maybe returning SERVFAIL instead of NXDOMAIN might work? But that's really only an uneducated guess.

@Sajito commented on GitHub (Apr 7, 2023): I've tested both features using this docker-compose config. I know the MG_RESOLVCONF is not needed, as it's detected automatically. But since my system uses systemd-resolved, it would be required to restart the systemd-resolved service. Using the /etc/resolv.conf directly does not require the system restart. ``` version: '3.6' services: dns: image: defreitas/dns-proxy-server:3.15.11-snapshot volumes: - /var/run/docker.sock:/var/run/docker.sock - /etc:/host/etc environment: MG_RESOLVCONF_OVERRIDE_NAMESERVERS: false MG_RESOLVCONF: /host/etc/resolv.conf MG_DPS_NETWORK: true MG_DPS_NETWORK_AUTO_CONNECT: true NO_REMOTE_SERVERS: true MG_LOG_LEVEL: DEBUG command: --no-remote-servers ports: - "5380:5380" ``` The `NO_REMOTE_SERVERS` environment variable does not seem to work. When adding only that variable, remote servers are still used. When using the cli option, it works fine. The two features work as requested, but unfortunately the intended use-case still does not work. In fact, using both features together results in no external domains being resolved. From my understanding that's the case, because DPS returns `NXDOMAIN`, when it has no result. `NXDOMAIN` from any nameserver causes the clients to stop trying any other nameserver (see https://superuser.com/a/1713739). I'm not sure, but maybe returning `SERVFAIL` instead of `NXDOMAIN` might work? But that's really only an uneducated guess.

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Apr 8, 2023):

The NO_REMOTE_SERVERS environment variable does not seem to work. When adding only that variable, remote servers are still used. When using the cli option, it works fine.

The docs are incorrect, the right variable name is MG_NO_REMOTE_SERVERS

@mageddo commented on GitHub (Apr 8, 2023): > The NO_REMOTE_SERVERS environment variable does not seem to work. When adding only that variable, remote servers are still used. When using the cli option, it works fine. The docs are incorrect, the right variable name is `MG_NO_REMOTE_SERVERS`

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Apr 8, 2023):

I'm not sure, but maybe returning SERVFAIL instead of NXDOMAIN might work? But that's really only an uneducated guess.

I've tried, REFUSED and SERVFAIL, only SERVFAIL worked:

$ nslookup host.docker
Server:         172.157.5.2
Address:        172.157.5.2#53

Non-authoritative answer:
Name:   host.docker
Address: 172.20.0.2
Name:   host.docker
Address: fc00:5c6f:db50::4

$ nslookup google.com
;; Got SERVFAIL reply from 172.157.5.2, trying next server
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.79.206
;; Got SERVFAIL reply from 172.157.5.2, trying next server
Name:   google.com
Address: 2800:3f0:4001:82f::200e

I don't consider return SERVFAIL as a RFC compliant answer in that case, for that reason I'll customize the RCODE when a hostname wasn't found by DPS local solvers (not the remote ones), I consider it must solve your use case.

@mageddo commented on GitHub (Apr 8, 2023): > I'm not sure, but maybe returning SERVFAIL instead of NXDOMAIN might work? But that's really only an uneducated guess. I've tried, REFUSED and SERVFAIL, only SERVFAIL worked: ``` $ nslookup host.docker Server: 172.157.5.2 Address: 172.157.5.2#53 Non-authoritative answer: Name: host.docker Address: 172.20.0.2 Name: host.docker Address: fc00:5c6f:db50::4 $ nslookup google.com ;; Got SERVFAIL reply from 172.157.5.2, trying next server Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: google.com Address: 142.250.79.206 ;; Got SERVFAIL reply from 172.157.5.2, trying next server Name: google.com Address: 2800:3f0:4001:82f::200e ``` I don't consider return `SERVFAIL` as a RFC compliant answer in that case, for that reason I'll customize the RCODE when a hostname wasn't found by DPS local solvers (not the remote ones), I consider it must solve your use case.

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Apr 12, 2023):

By #414 I'm releasing 3.15.13-snapshot, will be available in 10 minutes. @Sajito

Option to customize RCODE when no entries are found by all tried solvers

@mageddo commented on GitHub (Apr 12, 2023): By #414 I'm releasing `3.15.13-snapshot`, will be available in 10 minutes. @Sajito > Option to customize RCODE when no entries are found by all tried solvers

kerem commented

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

Author

Owner

@Sajito commented on GitHub (Apr 13, 2023):

This is awesome, it's working perfectly fine. Thank you very much!

@Sajito commented on GitHub (Apr 13, 2023): This is awesome, it's working perfectly fine. Thank you very much!

kerem referenced this issue

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

[PR #133] [MERGED] fixing json config version data type #293

Rows
Columns

[GH-ISSUE #386] Option to not comment out existing nameservers from resolv.conf #133

What is expected

What is Happening

What I want to achieve