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 #478] HOSTNAMES Env dont work if kernel option ipv6.disable=1 #170

New issue
Closed
opened 2026-02-26 04:34:16 +03:00 by kerem · 11 comments
kerem commented 2026-02-26 04:34:16 +03:00
Owner
Copy link

Originally created by @sh3bang on GitHub (Jun 19, 2024).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/478

http://mageddo.github.io/dns-proxy-server/latest/en/2-features/docker-solving/#hostnames-env

Note: noRemoteServers = false

Originally created by @sh3bang on GitHub (Jun 19, 2024). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/478 http://mageddo.github.io/dns-proxy-server/latest/en/2-features/docker-solving/#hostnames-env Note: noRemoteServers = false
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@mageddo commented on GitHub (Jun 19, 2024):

@sh3bang does you have a minimal example Of How to create a Linux env with that kernel option?

<!-- gh-comment-id:2178942046 --> @mageddo commented on GitHub (Jun 19, 2024): @sh3bang does you have a minimal example Of How to create a Linux env with that kernel option?
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@sh3bang commented on GitHub (Jun 19, 2024):

i am wondering how this answer can happen:

root@e40361db30e2:/app# nslookup coupon.dev
Server:		10.5.0.2
Address:	10.5.0.2#53

Non-authoritative answer:
Name:	coupon.dev
Address: 10.5.0.6
** server can't find coupon.dev: NXDOMAIN

NXDOMAIN should be No Answer because domain is existing, but Zone have no AAAA record

DPS is obviously mixing none existing DNS Zones on remote DNS with existing Zones on local/DPS Server by querying always the upstream DNS first.

Correct DNS answer (just ask for A):

root@e40361db30e2:/app# nslookup -type=A coupon.dev
Server:		10.5.0.2
Address:	10.5.0.2#53

Non-authoritative answer:
Name:	coupon.dev
Address: 10.5.0.6

Also correct (A existing, but no AAAA):

root@e40361db30e2:/app# nslookup -type=AAAA hussmedien.de
Server:		10.5.0.2
Address:	10.5.0.2#53

Non-authoritative answer:
*** Can't find hussmedien.de: No answer

DPS config.json

{
  "version" : 2,
  "activeEnv" : "",
  "webServerPort" : 5380,
  "dnsServerPort" : 53,
  "defaultDns" : null,
  "logLevel" : "INFO",
  "logFile" : "console",
  "registerContainerNames" : true,
  "hostMachineHostname" : "host.dev",
  "domain" : "dev",
  "dpsNetwork" : false,
  "dpsNetworkAutoConnect" : false,
  "serverProtocol" : "UDP_TCP",
  "dockerHost" : null,
  "resolvConfOverrideNameServers" : true,
  "noRemoteServers" : false,
  "noEntriesResponseCode" : 3,
  "remoteDnsServers" : [ "10.22.0.31", "10.22.0.32" ],
  "envs" : [ {
    "name" : "",
    "hostnames" : [ {
      "id" : 1,
      "hostname" : "dps-sample.dev",
      "ip" : "192.168.0.254",
      "target" : null,
      "ttl" : 30,
      "type" : "A"
    } ]
  } ]
}

docker-compose.yml

name: docker
services:
  dps:
    container_name: dps
    restart: unless-stopped
    image: defreitas/dns-proxy-server:3.19.5-snapshot
    networks:
      develop:
        ipv4_address: 10.5.0.2
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ~/Projekte/.container/dps/config.json:/app/conf/config.json
  nginx:
    container_name: nginx
    image: nginx:latest
    environment:
      TZ: Europe/Berlin
      HOSTNAMES: coupon.dev
    depends_on:
      - dps
networks:
  develop:
    driver: bridge
    ipam:
      driver: default
      config:
       - subnet: 10.5.0.0/16
         gateway: 10.5.0.1

if you are disable IPv6 completely nothing work as expected ;)

