Hi Maddes,

wow, great. Thanks a lot for such a detailed explanation.
I will try this as soon as I can.

Best regards,

On 22 Sep 2017, at 13:15, M. Buecher wrote:

On 2017-09-16 14:50, Robert N wrote:
Hello all,

I'm trying to replace the DNS/DHCP of my FritzBox home router with dnsmasq.

For IPv4 everything seems to work fine, i.e. when clients request an
IPv4 address, dnsmasq registers their hostnames, so name resolution
for local machines works.

But it does not seem to work for IPv6. I want the clients to do SLAAC
but still dnsmasq should serve AAAA records for local hosts if asked
If I understood correctly, then dnsmasq will only register the
hostnames for which it receives a DHCP request. Does this require the
hosts to request an IP address? Or will the hostnames be added to DNS
also if just the DNS server information is requested?

So I probably should configure what is called stateless DHCPv6:





# This will tell DHCP clients to not ask for proxy information
# Some clients, like Windows 7, will constantly ask if not told NO


However, I don't get dnsmasq to return AAAA records for local hostnames.
Is this configuration basically correct? Or am I missing something?

Best regards,

Hi Robert,

here's how I set up my LAN with FRITZ!Box and dnsmasq on Raspbian/Debian 9.0 (including reasons and thoughts for my decisions):

If just DNS resolution for clients is wanted, then a FRITZ!Box with Stateful DHCPv6 enabled is enough, no dnsmasq necessary.
If wanting other records like CNAME, MX, then dnsmasq is needed.
If wanting a different domain other than fritz.box, e.g. for certificates, then dnsmasq is needed.
Or use dnsmasq just "because I can / want to" :)

If only "LAN addresses" are sufficient, then go with Unique Local Addresses (ULA). These are independent of any ISP connection and/or static/dynamic Global Scope prefixes. Unregistered ULA is fd00::/8, where one has to choose a random /48 prefix from (here the not-so-random fd12:3456:789A::/48). The randomness is important when connecting to other ULA subnets, e.g. via VPN.

If also "WAN addresses" in local DNS are wanted, then more has to be considered: static/dynamic prefix, settings of FRITZ!Box and dnsmasq must work together, etc.

Assuming "LAN addresses" in local DNS are sufficient then the following is necessary: 1. Router Advertisement (RA) with Prefix Information for ULA plus (M)anaged Address Configuration Flag set If the advertising node is not really a router, then the default route for itself must be disabled via its lifetime set to zero. When advertising multiple prefixes and/or additional routes (e.g. for VPN) it can be an advantage to use radvd instead of dnsmasq's RA feature.
2. Stateful DHCPv6 with DNS server
   That's dnsmasq :)

Further assumptions for the "LAN addresses" setup:
* Assuming only DHCPv6 addresses for ULA. As temporary addresses for Site-Local Scope is not really necessary and DHCP addresses carry no hardware information.
  Chosen ULA subnet from above ULA prefix is: fd12:3456:789A:1::/64.
* Guessing SLAAC addresses may not work depending on OS implementation and node configuration (e.g. Windows, only temporary addresses, etc.). * dnsmasq server has a static ULA, e.g. via systemd-networkd, ifupdown/interfaces, dhcpcd, etc.
* dnsmasq server provides complete LAN setup even without FRITZ!Box.

a) Stateful DHCPv6 with DNS server
dnsmasq needs a range for dynamic DHCP, needs to send out his own address (here ULA chosen) and the local domain name on DHCPv6 requests.

b) Router Advertisement
b.1) via dnsmasq
RA must be enabled in dnsmasq, so that dnsmasq sends RA for all explicitly specified dhcp-ranges (but not for an catch-all dhcp-range). If the node is not a router, e.g. to VPN networks, then disable it as default route via ra-param. If SLAAC is wanted, then the wanted mode must be set on the related dhcp-range. See https://weirdfellow.wordpress.com/2014/09/05/dhcpv6-and-ra-with-dnsmasq/
  ## Default interval (1st Zero), Disable Default Route (2nd Zero)

