Problems with local iPv6 DNS/DHCP resolving

Hi

I have problems with resolving IPv6 addresses of local devices. I've set up OpenWrt 18.06.2 on WRT3200ACM.
I have unbound installed with dnsmasq as described here: https://github.com/openwrt/packages/tree/master/net/unbound/files#parallel-dnsmasq

If I look on the Status page, I see active DHCP and DHCP6 leases:


If I query from a device in LAN, I get:

pi@pi-mail:/etc/postfix $ dig pi-nc1
;pi-nc1.                                IN      A

pi@pi-mail:/etc/postfix $ dig pi-nc1.0x42.ch
pi-nc1.0x42.ch.         3600    IN      A       192.168.40.62

pi@pi-mail:/etc/postfix $ dig pi-nc1 AAAA
;pi-nc1.                                IN      AAAA

pi@pi-mail:/etc/postfix $ dig pi-nc1.0x42.ch AAAA
;pi-nc1.0x42.ch.                        IN      AAAA

pi@pi-mail:/etc/postfix $ dig -x 192.168.40.62
62.40.168.192.in-addr.arpa. 3546 IN     PTR     pi-nc1.0x42.ch.

pi@pi-mail:/etc/postfix $ dig -x fd42:0:0:40::62
2.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.0.0.0.0.0.0.2.4.d.f.ip6.arpa. 2060 IN PTR pi-nc1.

pi@pi-mail:/etc/postfix $ host pi-nc1
Host pi-nc1 not found: 3(NXDOMAIN)

pi@pi-mail:/etc/postfix $ host pi-nc1.0x42.ch
pi-nc1.0x42.ch has address 192.168.40.62

While the reverse lookup on the IPv4 returns hostname with domain, the reverse lookup on IPv6 returns the hostname only.

Any suggestion why the IPv6 is not visible on the devices in LAN?

unless you changed it odhcpd is providing dhcpv6 (dnsmasq only dhcpv4)

did you set option dhcp_link 'odhcpd'

you can also run unbound-host -v -r pi-nc1.0x42.ch

Thank you. A bit confusing ..

Is odhcpd capable to provide IPv6 and IPv4? I can set only set one dhcp_link in the Luci interface. If odhcpd can do the dhcp (both) can I disable or remove the dnsmasq? Does not seem to be nesseccary then, correct?

Reading the link above about unbound and odhcpd this also seems to be a bit difficulty.

I want to: use unbound as (my dns resolver to) upstream dns resolver to provide qname-minimization and dnssec. So this one is set.

I also need to query the unbound directly from my pi-mail. So if the unbound is not capable of providing the local DNS information, lookup to local devices would fail.

So what is the best way to handle the local dhcp and dns?

Yes it is indeed, my node is utilizing it to that extent.

Not sure whether it would work or whether really it can be set to either dnsmasq or odhcpd but at least if you want to give a try and manually change the settings via ssh file browser you could see whether this works

list dhcp_link 'odhcpd'
list dhcp_link 'dnsmasq'

mind to restart related services after changes, e.g. unbound, dnsmasq, odhcpd


yeah, but it impacts /cgi-bin/luci/admin/network/dhcp - it will be a blank page , at least when your remove dnsmasq, since the LuCI code is covering only dnsmasq but not odhcpd settings.
Another caveat is that odhcpd has no feature to broadcast ntp server on the network like dnsmasq can.
Ooh, one more thing - removing dnsmasq also wipes the file /etc/config/dhcp and thus all odhcpd settings...


I am good with unbound and odhcpd but I am not relying on some script to write the local-stub zones for unbound, though certainly enticing some convenience, but rather manually creating the stub-zones for unbound. That requires though to become familiar with unbound functionality.

Suppose you will figure out what suits you best.

Interessting, how that simple name to number conversion (DNS to IP) becomes a complex topic ...

As I don't want to break anything in LuCI and the default of 18.06.2 I think I go the following way:
a) go back to 18.06.2 default with dnsmasq
b) Use the unbound on the router for DNSSEC and qname minimizatin and configure it as the only upstream for the dnsmasq.
c) Look into the current unbound config and set it up so it forwards requests to local zones to the dnsmasq .. and as dnsmays shouldn't forward local requests to unbound i should not have ping pongs.
This way I can call the unbound directly from the mail server for DNSSEC validation. And it should also resolve local requests (most of). Correct?