<!-- gh-comment-id:2178988328 --> @sh3bang commented on GitHub (Jun 19, 2024): i am wondering how this answer can happen: ``` root@e40361db30e2:/app# nslookup coupon.dev Server: 10.5.0.2 Address: 10.5.0.2#53 Non-authoritative answer: Name: coupon.dev Address: 10.5.0.6 ** server can't find coupon.dev: NXDOMAIN ``` **NXDOMAIN** should be **No Answer** because domain is existing, but Zone have no AAAA record DPS is obviously mixing none existing DNS Zones on remote DNS with existing Zones on local/DPS Server by querying always the upstream DNS first. Correct DNS answer (just ask for A): ``` root@e40361db30e2:/app# nslookup -type=A coupon.dev Server: 10.5.0.2 Address: 10.5.0.2#53 Non-authoritative answer: Name: coupon.dev Address: 10.5.0.6 ``` Also correct (A existing, but no AAAA): ``` root@e40361db30e2:/app# nslookup -type=AAAA hussmedien.de Server: 10.5.0.2 Address: 10.5.0.2#53 Non-authoritative answer: *** Can't find hussmedien.de: No answer ``` DPS config.json ``` { "version" : 2, "activeEnv" : "", "webServerPort" : 5380, "dnsServerPort" : 53, "defaultDns" : null, "logLevel" : "INFO", "logFile" : "console", "registerContainerNames" : true, "hostMachineHostname" : "host.dev", "domain" : "dev", "dpsNetwork" : false, "dpsNetworkAutoConnect" : false, "serverProtocol" : "UDP_TCP", "dockerHost" : null, "resolvConfOverrideNameServers" : true, "noRemoteServers" : false, "noEntriesResponseCode" : 3, "remoteDnsServers" : [ "10.22.0.31", "10.22.0.32" ], "envs" : [ { "name" : "", "hostnames" : [ { "id" : 1, "hostname" : "dps-sample.dev", "ip" : "192.168.0.254", "target" : null, "ttl" : 30, "type" : "A" } ] } ] } ``` docker-compose.yml ``` name: docker services: dps: container_name: dps restart: unless-stopped image: defreitas/dns-proxy-server:3.19.5-snapshot networks: develop: ipv4_address: 10.5.0.2 volumes: - /var/run/docker.sock:/var/run/docker.sock - ~/Projekte/.container/dps/config.json:/app/conf/config.json nginx: container_name: nginx image: nginx:latest environment: TZ: Europe/Berlin HOSTNAMES: coupon.dev depends_on: - dps networks: develop: driver: bridge ipam: driver: default config: - subnet: 10.5.0.0/16 gateway: 10.5.0.1 ``` if you are disable IPv6 completely nothing work as expected ;)
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@mageddo commented on GitHub (Jun 19, 2024):

So the behavior below is the one you understand as the unexpected behavior?

i am wondering how this answer can happen:

root@e40361db30e2:/app# nslookup coupon.dev
Server:		10.5.0.2
Address:	10.5.0.2#53

Non-authoritative answer:
Name:	coupon.dev
Address: 10.5.0.6
** server can't find coupon.dev: NXDOMAIN

NXDOMAIN should be No Answer because domain is existing, but Zone have no AAAA record

DPS is obviously mixing none existing DNS Zones on remote DNS with existing Zones on local/DPS Server by querying always the upstream DNS first.

<!-- gh-comment-id:2179075268 --> @mageddo commented on GitHub (Jun 19, 2024): So the behavior below is the one you understand as the unexpected behavior? > i am wondering how this answer can happen: > > ``` > root@e40361db30e2:/app# nslookup coupon.dev > Server: 10.5.0.2 > Address: 10.5.0.2#53 > > Non-authoritative answer: > Name: coupon.dev > Address: 10.5.0.6 > ** server can't find coupon.dev: NXDOMAIN > ``` > > **NXDOMAIN** should be **No Answer** because domain is existing, but Zone have no AAAA record > > DPS is obviously mixing none existing DNS Zones on remote DNS with existing Zones on local/DPS Server by querying always the upstream DNS first. >
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@mageddo commented on GitHub (Jun 19, 2024):

I didn't get if "if you are disable IPv6 completely nothing work as expected ;)" suggests another unexpected behavior which wasn't explained, in this case can you describe what happens in this scenario?

<!-- gh-comment-id:2179077306 --> @mageddo commented on GitHub (Jun 19, 2024): I didn't get if "if you are disable IPv6 completely nothing work as expected ;)" suggests another unexpected behavior which wasn't explained, in this case can you describe what happens in this scenario?
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@mageddo commented on GitHub (Jun 19, 2024):

That's the expected behavior because NSLOOKUP query for both A and AAAA records at the same execution

This result says "I found answer for A but didn't for the AAAA"

root@e40361db30e2:/app# nslookup coupon.dev
Server:		10.5.0.2
Address:	10.5.0.2#53