b.2) via radvd
interface eth0
  ## Send RA
  AdvSendAdvert on;
  ## Enable (M)anaged Address Configuration Flag
  AdvManagedFlag on;
  ## Enable (O)ther Configuration Flag
  AdvOtherConfigFlag on;
  ## Disable default route over this node by setting lifetime to zero
  AdvDefaultLifetime 0;

  prefix fd12:3456:789A:1::/64
    ## Enable On-(L)ink Flag
    AdvOnLink on;
    ## Disable (A)utonomous Address-Configuration Flag (SLAAC)
        AdvAutonomous off;

Now there's a working "LAN" based on ULA addresses with dynamic DHCPv6 addresses and fitting dynamic DNS entries.

c) Taking care of the FRITZ!Box plus Dual Stack (yes, IPv4)
c.1) Multiple DNS servers
The FRITZ!Box also advertises the "WAN" prefix, normally from an ISP, plus itself as DNS server with its IPv4 and IPv6 addresses. With IPv6 all DNS servers are queried. If running IPv6-only, then everything should be fine already. Exception: external DNS entries exist for the local domain.
But with IPv4 just one server is queried and that is randomly chosen.
Note that not every OS/device applies this behaviour. In my network the Playstation 4 chooses a random DNS server as described in the RFCs. Therefore for IPv4 (or when external DNS entries exist) all DNS servers must be identical and return the same result for each and every query. But this is not the case here with dnsmasq and the FRITZ!Box, as the FRITZ!Box has no clue about the internal DNS records from dnsmasq.

* Set the FRITZ!Box to not advertise itself as DNS server anymore, neither via RA, DHCPv6 or DHCPv4.
  As of now (FRITZ!OS 6.83)
* Disable DHCPv4 service completely, as only one DHCPv4 per link is allowed and the dnsmasq server will handle all this. * Enter the Link-Local Address or Unique Local Address of the dnsmasq server as DNS server for RAs/DHCPv6.
  * Use Stateless/Stateful DHCPv6 or RA for the "WAN" prefix.
Still the FRITZ!Box should advertise itself as the default route (Standard gateway for Internet Connection). * Assign a static IPv4 address to the FRITZ!Box and the dnsmasq server.
  dnsmasq must also run DHCPv4 for LAN.
    dhcp-option=tag:net1,6,  (dnsmasq as DNS server for IPv4)
dhcp-option=tag:net1,3, (IPv4 of FRITZ!Box as Gateway) * Use an upstream DNS server in dnsmasq for other domains, either static ones like OpenDNS, Google, etc. or relay via the FRITZ!Box to the ISP DNS servers. To relay via the FRITZ!Box use its Link-Local Address (fe80::/10) and/or static IPv4 address. One of these is sufficient.
    server=<internal ip of FRITZ!Box -or- external DNS server>
* Now dnsmasq is the master DNS in the network.

c.2) Problems with "WAN" addresses
The FRITZ!Box can be used to assign semi-static "WAN" addresses (static interface ID) via DHCPv6 to manage Port Forwarding. Still you have to go with hardware based EUI-64 interface IDs, because as soon as the IP address is not reachable the FRITZ!Box regenerates the address for the node from its hardware address as done by SLAAC.

If this wouldn't be the case you could also assign semi-static "WAN" addresses via dnsmasq. Normally this is only needed for servers or nodes that are to be accessed from outside. For this set a catch-all dhcp-range in dnsmasq, so that all static DHCPv6 addresses will be assigned for every advertised subnet including "WAN" prefixes.

Examples for static DHCPv6 addresses
* dhcp-host for dnsmasq
## static address for a server on all subnets via his MAC address (should be outside *all* dhcp-ranges for dynamic assignment)
## static address for a special client on ULA only via his MAC address (should be outside related dhcp-range for dynamic assignment)
* Set the FRITZ!Box to advertise the "WAN" prefix with M-Flag and A-Flag set. This way the nodes, which are explicitly defined in dnsmasq, get an additional static interface ID.

Use the MyFRITZ Port Forwarding to have an external DynDNS entry for each node, e.g. my-server.<hash>.myfritz.net with A and AAAA record. Note that the AAAA record points directly to the node, while the A record points to the FRITZ!Box which NATs the connection.
Take care of this in the packet filter rules, e.g. port redirections.

Kind regards

Dnsmasq-discuss mailing list

Dnsmasq-discuss mailing list

Reply via email to