starred/dns-proxy-server-mageddo

Fork 0

mirror of https://github.com/mageddo/dns-proxy-server.git synced 2026-04-25 09:25:56 +03:00

[GH-ISSUE #611] Bug: Getting NXDOMAIN when not expected #199

New issue

Closed

opened 2026-02-26 04:34:22 +03:00 by kerem · 5 comments

kerem commented

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

Owner

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

Reported at #478

What is Happening

DPS solvers are forwarding the hostname query to remote solver even when the hostname exists at the dps solvers but haven´t an IP to be answered, then it causes a NXDOMAIN answer got from the remote solver or by the MG_NO_ENTRIES_RESPONSE_CODE when no remote solver could be used.

What is Expected

As explained by @aricooperdavis (ref), following the RFCs, the expected behavior would 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.".

Originally created by @mageddo on GitHub (Nov 27, 2024). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/611 Reported at #478 ## What is Happening DPS solvers are **forwarding** the hostname query to remote solver even when the hostname exists at the dps solvers but haven´t an IP to be answered, then it causes a NXDOMAIN answer got from the remote solver or by the `MG_NO_ENTRIES_RESPONSE_CODE` when no remote solver could be used. ## What is Expected As explained by @aricooperdavis ([ref][1]), following the RFCs, the expected behavior would 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.". [1]: https://github.com/mageddo/dns-proxy-server/issues/478#issuecomment-2500986674

kerem

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

closed this issue
added the
bug
label

kerem commented

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

Author

Owner

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

I already commented in the original issue, but let me give an example about what I wrote there:

With IPv6 disabled:

docker exec -it nginx 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

With IPv6 enabled:

docker exec -it nginx 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

Non-authoritative answer:
Name:   artifactory.docker
Address: fdd8:55dd:548c::1

It doesn't seem to be related to upstream servers as suggested because I have the same behavior with or without upstream servers configured.

@cmiguelcabral commented on GitHub (Dec 19, 2025): I already commented in the original issue, but let me give an example about what I wrote there: With IPv6 disabled: ```` docker exec -it nginx 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 ```` With IPv6 enabled: ```` docker exec -it nginx 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 Non-authoritative answer: Name: artifactory.docker Address: fdd8:55dd:548c::1 ```` It doesn't seem to be related to upstream servers as suggested because I have the same behavior with or without upstream servers configured.

kerem commented

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

Author

Owner

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

@cmiguelcabral

It occurs because NSLOOKUP is asking both IPV4 and IPV6 to DPS into two separate queries, as DPS has not an IPV6 to answer then it responds error code 3 (which is not expected because the hostname exists, even only with ipv4 addresses), then nslookup consider that the process has errors.

The only workaround is to stop asking IPV6 addresses to DPS

 nslookup -po=5354 -type=A  kafka.docker 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#5354

Non-authoritative answer:
Name:	kafka.docker
Address: 172.21.0.3

That's a simple issue to fix on DPS, hope to fix it in the next days.

@mageddo commented on GitHub (Dec 19, 2025): @cmiguelcabral It occurs because NSLOOKUP is asking both IPV4 and IPV6 to DPS into two separate queries, as DPS has not an IPV6 to answer then it responds error code 3 (which is not expected because the hostname exists, even only with ipv4 addresses), then nslookup consider that the process has errors. The only workaround is to stop asking IPV6 addresses to DPS ``` nslookup -po=5354 -type=A kafka.docker 127.0.0.1 Server: 127.0.0.1 Address: 127.0.0.1#5354 Non-authoritative answer: Name: kafka.docker Address: 172.21.0.3 ``` That's a simple issue to fix on DPS, hope to fix it in the next days.

kerem commented

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

Author

Owner

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

That would be great.
Nginx doesn't seem to handle well the way dps is working now.
The truth is that dnsmasq doesn't do the same thing, if there is no IPv6, it just responds the IPv4.

@cmiguelcabral commented on GitHub (Dec 20, 2025): That would be great. Nginx doesn't seem to handle well the way dps is working now. The truth is that dnsmasq doesn't do the same thing, if there is no IPv6, it just responds the IPv4.

kerem commented

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

Author

Owner

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

5.6.1 is out, appreciate feedback, thanks in advance.

@mageddo commented on GitHub (Dec 24, 2025): [5.6.1][1] is out, appreciate feedback, thanks in advance. [1]: https://github.com/mageddo/dns-proxy-server/releases/tag/5.6.1-snapshot

kerem commented

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

Author

Owner

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

5.6.1 is out, appreciate feedback, thanks in advance.

Working perfectly!

Thank you very much for all your work!!

@cmiguelcabral commented on GitHub (Dec 25, 2025): > [5.6.1](https://github.com/mageddo/dns-proxy-server/releases/tag/5.6.1-snapshot) is out, appreciate feedback, thanks in advance. Working perfectly! Thank you very much for all your work!!