unbound - forward-zone - subdomains

[Salamimander]

Hallo,

ich scheitere gerade daran, meine lokale dns zone (eine Subdomain) an meinen DHCP zu forwarden, ich erhalte immer SERVFAIL

    forward-zone:
    name: "lan.dmopp.de"
    forward-addr: 192.168.1.1

Ist der relevante Teil, klappt aber nicht. Frage ich den DNS direkt, klappt es

 

[TheCadillacMan]

Nur eine spontane Idee: Versuch mal einen Punkt am Ende des Domainnames einzufügen: name: "lan.dmopp.de.".

 

[Salamimander]

Gute Idee, auch schon versucht. Leider kein Erfolg.


Auch spannend:
debug: sending to target: <lan.dmopp.de.> 192.168.1.1#53 - Also vom LOG her forwarded er richtig O_o

Edit: Mal die komplette conf

server:
    # If no logfile is specified, syslog is used
    logfile: "/var/lib/unbound/logs/unbound.log"
    verbosity: 1
    module-config: "subnetcache validator iterator"
    #ECS Support
    client-subnet-zone: "."
    client-subnet-always-forward: yes
    send-client-subnet: 0.0.0.0/0
    send-client-subnet: ::0/64

    edns-tcp-keepalive: yes

    port: 5353
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: yes

    # Use this only when you downloaded the list of primary root servers!
    root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the servers authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1232

    # TTL bounds for cache
    cache-min-ttl: 0
    cache-max-ttl: 172800

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes
    prefetch-key: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m
    so-sndbuf: 1m

###PERF STUFF
    # Faster UDP with multithreading (only on Linux).
    so-reuseport: yes

    # more cache memory, rrset=msg*2
    msg-cache-size: 100m
    rrset-cache-size: 200m

    # serve expired entries (but refresh instantly after serving)
    serve-expired: yes

    # more outgoing connections
    # depends on number of cores: 1024/cores - 50
    outgoing-range: 450
    num-queries-per-thread: 225



    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fd11::/8
    private-address: fe80::/10
    private-address: 2406:da00:ff00::/48
    private-address: 2607:fb10::/32
    private-address: 2620:0:ef0::/48
    private-address: 2a00:86c0::/32
    private-address: 2620:108:700f::/48

    private-domain: "lan.dmopp.de"
    private-domain: "xxx.dmopp.de"
    private-domain: "zzz.dmopp.de"

    forward-zone:
      name: "lan.dmopp.de."
      forward-addr: 192.168.1.1

Ergänzung (3. November 2020)

WTF, es scheint an OpenWRT zu liegen O_o. Konnte DEBUG weiter hoch drehen und sobald mein DNS den upstream fragt leitet er weiter. Tue ich das als client selbst, geht es ... W T F

 

[cgs]

Ich habs umgedreht gemacht:

• Zuerst antwortet der dnsmasq (DHCP + localer DNS)
• Ist was lokales dabei antwortet er gleich
• sonst wirds weitergeleitet zum unbound server

 

[Salamimander]

Naja, ich habe im Prinzip 3 DNS Server und will aus Performancegründen kleine Wege

Also:

Client --> PiHole (ohne Cache) --> Unbound --> RootDNS/LocalDNS

Ich habe erstmal wieder auf die static zone zurueck gebaut :|


Edit: Stelle ich OpenWRT als primären DNS ein, sehe ich auch nur noch OpenWRT als Client, was fuers Blocken auch wieder doof ist :|

 

[MisC]

DNSSEC könnte die Ursache sein. Das "forward-zone" bedeutet ja nur dass andere Server gefragt werden aber nicht, dass DNSSEC ignoriert wird.

 

[Die_antwoord]

Client --> PiHole (ohne Cache) --> Unbound --> RootDNS/LocalDNS

in pi.hole eintragen ist keine Option?

 

[Salamimander]

DNSSEC ist nicht involviert. Problem liegt am dnsmasq von openwrt. Er versucht das beim forwarding selbst zu forwarded anstatt zu resolven.

Werde demnächst wieder mal fummeln

@Die_antwoord
nein. Mein pihole/unbound ist eine VM die abhängig vom OPENWRT ist damit alles funktioniert. Kreuzabhängigkeit will ich vermeiden. Der OPENWRT soll unabhängig der VMs auflösen können. Schwieriges Thema ^^

Ich muss raus finden was der dnsmasq des OpenWRT da verbricht.

 

[cgs]

Ich habe das PiHole wegoptimiert

Client -> dnsmasq (DHCP, lan DNS, Filter) -> unbound -> root DNS

• DNSSEC läuft nur in unbound, was dann NXDOMAIN zurücklifert.
• Filter können als Listen bei dnsmasq (so wie es PiHole auch macht) oder in unbound interlegt werden.
• unbound ist nur innerhalb des Servers zu erreichen, also nicht vom client aus

Weiterer Vorteil ist, daß diese albernen Anfragen von Chromium (3x random) als zur localen Domain gehörig erkannt werden, und da es den Rechner lokal nicht gibt kommt gleich NXDOMAIN, d.h. die Anfrage geht garnicht nach Draußen ...

 

[Salamimander]

Mal ein spätes Update: Aktuell läuft alles, wieso genau kann ich aber nicht mehr sagen...

Das hier ist alles was ich gemacht habe:

private-domain: "lan.dmopp.de"
domain-insecure: "lan.dmopp.de"

<snip>


domain-insecure: "168.192.in-addr.arpa."
domain-insecure: "8.6.1.0.2.9.1.0.1.1.d.f.ip6.arpa."
local-zone: "168.192.in-addr.arpa." nodefault
local-zone: "d.f.ip6.arpa." nodefault

stub-zone:
name: "lan.dmopp.de"
stub-addr: 192.168.1.1
stub-addr: fd11:192:168:1::1

<snip>

stub-zone:
name: "168.192.in-addr.arpa."
stub-addr: 192.168.1.1
stub-addr: fd11:192:168:1::1

stub-zone:
name: "d.f.ip6.arpa."
stub-addr: 192.168.1.1
stub-addr: fd11:192:168:1::1

Forward- und reverse DNS laufen so.