If am not mistaken this script that ships with unbound reads dnsmasq | odhcpd generated lease files and writes local-zone for unbound to query.

To mitigate complexity you could also lets dnsmasq handle dhcpv6 instead of odhcpd

Ok, got it working as expected and runned into next problems ... :frowning:

Seems as if I need to go back to the previous approach. My goals are:

  • Use unbound with qname-minimization and DNSSEC and as the only resolver for outbound connections.
  • Have my Pi with the mail server to use the unbound as it needs DNSSEC validations and I don't want to set up a second unbound in my home network.
  • For two of the zones (LAN, DMZ) I have a pi-hole set up which is announced to the devices in theses zones. This works well. The pi-hole should just do ad blocking and forward anything else to the resolver on the OpenWrt router (no special conditional forwarding).
  • I don't want to break the LuCi and so will use dnsmasq (and odhcp) for DNS.

Setting unbound and dnsmasq in sequence with unbound on 1053, dnsmasq on 53 disallowed item 1 as the resolving on the pi-hole is allways quering port 53, can't get it working to use 1053. :frowning:

So, next solution:

  • unbound as the DNS resolver on the OpenWrt router serving on port 53, using qname minimization and DNSSEC. Can be used directly by the pi-mail.
  • dnsmasq (and odhcp) as it is doing the DHCP
  • use a (or more) forward zone (s) on unbound to forward requests on local network to the dnsmasq.
  • use the unbound as upstream resolver for the pi-hole.

Expected result:

  • This should minimize caching on the OpenWrt router (only unbound, or both only for local entries).
  • It should be fast enough.
  • It shoud be a good start if I can remove dnsmasq later and let odhcp handle the DHCP for IPv4 and IPv6 together with just unbound.

Question: is the link in unbound to the dnsmasq needed? Shoudn't just forwarding local request do the trick?

as far as I can tell from the source code thedhcp_link option for dnsmasq and odhcpd is only necessary for the aforementioned script to produceloca-zone automatically/conveniently. Thus if you generate those manually, for ipv4|6, neither should be required.

This all is fascinating

Both, unbound and dnsmasq, have advantages and disadvantages. Not so staight forward to use either one or the other.

I now have the unbound on the OpenWrt router set up for all outgoing dns requests, with DNSSEC and qname minimization.
It forward all local requests to the dnsmasq on the OpenWrt router which provides the information from DHCP assigned devices.
The pihole propagated to the devices in LAN and DMZ uses the unbound on the OpenWrt router as upstream and does filtering for the Android and Windows devices.
The mail server uses the unbound on the OpenWrt router directly.

So far, so good ... but:

Unbound can't handle requests on hostname without domain, whereas dnsmasq can handle those and has a configuration option to not forward those to an upstream. To prevent leaking of my internal hostnames I download the root zone (hyper local) with unbound.

Unbound also can't use IPv6 for only local requests and not use IPv6 for upstream. Either both or no IPv6. :frowning: If I enable IPv6, unbound tries to query upstream server with IPv6, which is not working, and floods the logfile.
Without IPv6 support, it does not forward local requests on IPv6 to the dnasmasq. So I'm limited to IPv4 for DNS.

Anyway, besides this, all ist working and it's fast.

I'm now awaiting OpenWrt 19 and hope I can replace the dnsmasq simply with odhcpd with the unbound to ease the setup even more.

It should be feasible https://github.com/NLnetLabs/unbound/issues/34#issuecomment-497673509

On my node unbound's upstream connectivity falls back to ipv4 if ipv6 becomes unavailable, with the exception of this bug https://github.com/NLnetLabs/unbound/issues/35 that should be fixed in unbound 1.9.2


Not for dynamic ip assigned clients (that requires a hotplug script) but static it does, e.g.

domain-insecure: devel
private-domain: devel
local-zone: "devel.oclan" static
local-data: "devel.oclan IN A 172.30.67.5"
local-data-ptr: "172.30.67.5 devel.oclan"

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.