Non-authoritative answer:
Name:	coupon.dev
Address: 10.5.0.6
** server can't find coupon.dev: NXDOMAIN

This another one says "I found no answer at all"

root@e40361db30e2:/app# nslookup -type=AAAA hussmedien.de
Server:		10.5.0.2
Address:	10.5.0.2#53

Non-authoritative answer:
*** Can't find hussmedien.de: No answer

So the behavior below is the one you understand as the unexpected behavior?

i am wondering how this answer can happen:

root@e40361db30e2:/app# nslookup coupon.dev
Server:		10.5.0.2
Address:	10.5.0.2#53

Non-authoritative answer:
Name:	coupon.dev
Address: 10.5.0.6
** server can't find coupon.dev: NXDOMAIN

NXDOMAIN should be No Answer because domain is existing, but Zone have no AAAA record
DPS is obviously mixing none existing DNS Zones on remote DNS with existing Zones on local/DPS Server by querying always the upstream DNS first.

<!-- gh-comment-id:2179091346 --> @mageddo commented on GitHub (Jun 19, 2024): That's the expected behavior because NSLOOKUP query for both A and AAAA records at the same execution This result says "I found answer for A but didn't for the AAAA" ``` root@e40361db30e2:/app# nslookup coupon.dev Server: 10.5.0.2 Address: 10.5.0.2#53 Non-authoritative answer: Name: coupon.dev Address: 10.5.0.6 ** server can't find coupon.dev: NXDOMAIN ``` This another one says "I found no answer at all" ``` root@e40361db30e2:/app# nslookup -type=AAAA hussmedien.de Server: 10.5.0.2 Address: 10.5.0.2#53 Non-authoritative answer: *** Can't find hussmedien.de: No answer ``` > So the behavior below is the one you understand as the unexpected behavior? > > > i am wondering how this answer can happen: > > ``` > > root@e40361db30e2:/app# nslookup coupon.dev > > Server: 10.5.0.2 > > Address: 10.5.0.2#53 > > > > Non-authoritative answer: > > Name: coupon.dev > > Address: 10.5.0.6 > > ** server can't find coupon.dev: NXDOMAIN > > ``` > > > > > > > > > > > > > > > > > > > > > > > > **NXDOMAIN** should be **No Answer** because domain is existing, but Zone have no AAAA record > > DPS is obviously mixing none existing DNS Zones on remote DNS with existing Zones on local/DPS Server by querying always the upstream DNS first.
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@mageddo commented on GitHub (Jun 19, 2024):

DPS is obviously mixing none existing DNS Zones on remote DNS with existing Zones on local/DPS Server by querying always the upstream DNS first.

The A and AAAA are two different queries made to DPS from the nslookup client, so yes, DPS can solve A record from docker,local db and solve AAAA from the remote solver.

Actually I understand that as OK.

The hostname entry existence at the docker solver is not enough criterium to make DPS stop the resolution and don't forward the query to the remote solver.

Maybe this current criterium can be questionable, maybe if the hostname entry exists at the docker solver and even if no IP exists DPS should stop the resolution and answer NXDOMAIN

<!-- gh-comment-id:2179105393 --> @mageddo commented on GitHub (Jun 19, 2024): > DPS is obviously mixing none existing DNS Zones on remote DNS with existing Zones on local/DPS Server by querying always the upstream DNS first. The A and AAAA are two different queries made to DPS from the nslookup client, so yes, DPS can solve A record from docker,local db and solve AAAA from the remote solver. Actually I understand that as OK. The hostname entry existence at the docker solver is not enough criterium to make DPS stop the resolution and don't forward the query to the remote solver. Maybe this current criterium can be questionable, maybe if the hostname entry exists at the docker solver and even if no IP exists DPS should stop the resolution and answer NXDOMAIN
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Aug 7, 2024):

This issue is stale because it has been waiting-feedback for 15 days with no activity.

<!-- gh-comment-id:2272818105 --> @github-actions[bot] commented on GitHub (Aug 7, 2024): This issue is stale because it has been waiting-feedback for 15 days with no activity.
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@github-actions[bot] commented on GitHub (Aug 15, 2024):

This issue was closed because it has been inactive for 7 days since being marked as stale, you can reopen it at any time.

<!-- gh-comment-id:2290820912 --> @github-actions[bot] commented on GitHub (Aug 15, 2024): This issue was closed because it has been inactive for 7 days since being marked as stale, you can reopen it at any time.
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@aricooperdavis commented on GitHub (Nov 26, 2024):

