0

I have two Raspberry Pis with me - one works as a media player, another as a home server (I call it plug).

In the plug I have installed a couple of applications that has web interfaces - SickBeard (TV Library), CouchPotato (Movie Library), Sabnzbd (Usenet downloader) & Transmission (torrent downloader). I use NGINX as a proxy in front. So my basic idea is that any domain pointing to my "Plug's IP" will route to NGINX, which, based on the domain name used, routes (proxies) the call to the respective application's web interface. For example, dl.plug.example.com (I don't wish to reveal the domain name) will take me to Transmission web interface while usenet.plug.example.com will take me to Sabnzbdplus web interface, pi.plug.example.com will point to the "remote" interface for my other PI (used as media player) & modem.plug.example.com will point to my router's admin page. It does work as expected.

Now I installed and configured BIND and then set my Modem to use Plug's IP as DNS server so that all requests go through Plug's BIND installation. My aim is:

  1. From any device connected to my home network, .plug.example.com should take me to the corresponding machine hosting the application byt through local IP. Means, if I am at home and I type in dl.plug.example.com on my phone's browser it should route to 192.168.1.x. While if I am accessing from outside home it should route to my public ip.
  2. Any request for any other domain name not hosted inside my network, I want BIND to go through Google DNS (8.8.8.8) and resolve it.

The public IP part works. Means when I access from outside my network it does work. When I try from inside network - it fluctuates. That is, at times it routes via my internal IP but other times it takes me through the whole web (routes via public IP). This is one problem I am trying to resolve.

Another problem is that sometimes plug.example.com fails to resolve at all. Through BIND is up and running. When I SSH from terminal via domain name it sometimes doesn't resolve but if I use IP it works smooth. So I am guessing it is some issue with my BIND configuration. As per my modem config, all DNS traffic goes through Plug where BIND is installed. So this shouldn't have happened.

I have uploaded my BIND configuration to: https://drive.google.com/file/d/0B8TuY1aaTEhmbXRGVUkwbUh1bVU/view?usp=sharing

  • 2 Questions: 1.) Are you using MAC Address Binding? 2.) Have you updated your etc/hosts file? – eyoung100 Aug 7 '15 at 18:42
  • Nope I am not using MAC address binding or touching etc/hosts I am looking for a broader one. Changing etc/hosts works only for that computer, I am looking at getting the domains accessible across all devices in my network - hence BIND is installed and router is configured to pass all DNS queries to my BIND installation – Mathew Paret Aug 8 '15 at 3:00
  • That's part of the problem... /etc/hosts is used for local routing, and your devices need static ip's in your local network for your idea to work. Would you like an answer explaining this? – eyoung100 Aug 8 '15 at 3:03
  • When you work in a company do you think that the hosts file is updated in all workstations? Nope, so there should be some option to get it routed properly via a DNS server. – Mathew Paret Aug 8 '15 at 9:22
  • The host file only gets updated in the device serving the company and the ip addresses the company uses are reserved internally. See my answer here Due to the RFC's discussed there, your assumption in number 1 above only holds true if the IP addresses are static. DHCP is rather stupid, ie it only gives out addresses but won't reserve them. See also here – eyoung100 Aug 8 '15 at 19:56
0

Primer

This is the Hosts file from my working Gentoo installation. I've removed the actual routing instructions, in favor of the comments. More on the routing momentarily:

# /etc/hosts: Local Host Database
#
# This file describes a number of aliases-to-address mappings for the for 
# local hosts that share this file.
#
# In the presence of the domain name service or NIS, this file may not be 
# consulted at all; see /etc/host.conf for the resolution order.
#
# Imaginary network.
#10.0.0.2               myname
#10.0.0.3               myfriend
#

