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