{"id":1212,"date":"2023-12-09T15:49:55","date_gmt":"2023-12-09T03:49:55","guid":{"rendered":"https:\/\/mdickinson.dyndns.org\/php\/wordpress\/?p=1212"},"modified":"2024-01-17T17:26:41","modified_gmt":"2024-01-17T05:26:41","slug":"setting-up-a-dns-dnsmasq-server-for-your-home-network","status":"publish","type":"post","link":"https:\/\/mdickinson.dyndns.org\/php\/wordpress\/?p=1212","title":{"rendered":"Setting up a DNS (dnsmasq) server for your home network"},"content":{"rendered":"

\nFirst a what this post is and is not<\/b>. It covers only using dnsmasq<\/b><\/em>.\n<\/p>\n

Who this post is for<\/h2>\n

\nIt is<\/b> is primarily for people that have a lot of VMs running in their
\nhome network and are finding the time needed to keep \/etc\/hosts files
\nup to date on multiple machines.\n<\/p>\n

\nIt is<\/b> is for people that want a simple home network dns resolver
\nas the solution rather than investigate deployment tools that could push out
\nhosts files to dozens of VMs\/servers.\n<\/p>\n

\nit is<\/b> for people who used to have dnsmasq working and then it suddenly all
\n broke a few years ago.
\n(which is a read the docs, the way short names were handled by default completely
\nchanged, which is good because now all clients across all OSs can expect the
\nsame responses).\n<\/p>\n

\nAnd the biggee; it is for people who have tried to set it up but have issues
\nwith short names not resolving, SERVFAIL requests coming back, or just a
\ngeneral mess as a result<\/em>. This post covers off the things that are probably
\nbreaking in the way you have set it up.\n<\/p>\n

\nAnd see the very last section on why you would want to, you may not want to bother.\n<\/p>\n

Who this post is not for<\/h2>\n

\nit is definately not<\/em><\/b> for people that want to assign known ip-addresses
\n to the many devices that may connect to their home network via wireless connections…
\n as of course they get the info for wireless connections from your wireless router which
\n is outside the scope of this.
\n
\nThat includes things like laptops that may have both a cabled static address plus a wireless
\ndhcp address to your network active at the sametime, the wireless connection will really
\nmess things up as the dhcp settings happily take precedence over you static ones.\n<\/p>\n

So on to DNSMASQ itself<\/h2>\n

\nAs I am sure you are aware dnsmasq builds it entries by reading the \/etc\/hosts
\nfile in the machine it is running on (by default, you can provide other files if you wish).
\nThat should be simple should it not ?, if your hosts file works it should also work in dnsmasq right ?.
\n
\nOf course not, your hosts files are probably populated with a mix of short names and FQDNs
\nmaking it impossible for a remote client to know what format to use.
\n
\nIf you are reading this post because you may have issues with short names not
\nresolving for some machines, sometimes long names do and sometimes they do not, or
\n generally strange and what appears inconsistent behaviour then read on.\n<\/p>\n

\nThe key thing is that using dnsmasq to privide DNS lookup services for
\nyour home network is that everything in your home network should be in the
\nsame domain<\/em>.
\n
\nSo the issues you experience could be caused by\n<\/p>\n

    \n
  • you have not configured your domain in dnsmasq<\/li>\n
  • your servers were installed using defaults like localdomain or
    \nif built using dhcp before assigning a static address will be in your
    \nrouters domain (Home, D-Link etc) instead of your home domain<\/li>\n
  • you have made life over complicated by having both short named and FQDN names
    \nin the hosts file used by dnsmasq<\/li>\n<\/ul>\n

    STEP1 – configure DNSMASQ properly<\/h3>\n

    \nFirst step: in any \/etc\/hosts file on servers running dnsmasq only have the
    \nshort names of the servers (ie: do not have entries like myserver1.myhomenet.org;
    \nyou would only have a entry for myserver1). If you have a FQDN in there you
    \nare doing it all wrong.\n<\/p>\n

    \nSecond Step: in \/etc\/dnsmasq.conf search for the line “#local=\/localnet\/” and
    \nchange it to your domain, for example “local=\/myhomenet.org\/” uncommented of course).
    \n
    \nThe effect of this change is that dnsmasq will append myhomenet.org to all the short
    \nnames read from the hosts file it uses (short name being anything without a trailing
    \ndot and data). You may wonder why this is going to help if you want to lookup a short
    \nname; read on as it is the clients fault<\/em>.
    \nRemember to change the example myhomenet.org to your domain of course<\/b>.\n<\/p>\n

    \nThird step:
    \nIn dnsmasq.conf uncomment “domain-needed” and “bogus-priv”. You do not want
    \nshort name queries forwarded to the internet;
    \nand we will be correcting client queries later.\n<\/p>\n

    \nFourth step:
    \nIn dnsmasq.conf uncomment “strict-order”
    \n
    \nOn your dnsmasq DNS server(s) you should have configured them to first lookup
    \ntheir own ip-address (have your local dnsmasq server ip as the first nameserver as it
    \nshould be the first queried by tools like nslookup if run on your dnsmasq host;
    \nor you will find client queries work but quesries on the dnsmasq host itself do not, so you
    \nmust also tell this dnsmasq server it can resolve names using itself),
    \n
    \nif you do not have strict-order<\/em> plus your dnsmasq server first
    \nnameservers will
    \n be selected from the list in resolv.conf in random
    \n(or round robin) order<\/em> and you will end up with some queries being sent
    \nto DNS servers that know nothing about your local domain (if step3 was not done
    \nto the internet to resolve), and queries will randonly fail.\n<\/p>\n

    \nFor those of you who may have got to playing with this in the past and got
    \nfrustrated by some queries made on the dnsmasq host itself working and some not,
    \nomitting strict-order
    \nis probably why, it would have been occasionally querying the upstream server
    \ninstead of itself (for queries from things like “nslookup”, tools that do
    \nnot use dns but would have used the \/etc\/hosts file will still have worked
    \nmasking any issue… assuming your nsswitch.conf has files as the first entry
    \nwhich I think you should have in a home network, even if a clients host file
    \nhas nothing but localhost in it there is always going to be an exception.
    \n
    \nSlightly of topic, “dig” and “nslookup” work in different ways, if “dig”
    \nis working and “nslookup” is not you have a config error in your DNS setup.\n<\/p>\n

    \nThat is it for the dnsmasq config but I bet it is still not working :-)<\/b>.
    \nWe have to move onto the clients.\n<\/p>\n

    \nRandom tip: if your DNS search list (\/etc\/resolv.conf) on the server running
    \ndnsmasq does not contain
    \nthe ip of the machine running yor dnsmasq instance and the interface it listens
    \non is managed by NetworkManager<\/em> the example below may help (eth0 is the
    \nprimary interface on my server and .181 is the server ip… I lock it down to
    \nserver ip, if you do not do that 127.0.0.1 may work as the first entry).
    \nThe last nameserver (.1) is my router, so with strict order it it cannot find
    \na server locally it will hunt the internet dns servers for it via the router
    \nwith whatver ISP defaults were set on that.\n<\/p>\n

    \r\nnmcli conn modify eth0 ipv4.dns 192.168.1.181,192.168.1.1\r\nsystemctl restart NetworkManager\r\n<\/pre>\n
    STEP2 – configure your clients, thats the real problem<\/h2>\n
    \nWe have dnsmasq setup correctly, why are queries for short names still failing ?.
    \nBecause the clients are misconfigured of course.\n<\/p>\n
    \nNow I do not now how many servers or VMs you have setup, but if you
    \nhave accepted all the default prompts you probably have localdomain as a domain.
    \nIf you installed a VM using DHCP and later changed it to a static address it probably
    \nstill has the domain name assigned by the DHCP sever (or your router).\n<\/p>\n
    \nGuess what, that is not going to work. There are two things you can do,
    \nmanually edit \/etc\/resolv.conf on each server after every reboot or<\/b> fix
    \neach client server.
    \n
    \nDo it properly, fix each client server and for future installs use the
    \ncorrect domain name instead of the defaults.\n<\/p>\n
    \nYou may see in some of your client \/etc\/resolv.conf files entries like “search localdomain” or “domain localdomain” (or on some of my VMs built from DHCP before changing to static things like Home or D-Link).
    \n
    \nThat is obviously a problem that will prevent name lookups working<\/b>… (well part of it as discussed later<\/em>).\n<\/p>\n
    \nWhen a DNS lookup is performed on a short name the client<\/em><\/b> will
    \nappend to any short name (a hostname without a dot) the domain\/search value from
    \nresolv.conf to the query to make a FQDN to be looked up.
    \n
    \nNow if you had a search value in \/etc\/resolv.conf on the client as used in the dnsmasq
    \nsteps as “myhomenet.org” then the short name query would work as the client will
    \nappend the correct domain part and find a match in dnsmasq which has also now been
    \nconfigured to add the domain name to short names.
    \n
    \nBut<\/b> if you have left install defaults like localdomain still lying around
    \n on clients that will never work (unless of course all your servers are setup for
    \n localdomain and you set that as the home network domain in dnsmasq).\n<\/p>\n
    So, first fix the server running dnsmasq, a unique client setup<\/h3>\n
    \nThis is what you want on the server running dnsmasq, not for clients in general.
    \nThe main difference is that the server(s) running dnsmasq must only reference themselves and
    \nupstream DNS resolvers, never any other dnsmasq servers you may be running for the same
    \ndomain or you will be an an endless loop as they refer to each other as they try and
    \n resolve a mistyped host name.\n<\/p>\n
    \nThe assumption in the examples is that the interface name is eth0 and your dns server
    \nip address is 192.168.1.181 with the next upstream server an internet (or router) dns server.
    \nThe next upstream server is required as in many cases you will want to resolve
    \n hostnames\/URLs out in the big wide world also.\n<\/p>\n
    \nRHEL has pretty much dropped \/etc\/sysconfig\/network-scripts and you must use
    \nNetworkManager; NetworkManager is on most Debian servers as well although you
    \ncan still use the older network\/interfaces.d files there\n<\/p>\n
    \nNetworkManager: Assuming eth0 is your interface name and we use the example myhomenet.org.\n<\/p>\n
    \r\nnmcli conn modify eth0 ipv4.dns-search myhomenet.org\r\nnmcli conn modify eth0 ipv4.dns 192.168.1.181,192.168.1.1\r\nsystemctl restart NetworkManager   # applies changes to resolv.conf, no connection drop\r\n<\/pre>\n
    \nFor debian static manual interfaces in \/etc\/network\/interfaces.d\n<\/p>\n
    \r\nauto eth0\r\niface eth0 inet static\r\n      address 192.168.1.181\r\n      netmask 255.255.0.0\r\n      gateway 192.168.1.1\r\n      dns-nameserver 192.168.1.181\r\n      dns-nameserver 192.168.1.1\r\n      dns-search myhomenet.org\r\n      dns-domain myhomenet.org\r\n<\/pre>\n
    When the dnsmasq server is correct, update\/correct all your clients<\/h3>\n
    \nIt goes without saying that to avoid doing this often, always use the correct domain name
    \nand dns list when building a new VM or server so it will never need to be done on those.\n<\/p>\n
    \nIt is important to note a few things here about clients in general that do not run
    \nany copies of dnsmasq themselves.\n<\/p>\n
      \n
    1. they can refer to multiple dnsmasq servers on your home network so they can
      \n resolve names if one is down<\/li>\n
    2. while you can also include an upstream DNS server that will probably stop
      \nthings working correctly again, you should only search your home network dnsmasq servers<\/li>\n<\/ol>\n
      \nThe second point above is an important one<\/em>, you will remember we configured dnsmasq
      \nto use strict order to always check the home network dnsmasq instance first.
      \n
      \nGuess what, clients also are unlikely to use a strict order.
      \nDepending upon what version of operating system you are running lookup operations
      \nby the client are quite likely to round-robin through the nameserver list rather
      \n than use strict order so can
      \nquite easily query the upstream server instead of your dnsmasq server;
      \nthis is something else that can cause dns lookups of servers in your home network
      \nto sometimes work and sometimes not<\/em>.\n<\/p>\n
      \nThe solution I use is to have two dnsmasq servers so one is always available,
      \nall clients only use those two for all name resolution (yes, including external)
      \nand no client has any internet dns resolver address configured relying on the
      \ndnsmasq server instead.
      \n
      \nAs the dnsmasq servers are configured with an upsteam dns then any external
      \nhost name they are unable to resolve themselves (ie: google.com) the dnsmasq servers
      \nwill query the external DNS and resturn the correct ip-address for the name to the client
      \nrequesting it. The client does not need an external dns entry and not having one
      \navioids lookup problems if a client round-robins through name servers.
      \n
      \nRemember this is just for the dns name resolution, once the client has the ip-address
      \nit will cache it and all traffic is from the client direct to the ip-address (unless you go
      \nthrough a proxy of course).\n<\/p>\n
      \nBased on the examples for dnsmasq above with a single server providing dnsmasq,
      \nand letting that dnsmasq server query any upstream dns resolvers on behalf of the client(s)
      \nthen a client configuration would be based on the above examples as below.
      \nIf you have a second dnsmasq servers just add it to the dns ip list,
      \n as long as the two dnsmasq servers do not reference each other in any way to avoid
      \n the endless lokkup loop situation.\n<\/p>\n
      \r\n# NetworkManager\r\nnmcli conn modify eth0 ipv4.dns-search myhomenet.org\r\nnmcli conn modify eth0 ipv4.dns 192.168.1.181\r\nsystemctl restart NetworkManager   # applies changes to resolv.conf, no connection drop\r\n<\/pre>\n
      \nFor debian static manual interfaces in \/etc\/network\/interfaces.d\n<\/p>\n
      \r\n# Debian \/etc\/network\/interfaces.d files (xxx is the client ipaddr)\r\nauto eth0\r\niface eth0 inet static\r\n      address 192.168.1.xxx\r\n      netmask 255.255.0.0\r\n      gateway 192.168.1.1\r\n      dns-nameserver 192.168.1.181\r\n      dns-search myhomenet.org\r\n      dns-domain myhomenet.org\r\n<\/pre>\n
      Congradulations,it now of course works<\/h2>\n
      \nYou can lookup your internal servers from any client by either short or FQDN names
      \nusing yout home network domain without
      \nany issue; and internet names are still resolvable for all your clients.\n<\/p>\n
      Troubleshooting<\/h2>\n