HOSTNAMES Env dont work if kernel option ipv6.disable=1

[sh3bang]

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

Note: noRemoteServers = false

[mageddo]

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

[sh3bang]

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 ;)

[mageddo]

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.

[mageddo]

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?

[mageddo]

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.

[mageddo]

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

[github-actions]

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

[github-actions]

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

[aricooperdavis]

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):

• https://serverfault.com/questions/1121447/nslookup-finds-ip-address-but-still-claims-nxdomain

[mageddo]

@aricooperdavis

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