Maybe this current criterium can be questionable, maybe if the hostname entry exists at the docker solver and even if no IP exists DPS should stop the resolution and answer NXDOMAIN.

I am requesting that this be re-opened, as currently the resolver doesn't meet DNS standards. The logic should be:

  • if the domain exists in any solver then that solver should handle the response.
  • if a record of the requested type doesn't exist under that solver then it should return RCODE 0 ("No Error"/"NODATA").

Here are the relevant RFC standards:

  • RFC 1035 states that the "Name Error" RCODE (i.e. 3, "NXDOMAIN") "signifies that the domain name referenced in the query does not exist".
  • RFC 2308 clarifies that the more appropriate RCODE would be "No Error" (i.e. 0, "NODATA"), "which indicates that the name is valid, for the given class, but [there] are no records of the given type.".

Here are some other sources that indicate that this is incorrect and problematic behaviour (because of NXDOMAIN response cacheing):

<!-- gh-comment-id:2500986674 --> @aricooperdavis commented on GitHub (Nov 26, 2024): > Maybe this current criterium can be questionable, maybe if the hostname entry exists at the docker solver and even if no IP exists DPS should stop the resolution and answer NXDOMAIN. I am requesting that this be re-opened, as currently the resolver doesn't meet DNS standards. The logic should be: - if the domain exists in any solver then that solver should handle the response. - if a record of the requested type doesn't exist under that solver then it should return RCODE 0 ("No Error"/"NODATA"). Here are the relevant RFC standards: - [RFC 1035](https://www.rfc-editor.org/rfc/rfc1035#section-4.1.1) states that the "Name Error" RCODE (i.e. 3, "NXDOMAIN") "signifies that the domain name referenced in the query does not exist". - [RFC 2308](https://www.rfc-editor.org/rfc/rfc2308) clarifies that the more appropriate RCODE would be "No Error" (i.e. 0, "NODATA"), "which indicates that the name is valid, for the given class, but [there] are no records of the given type.". Here are some other sources that indicate that this is incorrect and problematic behaviour (because of NXDOMAIN response cacheing): - https://serverfault.com/questions/1121447/nslookup-finds-ip-address-but-still-claims-nxdomain
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

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

@aricooperdavis

Thanks for the evidences, it makes sense for me, creating #611 to treat this behavior.

<!-- gh-comment-id:2504684972 --> @mageddo commented on GitHub (Nov 27, 2024): @aricooperdavis Thanks for the evidences, it makes sense for me, creating #611 to treat this behavior.
kerem commented 2026-02-26 04:34:17 +03:00
Author
Owner
Copy link

@cmiguelcabral commented on GitHub (Dec 19, 2025):

I'm also experiencing the same issue when resolving docker containers.
The only way to have it working is to enable and configure IPv6 on docker, othewise we get a response like this:

/ # nslookup artifactory.docker 172.28.0.2
Server:         172.28.0.2
Address:        172.28.0.2:53

Non-authoritative answer:
Name:   artifactory.docker
Address: 172.25.0.2

** server can't find artifactory.docker: NXDOMAIN

I'm guessing the error ** server can't find artifactory.docker: NXDOMAIN happens because it cannot find the container's IPv6. I'm saying this because if IPv6 is enabled, we get both IPs instead of an IPv4 and an error.
Some services, like nginx, don't work this way.

Can we just turn off IPv6 in dns-proxy-server?
I don't want to enable and configure IPv6 on docker just to have this working...

<!-- gh-comment-id:3676935264 --> @cmiguelcabral commented on GitHub (Dec 19, 2025): I'm also experiencing the same issue when resolving docker containers. The only way to have it working is to enable and configure IPv6 on docker, othewise we get a response like this: ```` / # nslookup artifactory.docker 172.28.0.2 Server: 172.28.0.2 Address: 172.28.0.2:53 Non-authoritative answer: Name: artifactory.docker Address: 172.25.0.2 ** server can't find artifactory.docker: NXDOMAIN ```` I'm guessing the error `** server can't find artifactory.docker: NXDOMAIN` happens because it cannot find the container's IPv6. I'm saying this because if IPv6 is enabled, we get both IPs instead of an IPv4 and an error. Some services, like nginx, don't work this way. Can we just turn off IPv6 in dns-proxy-server? I don't want to enable and configure IPv6 on docker just to have this working...
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#170
No description provided.