I am not very familiar with dynamic DNS, and was curious if I could get it to work for a certain use case.

I have a few Raspberry Pi's I'm setting up for mocking server setups of applications we use at a small scale of our larger setup. They have wireless access capability. I'd like to be able to throw them in a bag and work with them using my laptop in various settings. However, working out the IP's and addresses every time to communicate with them on new networks would be quite annoying (having to change the endpoints all of the applications/configurations are referring to).

I can have normal DNS A Records point to internal IPs and they work great while on private networks. However this is less ideal for changing IPs. Would I be able to use Dynamic DNS to resolve the DNS records to internal addresses? (Such that connecting to a new wireless network all of the lookups would work after everything is connected without having to monkey with the router, custom dns server, etc.)

Initial research indicates Dynamic DNS usually resolves to the external IP whereas in this case I wish to automatically resolve to the address obtained on a specific interface for each client e.g. Eth0.


The simplest way forward would be to use mDNS to do "ad-hoc" DNS resolution amongst the machines in the same subnet. This is, basically, as simple as installing avahi-daemon and libnss-mdns (Debian package names; adjust as appropriate) and making sure your firewall isn't blocking 5353/udp. This will cover both forward and reverse DNS entries, and create resolvable names of the form <hostname>.local for all other machines on the local subnet.

If you need naming which is available beyond the local multicast domain, you'll probably want to setup a DNS server somewhere on the Internet which accepts TSIG-authenticated UPDATE queries, and then configure your client machines to send updates using nsupdate (or some other equivalent means).

  • This elegantly solves my problem. Thank you! For future viewers - I found howtogeek.com/167190/… off of this answer which explains setting up mDNS on the Pi. – Joshua Enfield Nov 20 '15 at 17:17

If by "Dynamic DNS" you mean one of the public DynDNS services like dyn.com or noip.com then no, you cannot have those point to a private IP address. This is because, by design, those services point their A records to the source IP address they see on your registration or update request, which by definition is your public address.

You can however set up a dynamic DNS service of your own which operates in the local network and hence sees the internal IP addresses. There are many ways to achieve this, from classical DHCP sending updates to the DNS server to installing a dyn.com-like service locally. The choice depends on the precise nature of the "various settings" you want to use your crowd of Pi-s in.

Note that you may encounter a bootstrap problem of how the Pi-s will find the dynamic DNS service to register to. This may be solved by using broadcast based techniques like DHCP or mDNS, or by putting the service at a public location on the Internet and setting it up so it receives the IP address to register in the payload of the update request instead of deriving it from its source IP address.


For future viewers....

MDNS was able to solve the problem, but required some extra installation for support on windows which was not ideal. Dynamic DNS actually did end up working.

Using DDClient with the interface set to wlan0 rather than an IP checking external website caused the client to pull the private address for the update to the dynamic DNS provider, and it works perfectly.


If you have no need to communicate with other devices in such new networks it is quite simple. Just give every Pi a static IP and maintain /etc/hosts accordingly. Then they can reach each other nomatter in what environment you are(as long as they are all connected). But you have to consider that you need another subnet then the network youre connected to, otherwise you could get an IP Address conflict.

If you need to communicate with other devices which then are in another subnet, you have a few options. First you need the same as above. To determine the best one it would be necessary to know your applications and use case more specific.

  1. You could set up one Pi as a router, routing between the two subnets. (pros: not very complex, contra: every device you want to communicate with will need a route for your subnet)

  2. Configure your pis that they additionally have an IP from the DHCP Server in that subnet, then use an ddns-client to adjust your ddns server(which runs on one of your pis, and is configured to be the DNS servers for your subnets). So your initial communication to configure your ddns would go over your own subnet. And the further communication over the new subnet your in. (pro: more flexible, con: more complex and therefor more errorprone)

I guess there are other options and possibilities too, but thats what came to my mind.

  • I imagine he is referring to DHCP, having to switch between networks and all. In most enterprise environments, setting up a a router is a big no-no. I also imagine I need to take a look at the links you provided, which appear to be quite-possibly pretty useful. – rubynorails Nov 20 '15 at 7:07
  • I provided technical solutions, if thats not allowed or wanted, it's not my fault, but I'm open for better/simpler solutions. – ddio Nov 20 '15 at 7:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.