# According to RFC 1918, you can use the following IP networks for private 
# nets which will never be connected to the Internet:
#
#       10.0.0.0        -   10.255.255.255
#       172.16.0.0      -   172.31.255.255
#       192.168.0.0     -   192.168.255.255
#
# In case you want to be able to connect directly to the Internet (i.e. not 
# behind a NAT, ADSL router, etc...), you need real official assigned 
# numbers.  Do not try to invent your own network numbers but instead get one 
# from your network provider (if any) or from your regional registry (ARIN, 
# APNIC, LACNIC, RIPE NCC, or AfriNIC.)

Problem

Notice the last comment block regarding private networks. What most people forget when configuring network services for their private network is that there is an imaginary line that splits their internal network (Those IP Addresses covered by RFC 1918, and RFC 6761), and the external network (the Internet for all practical purposes), where the domain IP Addresses are mostly maintained and updated by the Internet Assigned Numbers Authority, aka the IANA. This is also the accepted practice because the IANA is in charge of the DNS Root Zone, The IANA DNS Server has the final say in where a domain resolves to. Imagine your DNS server as the top branch of a tree. If your Server can't resolve a host, your request is sent down the tree, to subsequent branches. Each branch grows in size At the bottom of the tree is the IANA DNS Server.


Solution

It's up to the maintainer/creator of the private network to handle routing inside the private network. In Linux this is done by updating the hosts file, usually stored at /etc/hosts Please note that the OP had only solved half the problem by installing and configuring BIND. BIND properly routes names to hosts and hosts:ports and the other way around. In most servers, one of it's many uses is to bind an external DNS zone (one outside your private network) to an internal DNS zone. See Linux DNS server BIND configuration for more on this. I'll also be referring back to that link when certain sections below warrant.

Since routing internally is governed by different rules (RFC 1918/6761), one must setup static routing so that the address-to-name mappings work in BIND. If the etc/hosts file isn't configured for this, the bind mapping only knows to route the request internally, but not where to route it to. In order to fix this we must add our local mapping (assuming the OP has set the external BIND mapping correctly):

# IPv4 and IPv6 localhost aliases
127.0.0.1       bedroom-gentoo.myISP.net     bedroom-gentoo  localhost
::1             bedroom-gentoo.myISP.net     bedroom-gentoo  localhost

and then our local resolution (in the OP's case)

192.168.1.x    sickbeard.plug.example.com   sickbeard.plug    sickbeard
192.168.1.x    dl.plug.example.com          dl.plug           download
# Add others as needed.

Notice that the private network resolution above can resolve to the FQDN, plus only the host names. The OP and others can adjust this accordingly for the desired behavior. I find that using the FQDN inside the private network is easier than remembering all the host names created.

Step 2 - Optional but Preferred

I'm adding the links below, as readers will see this networking term in most answers connected to network setup. If you're new here, have a read. If you've been around awhile, you may want to skip.

As you can see after reading or not, DHCP is very good at what it does. It's main function from here to eternity will be to give out addresses, whether Public or Private. What DHCP is not good at is remembering the addresses it gives out may actually belong to a server of any sort. In the OP's case, and many other readers, this is the case. That case applies here, as we have "software reserved" the IP address 192.168.1.x to the plug device. In order to make sure that DHCP doesn't stupidly override the server's address after a reboot/restart or power outage, one should use MAC Address Binding in one's router. I took the following screenshot from my Motorola Surfboard, but I've seen the same type of entry screen in most major router brands (D-LINK, NetGear, LinkSys/Cisco). Also, some may name it Reserve, some name it Binding, some MAC Binding:

Reserve By MAC Address

The MAC Address of the server, plug in the OP's case would go in the first box, and the last octet, x from the /etc/hosts file would go into the IP Address box. I believe the Host Name is filled in automatically, but you could use a name from etc/hosts if wanted. This will ensure that we will never have to modify our hosts file because we are forcing DHCP to hand out a Static IP Address. On a side note, this may slightly increase caching of streaming media services. I've used the same concept for my Roku device before.


For Fun

How TCP/IP Works - Youtube

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.