If you have even a passing familiarity with networking. you’re aware that there are certain network ranges that are reserved for private use.

With IPv4, those are:

• 10.* (an entire /8 for you to use!)
• 172.168.*
• 192.168.*

These are nonroutable addresses and you will never find a public Internet service at these addresses.  Typically, organizations will have both public and private.  For example, a company might buy an IPv4 address block and host their web, mail, and other services on it.  But it would be a waste of money to buy public IPs for all their internal computers (such as their database services, individual employees’ workstations, accounting services, etc.) which don’t need to be routed to the Internet.  An organization can build a vast, complex internal network purely on 10.x.

My Confession

At home, I don’t need an /8 for my modest computing environment.  I use 192.168.* addresses.  Naturally, I’d like to have DNS so I can talk to fileshare.example.com instead of 192.168.1.20.  (Of course, I am not using example.com – I use a domain I own).

The right way to do this is to have an internal DNS server.  Or actually, a recursive server that is authoritative for my internal network but forwards other requests to a public DNS server.

But this is rather a bit of work.  Some years ago, I thought…why not just put my internal addresses on my registrar’s DNS service?  

That Is Forbidden!

RFC1918, which defines private networking, says (emphasis mine):

   Because private addresses have no global meaning, routing information
   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links. Routers in networks not
   using private address space, especially those of Internet service
   providers, are expected to be configured to reject (filter out)
   routing information about private networks. If such a router receives
   such information the rejection shall not be treated as a routing
   protocol error.

   Indirect references to such addresses should be contained within the
   enterprise. Prominent examples of such references are DNS Resource
   Records and other information referring to internal private
   addresses. In particular, Internet service providers should take
   measures to prevent such leakage.

In other words, a public DNS server should never return a 192.168.* address.

But It Works

In my experience, this requirement is widely ignored.  Creating private-address DNS records on a public DNS server works just fine, and has for at least 15 years.

I also freely intermix DNS records.  So if you query www.example.com, you’ll get a public IP for a LowEnd VPS I run.  But if you query fileshare.example.com, you’ll get a 192.168.*.

So if you don’t feel like running a DNS server that properly splits public/private, and don’t mind be chastened by the RFC1918 authors, you can do the same.

raindog308

Raindog308 is a longtime LowEndTalk community administrator, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.

As an avid user of LowEndBox providers, Raindog runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.

Beyond the command line, Raindog is a lover of German Shepherds, high-quality knives, target shooting, theology, tabletop RPGs, and hiking in deep, quiet forests.

His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.

You can find him daily in the forums at LowEndTalk under the handle @raindog308.