starred/dns-proxy-server-mageddo
1
0
Fork 0
mirror of https://github.com/mageddo/dns-proxy-server.git synced 2026-04-25 09:25:56 +03:00
Code Issues 10 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #158] OSX Compatibility #63

New issue
Closed
opened 2026-02-26 04:33:55 +03:00 by kerem · 12 comments
kerem commented 2026-02-26 04:33:55 +03:00
Owner
Copy link

Originally created by @jwundrak on GitHub (Aug 26, 2019).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/158

What is expected

Support OSX

Currently per default you can not access container with their IPs directly on OSX. There are some workarounds and for me the best working thing is https://github.com/AlmirKadric-Published/docker-tuntap-osx . Using this (after setup the routing), I can ping and dig/nslookup directly to DPS

What is Happening

An issue for me is, that the DPS overwrites all *.docker.internal DNS entries, that also used on windows. That are e.g. host.docker.internal or gateway.docker.internal
There is a pull-request, to add this also to linux to provide an "same behaviour on all OSes": https://github.com/docker/libnetwork/pull/2348 . Hopefully it is merged in the next months.

Cause of the Docker-for-Mac (DfM) implementation, all others containers can not reach the dns, if I add the volume mapping to /etc/resolv.conf, so all builds fails (DNS e.g. for apt update) and so on...

Changes

I tried this locally and think, that this should work:

  • ignore *.docker.internal and let resolve them from the docker-daemon
  • add a flag or an IP option, that is populating to the resolv.conf

What I expect:

Mapping the dns-proxy to localhost:53 (localhost = host), populate in the resolv.conf as host.docker.internal (resolved to ip).

Originally created by @jwundrak on GitHub (Aug 26, 2019). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/158 ### What is expected Support OSX Currently per default you can not access container with their IPs directly on OSX. There are some workarounds and for me the best working thing is https://github.com/AlmirKadric-Published/docker-tuntap-osx . Using this (after setup the routing), I can ping and `dig`/`nslookup` directly to DPS ### What is Happening An issue for me is, that the DPS overwrites all *.docker.internal DNS entries, that also used on windows. That are e.g. host.docker.internal or gateway.docker.internal There is a pull-request, to add this also to linux to provide an "same behaviour on all OSes": https://github.com/docker/libnetwork/pull/2348 . Hopefully it is merged in the next months. Cause of the Docker-for-Mac (DfM) implementation, all others containers can not reach the dns, if I add the volume mapping to `/etc/resolv.conf`, so all builds fails (DNS e.g. for `apt update`) and so on... ### Changes I tried this locally and think, that this should work: - [ ] ignore *.docker.internal and let resolve them from the docker-daemon - [ ] add a flag or an IP option, that is populating to the `resolv.conf` #### What I expect: Mapping the dns-proxy to localhost:53 (localhost = host), populate in the resolv.conf as host.docker.internal (resolved to ip).
kerem 2026-02-26 04:33:55 +03:00
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

@mageddo commented on GitHub (Aug 27, 2019):

@jwundrak Thanks for the very detailed report

<!-- gh-comment-id:525083086 --> @mageddo commented on GitHub (Aug 27, 2019): @jwundrak Thanks for the very detailed report
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

@mageddo commented on GitHub (Aug 27, 2019):

ignore *.docker.internal and let resolve them from the docker-daemon

What's supposed to ignore this entries and forward them to docker daemon?

add a flag or an IP option, that is populating to the resolv.conf

Do you wanna to parameterize which DNS server IP should be written to resolv.conf

<!-- gh-comment-id:525084436 --> @mageddo commented on GitHub (Aug 27, 2019): > ignore *.docker.internal and let resolve them from the docker-daemon What's supposed to ignore this entries and forward them to docker daemon? > add a flag or an IP option, that is populating to the resolv.conf Do you wanna to parameterize which DNS server IP should be written to resolv.conf
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

@mageddo commented on GitHub (Aug 27, 2019):

Okay,

Can you elaborate which is your use case?

DPS will not be useful for the host machine in this case since overlay network is only accessible by the containers connected to it, any swarm container solved IP will not be accessible from the host machine due network scope limitations and bridge networks are not allowed in swarm stack services

The only useful DPS features probably will be cname , the local store entries and the remote proxy DNS.

<!-- gh-comment-id:525100805 --> @mageddo commented on GitHub (Aug 27, 2019): Okay, Can you elaborate which is your use case? DPS will not be useful for the host machine in this case since overlay network is only accessible by the containers connected to it, any swarm container solved IP will not be accessible from the host machine due network scope limitations and bridge networks are not allowed in swarm stack services The only useful DPS features probably will be cname , the local store entries and the remote proxy DNS.
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

@jwundrak commented on GitHub (Aug 27, 2019):

@mageddo Thanks for the fast response

The use case is, that we have some developer machines, that should be available on the host machine. eg mydev.docker. On Linux this works pretty well, but on OSX not. (Windows I don't known, but there is a documentation for that, I think this also works).

add a flag or an IP option, that is populating to the resolv.conf

Do you wanna to parameterize which DNS server IP should be written to resolv.conf

What I want is, that we add in the resolv.conf the gateway.docker.internal (for me this is 192.168.65.1). If I map the port 53 from DPS to the "localhost", than all containers can access them. Now it is in its own network like 172.17.20.0/24 and on build 172.17.21.0/24 can not resolve any dns queries.
I think, do allow some ip is not pretty well. Maybe we can make a os switch inside your code or an option like: auto-os or something (For me: we want the dev-ENV on OSX/Linux/Win)

ignore *.docker.internal and let resolve them from the docker-daemon

What's supposed to ignore this entries and forward them to docker daemon?

How i can ignore them? I added host.* and gateway.* as predefined entries in the config. On OSX per default all containers use as NS the IP of gateway.docker.internal, which is for me 192.168.65.1. The best, I think, is to resolve everything from docker.internal to this IP. Should be possible or?!

<!-- gh-comment-id:525216167 --> @jwundrak commented on GitHub (Aug 27, 2019): @mageddo Thanks for the fast response The use case is, that we have some developer machines, that should be available on the host machine. eg `mydev.docker`. On Linux this works pretty well, but on OSX not. (Windows I don't known, but there is a documentation for that, I think this also works). >> add a flag or an IP option, that is populating to the resolv.conf > Do you wanna to parameterize which DNS server IP should be written to resolv.conf What I want is, that we add in the resolv.conf the gateway.docker.internal (for me this is 192.168.65.1). If I map the port 53 from DPS to the "localhost", than all containers can access them. Now it is in its own network like 172.17.20.0/24 and on build 172.17.21.0/24 can not resolve any dns queries. I think, do allow some ip is not pretty well. Maybe we can make a os switch inside your code or an option like: auto-os or something (For me: we want the dev-ENV on OSX/Linux/Win) >> ignore *.docker.internal and let resolve them from the docker-daemon > What's supposed to ignore this entries and forward them to docker daemon? How i can ignore them? I added host.* and gateway.* as predefined entries in the config. On OSX per default all containers use as NS the IP of gateway.docker.internal, which is for me 192.168.65.1. The best, I think, is to resolve everything from docker.internal to this IP. Should be possible or?!
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

@jwundrak commented on GitHub (Sep 2, 2019):

@mageddo Got you any time, to what at this?

With binding *:53 to "localhost" and avoid mapping of the resolv.conf, it is run fine for me, but i have to add host.docker.internal and gateway.docker.internal as preconfigured values in the config.json .

<!-- gh-comment-id:527221051 --> @jwundrak commented on GitHub (Sep 2, 2019): @mageddo Got you any time, to what at this? With binding *:53 to "localhost" and avoid mapping of the resolv.conf, it is run fine for me, but i have to add `host.docker.internal` and `gateway.docker.internal` as preconfigured values in the `config.json` .
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

@TheKnightCoder commented on GitHub (Oct 29, 2019):

Any progress with this? would love this feature

Also a detailed instructions of the workaround could be useful

<!-- gh-comment-id:547587717 --> @TheKnightCoder commented on GitHub (Oct 29, 2019): Any progress with this? would love this feature Also a detailed instructions of the workaround could be useful
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

@mageddo commented on GitHub (Nov 12, 2019):

@TheKnightCoder I'm trying to figure out yet exactly must be did to get DPS working on Mac yet.

@jwundrak

So if you

  • Configure your config.json like attach 1
  • Start DPS publishing the 53 port like attach 2
  • Configure /etc/resolv.conf on host machine like attach 3

Then you get DPS fully working?

Attach 3

nameserver 127.0.0.1

Attach 2

docker run --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
-p 53:53 \
-v -v config.json:/app/conf/config.json \
defreitas/dns-proxy-server

Attach 1

{
	"version": 2,
	"remoteDnsServers": [],
	"envs": [
		{
			"name": "",
			"hostnames": [
				{
					"hostname": "host.docker.internal",
					"ip": "",
					"target": "host.docker",
					"ttl": 60,
					"type": "CNAME"
				},
				{
					"hostname": "gateway.docker.internal",
					"ip": "",
					"target": "host.docker",
					"ttl": 60,
					"type": "CNAME"
				}
			]
		}
	],
	"activeEnv": "",
	"webServerPort": 0,
	"dnsServerPort": 0,
	"defaultDns": null,
	"logLevel": "",
	"logFile": "",
	"registerContainerNames": false,
	"hostMachineHostname": "",
	"domain": "",
	"dpsNetwork": false,
	"dpsNetworkAutoConnect": false
}
<!-- gh-comment-id:552683816 --> @mageddo commented on GitHub (Nov 12, 2019): @TheKnightCoder I'm trying to figure out yet exactly must be did to get DPS working on Mac yet. @jwundrak So if you * Configure your `config.json` like attach 1 * Start DPS publishing the **53** port like attach 2 * Configure `/etc/resolv.conf` on host machine like attach 3 Then you get DPS fully working? Attach 3 ``` nameserver 127.0.0.1 ``` Attach 2 ```bash docker run --rm \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 53:53 \ -v -v config.json:/app/conf/config.json \ defreitas/dns-proxy-server ``` Attach 1 ```json { "version": 2, "remoteDnsServers": [], "envs": [ { "name": "", "hostnames": [ { "hostname": "host.docker.internal", "ip": "", "target": "host.docker", "ttl": 60, "type": "CNAME" }, { "hostname": "gateway.docker.internal", "ip": "", "target": "host.docker", "ttl": 60, "type": "CNAME" } ] } ], "activeEnv": "", "webServerPort": 0, "dnsServerPort": 0, "defaultDns": null, "logLevel": "", "logFile": "", "registerContainerNames": false, "hostMachineHostname": "", "domain": "", "dpsNetwork": false, "dpsNetworkAutoConnect": false } ```
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

@gchari-asapp commented on GitHub (Aug 4, 2020):

I tried and it is not working.

I made a couple of corrections still.

The docker run must specify the port as udp 53:53/udp. In addition the current command mounts config.json as a directory. It thus needs to be $(pwd)/config.json:... . Finally, at least macos 10.14 does not use resolv.conf. To add the localhost as a nameserver I run the following command: sudo networksetup -setdnsservers Wi-Fi 127.0.0.1.

After this corrections DPS starts logging requests. However the resolution is failing.

nslookup google.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	google.com
Address: 172.217.172.78

❯ nslookup dns.mageddo
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find dns.mageddo: NXDOMAIN
<!-- gh-comment-id:668659755 --> @gchari-asapp commented on GitHub (Aug 4, 2020): I tried and it is not working. I made a couple of corrections still. The docker run must specify the port as udp `53:53/udp`. In addition the current command mounts `config.json` as a directory. It thus needs to be `$(pwd)/config.json:... `. Finally, at least `macos 10.14` does not use resolv.conf. To add the localhost as a nameserver I run the following command: `sudo networksetup -setdnsservers Wi-Fi 127.0.0.1`. After this corrections DPS starts logging requests. However the resolution is failing. ``` nslookup google.com Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: google.com Address: 172.217.172.78 ❯ nslookup dns.mageddo Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find dns.mageddo: NXDOMAIN ```
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

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

I think you get close @gchari-asapp , probably networksetup -setdnsservers Wi-Fi will work correctly only when specifying a IP which isn't a loopback address, need to specify your network interface IP, something like '192.168.0.x'.

<!-- gh-comment-id:1454365475 --> @mageddo commented on GitHub (Mar 4, 2023): I think you get close @gchari-asapp , probably `networksetup -setdnsservers Wi-Fi ` will work correctly only when specifying a IP which isn't a loopback address, need to specify your network interface IP, something like '192.168.0.x'.
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

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

I'm finally with access to a MacBook so I did some tests using DPS 3.7.0, my conclusion is it's now working the best it can on Mac due Docker for Mac limitations, can you confirm that or am I missing some feature? Got the following results after ran the steps below:

$ sudo ./dns-proxy-server

A nginx container:

$ docker run --rm --hostname nginx.docker nginx

Running a container to make some tests

$ docker run --rm -it --hostname alpine.docker alpine sh

# Docker gateway is solving 
$ nslookup gateway.docker.internal
Server:   192.168.65.7
Address:  192.168.65.7:53

Non-authoritative answer:
Name: gateway.docker.internal
Address: 192.168.65.2

Non-authoritative answer:

$ nslookup host.docker.internal
Server:   192.168.65.7
Address:  192.168.65.7:53

Non-authoritative answer:

Non-authoritative answer:
Name: host.docker.internal
Address: 192.168.65.2

# DPS docker container feature is also solving
$ nslookup alpine.docker
Server:   192.168.65.7
Address:  192.168.65.7:53

Non-authoritative answer:
Name: alpine.docker
Address: 172.17.0.4

Non-authoritative answer:

# Internet resolution also working
$ nslookup google.com
Server:   192.168.65.7
Address:  192.168.65.7:53

Non-authoritative answer:
Name: google.com
Address: 2800:3f0:4001:833::200e

Non-authoritative answer:
Name: google.com
Address: 142.250.219.238

# Other container also solving 
$ wget -q -S -O - nginx.docker
  HTTP/1.1 200 OK
  Server: nginx/1.23.3
  Date: Sat, 04 Mar 2023 03:50:52 GMT
  Content-Type: text/html
  Content-Length: 615
  Last-Modified: Tue, 13 Dec 2022 15:53:53 GMT
  Connection: close
  ETag: "6398a011-267"
  Accept-Ranges: bytes
<!-- gh-comment-id:1454365859 --> @mageddo commented on GitHub (Mar 4, 2023): I'm finally with access to a MacBook so I did some tests using DPS [3.7.0][1], my conclusion is it's now working the best it can on Mac due Docker for Mac limitations, can you confirm that or am I missing some feature? Got the following results after ran the steps below: ```bash $ sudo ./dns-proxy-server ``` A nginx container: ```bash $ docker run --rm --hostname nginx.docker nginx ``` Running a container to make some tests ```bash $ docker run --rm -it --hostname alpine.docker alpine sh # Docker gateway is solving $ nslookup gateway.docker.internal Server: 192.168.65.7 Address: 192.168.65.7:53 Non-authoritative answer: Name: gateway.docker.internal Address: 192.168.65.2 Non-authoritative answer: $ nslookup host.docker.internal Server: 192.168.65.7 Address: 192.168.65.7:53 Non-authoritative answer: Non-authoritative answer: Name: host.docker.internal Address: 192.168.65.2 # DPS docker container feature is also solving $ nslookup alpine.docker Server: 192.168.65.7 Address: 192.168.65.7:53 Non-authoritative answer: Name: alpine.docker Address: 172.17.0.4 Non-authoritative answer: # Internet resolution also working $ nslookup google.com Server: 192.168.65.7 Address: 192.168.65.7:53 Non-authoritative answer: Name: google.com Address: 2800:3f0:4001:833::200e Non-authoritative answer: Name: google.com Address: 142.250.219.238 # Other container also solving $ wget -q -S -O - nginx.docker HTTP/1.1 200 OK Server: nginx/1.23.3 Date: Sat, 04 Mar 2023 03:50:52 GMT Content-Type: text/html Content-Length: 615 Last-Modified: Tue, 13 Dec 2022 15:53:53 GMT Connection: close ETag: "6398a011-267" Accept-Ranges: bytes ``` [1]: https://github.com/mageddo/dns-proxy-server/releases/download/3.7.0/dns-proxy-server-linux-amd64-3.7.0.tgz
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

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

Checkout running it docs for Mac (actually nothing special for Mac, just some hints)

<!-- gh-comment-id:1454367821 --> @mageddo commented on GitHub (Mar 4, 2023): Checkout [running it docs for Mac][1] (actually nothing special for Mac, just some hints) [1]: http://mageddo.github.io/dns-proxy-server/latest/en/1-getting-started/running-it/#running-on-mac
kerem commented 2026-02-26 04:33:56 +03:00
Author
Owner
Copy link

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

This is a duplication of #44

<!-- gh-comment-id:1454383705 --> @mageddo commented on GitHub (Mar 4, 2023): This is a duplication of #44
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
gh-pages
develop
feat/138_2
feat/629
feat/594
5.9.0
5.9.0-snapshot
5.8.4
5.8.4-snapshot
5.8.3-snapshot
5.8.2-snapshot
5.8.1-snapshot
5.8.0-snapshot
5.7.0-snapshot
5.6.2-snapshot
5.6.1-snapshot
5.6.0-snapshot
5.5.1-snapshot
5.5.0-snapshot
5.4.0-snapshot
5.3.0-snapshot
5.2.0-snapshot
5.1.3-snapshot
5.1.2-snapshot
5.1.0-snapshot
5.0.5-snapshot
5.0.3-snapshot
5.0.2-snapshot
5.0.1-snapshot
5.0.0-snapshot
4.3.0-snapshot
4.2.0-snapshot
4.0.0
4.0.0-snapshot
3.32.7
3.32.7-snapshot
3.32.6
3.32.6-snapshot
3.32.5-snapshot
3.32.4
3.32.4-snapshot
3.32.3
3.32.3-snapshot
3.32.2-snapshot
3.32.1-snapshot
3.32.0-snapshot
3.31.1-snapshot
3.31.0-snapshot
3.30.5-snapshot
3.30.4
3.30.4-snapshot
3.30.3-snapshot
3.30.2-snapshot
3.30.1
3.30.1-snapshot
3.30.0-snapshot
3.29.0-snapshot
3.27.0
3.27.0-snapshot
3.26.0-snapshot
3.25.14
3.25.14-snapshot
3.25.13-snapshot
3.25.12-snapshot
3.25.11
3.25.11-snapshot
3.25.10
3.25.10-snapshot
3.25.9-snapshot
3.25.8-snapshot
3.25.7-snapshot
3.25.6-snapshot
3.25.4-snapshot
3.25.3-snapshot
3.25.2-snapshot
3.25.1-snapshot
3.25.0-snapshot
3.24.2
3.24.2-snapshot
3.24.1
3.24.1-snapshot
3.24.0-snapshot
3.23.0-snapshot
3.22.2-snapshot
3.22.3-snapshot
3.22.1-snapshot
3.21.3-snapshot
3.22.0-snapshot
3.21.2-snapshot
3.21.1-snapshot
3.20.0-snapshot
3.21.0-snapshot
3.19.7-snapshot
3.19.6-snapshot
3.19.5-snapshot
3.19.4-snapshot
3.19.3-snapshot
3.19.2-snapshot
3.19.1
3.19.1-snapshot
3.19.0
3.18.5-snapshot
3.18.4-snapshot
3.18.3-snapshot
3.18.2
3.18.2-snapshot
3.18.1-snapshot
3.18.0-snapshot
3.17.3-snapshot
3.17.2-snapshot
3.17.1-snapshot
3.17.0-snapshot
3.16.3-snapshot
3.16.2-snapshot
3.16.1-snapshot
3.16.0-snapshot
3.15.13-snapshot
3.15.12-snapshot
3.15.11-snapshot
3.15.10-snapshot
3.15.9-snapshot
3.15.8-snapshot
3.15.7-snapshot
3.15.6-snapshot
3.15.5-snapshot
3.15.4-snapshot
3.15.3-snapshot
3.15.2-snapshot
3.15.1-snapshot
3.15.0-snapshot
3.14.5
3.14.4
3.14.3
3.14.3-snapshot
3.14.2-snapshot
3.14.1-snapshot
3.14.0-snapshot
3.13.1
3.13.1-snapshot
3.13.0-snapshot
3.12.1
3.12.0
3.11.0
3.10.2-snapshot
3.10.3-snapshot
3.10.4-snapshot
3.10.5-snapshot
3.10.1-snapshot
3.9.2
3.9.1
3.9.0
3.8.1-last-version-with-quarkus
3.8.1
3.8.0
3.7.0
3.6.0
3.5.3
3.5.2
3.5.0
3.4.0-beta
3.3.0-beta
3.2.5-beta
3.2.4-beta
3.2.3-beta
3.2.2-beta
3.2.1-beta
3.2.0-beta
3.1.7-beta
3.1.6-beta
3.1.5-beta
3.1.4-beta
3.1.3-beta
3.1.2-beta
b-jre-8
3.1.1-beta
3.1.0-beta
3.0.4-beta
3.0.3-beta
3.0.2-beta
3.0.1-beta
v2-golang
2.19.5
2.19.4
2.19.3
2.19.2
2.19.1
2.19.0
2.18.7
2.18.6
2.18.5
2.18.4
2.18.3
2.18.2
2.18.1
2.18.0
2.17.4
2.17.3
2.17.2
2.17.1
2.17.0
2.16.0
2.15.0
2.14.6
2.14.5
2.14.4
2.14.2
2.14.1
2.14.0
2.13.2
2.13.1
2.13.0
2.12.0
2.11.0
2.10.4
2.10.3
2.10.2
2.10.1
2.10.0
2.9.1
2.9.0
2.8.0
2.7.0
2.6.1
2.6.0
2.5.4
2.5.3
2.5.2
2.5.1
2.5.0
2.4.1
2.4.0
2.3.3
2.2.3
2.2.2
2.2.1
2.2.0
2.1.8
2.1.7
2.1.6
2.1.5
2.1.2
2.1.1
2.1.0
2.0.21
2.0.20
2.0.19
2.0.18
2.0.17
2.0.16
2.0.9
2.0.5
2.0.4
v1-nodejs
1.8.1
1.8.0
1.7.7
1.7.6
1.7.5
1.7.4
1.7.3
1.7.2
1.7.1
1.7.0
1.6.9
1.6.8
1.6.7
1.6.6
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.0
1.4.0
1.3.5
1.3.4
1.3.3
1.3.2
1.3.1
1.3.0
peteris-version
1.1.4-peteris-version
1.2.0
1.1.3
1.1.2
1.1.1
1.1.0
1.0.1
1.0.0
Labels
Clear labels   
bug

   
confirmed

   
discussion

   
duplicate

   
enhancement

   
feature

   
feature-request

   
not-planned

   
pull-request

Mirrored from GitHub Pull Request

  
secondary-feature

   
stale

   
triage

   
waiting-feedback
No labels
bug
confirmed
discussion
duplicate
enhancement
feature
feature-request
not-planned
pull-request
secondary-feature
stale
triage
waiting-feedback
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/dns-proxy-server-mageddo#63
No description provided.