Internal domains

cartman82

Say I have a bunch of internal services that are only accessible on the LAN (192.168.1.x subnet). I want people to be able to remember them, but I am too lazy to try and setup internal DNS (and that seems a bit risky as well).

Can I just create a bunch of subdomains of the company's domain and point them to my internal IP-s?

Eg. chat.company.com points to 192.168.1.41.

That should work, right? But how WTF-y is it?

DogsB

You can do what our IT department did and force everyone to manually update their hosts files. Then change the ipaddresses at random and send an email informing everyone of the changes two days later.

LaoC

@cartman82 said in Internal domains:

Can I just create a bunch of subdomains of the company's domain and point them to my internal IP-s?

Eg. chat.company.com points to 192.168.1.41.

That should work, right? But how WTF-y is it?

It does work. It's not considered a good idea to leak private network information to public DNS but arguably that's "security by obscurity". Probably depends most on how susceptible your organization is to social engineering. If someone can call a junior admin and tell them something like "this is Joe from dev, we need the firewall opened to 192.168.1.41 because $managerdude can't access the chat server", that's much more convincing with the bits of internal information than without. May or may not be an issue.

cartman82

@laoc said in Internal domains:

It does work. It's not considered a good idea to leak private network information to public DNS but arguably that's "security by obscurity". Probably depends most on how susceptible your organization is to social engineering. If someone can call a junior admin and tell them something like "this is Joe from dev, we need the firewall opened to 192.168.1.41 because $managerdude can't access the chat server", that's much more convincing with the bits of internal information than without. May or may not be an issue.

That's a good point. Not sure it would work in a small company, but something to think about.

dfdub

@cartman82 said in Internal domains:

I am too lazy to try and setup internal DNS (and that seems a bit risky as well).

If you own a router that supports DNS, it's pretty easy to set up (and foolproof).

cartman82

@dfdub said in Internal domains:

If you own a router that supports DNS, it's pretty easy to set up (and foolproof).

I'm thinking, OK, so I setup DNS on some VPS on our local server and point router towards it.
But then, every internal issue with the server or VPS or anything like that screws internet for the entire office (and many people won't even be using these internal domains).

Since we don't have actual sysadmin (it has once again fallen to me to pretend to be one), I don't want to make this an eternal maintenance issue. I want to set it up once and then for it to just works, and if there are problems, only us developers to be affected, not the entire company.

dfdub

@cartman82 said in Internal domains:

I'm thinking, OK, so I setup DNS on some VPS on our local server and point router towards it.

Ah, you misunderstood what I was trying to say. There are some routers with built-in DNS servers and if you own those, things are easy. If not, then forget my suggestion.

cartman82

@dfdub said in Internal domains:

Ah, you misunderstood what I was trying to say. There are some routers with built-in DNS servers and if you own those, things are easy. If not, then forget my suggestion.

Yeah, no go on that one. I can't clear DNS cache on this fucking Linksys piece of shit, forget about DNS server.

pie_flavor

@dogsb Welcome back!

cartman82

@pie_flavor said in Internal domains:

@dogsb Welcome back!

His passion for internet domain administration was what hooked him back in.

Ben_Warre

Could you use machine names?

sockpuppet7

Why DNS software is still so complicated? It's just a fucking dictionary

Luhmann

@sockpuppet7 said in Internal domains:

a fucking dictionary

so ... UrbanDictionary ?

izzion

@cartman82
Yes, the internal DNS server and "split-brain DNS" method is a very common way to do that, and then for services that should be available both internally and externally, you use the same DNS name for both. Windows Active Directory Domains give you that split brain DNS for free, if you make your AD Domain name the same as your company's public domain (which is actually the current recommended practice, though it wasn't the recommended practice 15 years ago, so pre-existing domains often have a "weird" internal domain, but since you'll still have DNS servers with AD, it's easy enough to do the rest).

Even if you don't have a Windows AD, it's worth the time to set up a simple BIND server internally for split brain DNS.

ben_lubar

@cartman82 There are two ways to do it:

Create a bunch of subdomains that point to internal IPs.
Use non-standard domain names with a custom DNS server. (buildmaster.inedo.local)

The former is better because you can get a wildcard TLS certificate (automatically with Let's Encrypt).

ben_lubar

@ben_lubar said in Internal domains:

@cartman82 There are two ways to do it:

Create a bunch of subdomains that point to internal IPs.

Use non-standard domain names with a custom DNS server. (buildmaster.inedo.local)

The former is better because you can get a wildcard TLS certificate (automatically with Let's Encrypt).

Oh, a third option is to have a wildcard subdomain point to a single internal IP and then have that IP run a reverse proxy to everything else. Less fiddling with DNS, and you don't leak any information about the names of your internal services.

cartman82

@ben_warre said in Internal domains:

Could you use machine names?

How would that work?

cartman82

@ben_lubar said in Internal domains:

@cartman82 There are two ways to do it:

Create a bunch of subdomains that point to internal IPs.
Use non-standard domain names with a custom DNS server. (buildmaster.inedo.local)

The former is better because you can get a wildcard TLS certificate (automatically with Let's Encrypt).

We actually bought a new TLD and pointed subdomains towards internal IP-s.

I'm currently trying to setup a LAN-only mail system :)

I'll later look into whether we can buy a wildcard cert for the new internal-only TLD.

ben_lubar

@cartman82 said in Internal domains:

We actually bought a new TLD

what

You bought something like .google?

cartman82

@ben_lubar said in Internal domains:

We actually bought a new TLD

what
You bought something like .google?

I meant full domain, not subdomain.company.com.

ben_lubar

@cartman82 said in Internal domains:

@ben_lubar said in Internal domains:

We actually bought a new TLD

what
You bought something like .google?

I meant full domain, not subdomain.company.com.

That's second-level. That makes much more sense.

PleegWat

@cartman82 said in Internal domains:

Can I just create a bunch of subdomains of the company's domain and point them to my internal IP-s?

Could see that causing problems if an employee starts their chat client when at the hotel (and not on VPN), so 192.168.1.41 points to a different real server.

ben_lubar

@pleegwat said in Internal domains:

@cartman82 said in Internal domains:

Can I just create a bunch of subdomains of the company's domain and point them to my internal IP-s?

Could see that causing problems if an employee starts their chat client when at the hotel (and not on VPN), so 192.168.1.41 points to a different real server.

Not if you use TLS or some other form of server verification. The worst that could happen would be the hotel knowing the host name of the server, and that happens anyway if you connect using TLS on a connection someone else has control over.

cartman82

@pleegwat said in Internal domains:

Could see that causing problems if an employee starts their chat client when at the hotel (and not on VPN), so 192.168.1.41 points to a different real server.

I thought about it. It seems like, whatever the server, all that will happen is they'll get access denied or crash.

Jaloopa

@ben_lubar said in Internal domains:

@cartman82 said in Internal domains:

@ben_lubar said in Internal domains:

We actually bought a new TLD

what
You bought something like .google?

I meant full domain, not subdomain.company.com.

That's second-level. That makes much more sense.

T for Two. Twond level domain. I thought you knew about this sort of thing Ben

Ben_Warre

@cartman82 if you access //cartmanspc from a webbrowser a webserver running on port 80 would serve a page?

cartman82

@ben_warre said in Internal domains:

@cartman82 if you access //cartmanspc from a webbrowser a webserver running on port 80 would serve a page?

That's only good for localhost, right? Not if I want to access other computers or services.

blakeyrat

@ben_warre I believe that's NetBIOS name resolution and is entirely separate from DNS name resolution. It also seem to be pretty Windows/SMB-centric... I'm not even 100% sure Linux, for example, broadcasts those by default. (Does it?)

izzion

@pleegwat
The whole point of a split-brain DNS deployment is that when your employees aren't on the internal network, they won't get the DNS record for the internal only resource (and if the resource is published externally, they'll get the external IP).

As long as you set up your internal DNS server with an appropriate TTL - 60 minutes is common, though I like even shorter durations of 10 or 15 minutes - then there's no worry about cached results when the employee goes offsite - their computer will recognize that the response from the internal server yesterday is expired, and they'll query for a new result and get a failed query result if the resource isn't published off-site.

There's "security risk" in that your employees will be querying for chat.mycompany.com on regular DNS servers, but that's into serious tin-foil territory unless you're really stupid with your naming conventions (loginwithhunter2.mycompany.com)

mott555

@blakeyrat said in Internal domains:

@ben_warre I believe that's NetBIOS name resolution and is entirely separate from DNS name resolution. It also seem to be pretty Windows/SMB-centric... I'm not even 100% sure Linux, for example, broadcasts those by default. (Does it?)

Some broadcast their hostname, some don't, YMMV even between identical installs. And it seems to involve both NetBIOS and DNS. We made hostname resolution consistent by adding our Linux server hostnames to the company's internal DNS.

izzion

@cartman82
If your DHCP server (or Active Directory Domain Group Policy) is configured to distribute DNS search suffixes, then your computer would try to turn http://cartmanspc/ into http://cartmanspc.company.com/ under the hood. Which is a very effective tool for having different subdomains for pre-production and production environments, but have all of your connection strings remain the same...

Web app connects to "Data Source=db.mydatabase;Initial Database=AllTheData"
The development subdomain is devel.company.com
The production subdomain is company.com
The development database server is accessible via db.mydatabase.devel.company.com (a CNAME pointing to the host record for the development database server)
The production database server is accessible via db.mydatabase.company.com (a CNAME pointing to the host record for the production database server)
The development web server has a DNS Search Suffix of devel.company.com, but not the production suffix
The production web server has a DNS Search Suffix of company.com, but not the development suffix

In that scenario, the same connection string configuration on both the development and production web servers will connect to the respective database server, without any configuration changes when you promote to the next environment.

PJH

@cartman82 said in Internal domains:
[..]

Can I just create a bunch of subdomains of the company's domain and point them to my internal IP-s?

Eg. chat.company.com points to 192.168.1.41.

That should work, right? But how WTF-y is it?

Apart from the advertising internal IP's as previously noted, not too bad. We (by that I mean sysadmins, not dev) did it:

$ dig svn.vandelay.example.net

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.5 <<>> svn.vandelay.example.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12370
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;svn.vandelay.example.net.             IN      A

;; ANSWER SECTION:
svn.vandelay.example.net.      3600    IN      A       172.29.51.55

;; Query time: 53 msec
;; SERVER: 10.255.255.4#53(10.255.255.4)
;; WHEN: Fri Jun  1 14:37:07 2018
;; MSG SIZE  rcvd: 51

Naturally, unless I have my VPN to the office running, things like svn ls svn+ssh://svn.vandelay.example.net don't work as desired from home...

For your own use, it depends, I suppose, on how many hosts there are and how frequently they change of course...

izzion

@mott555
In Windows land, the old way was to use NetBIOS all the time, with a special device - a WINS proxy - to maintain NetBIOS caches across broadcast domains (network subdomains) and allow NetBIOS discovery between devices that couldn't broadcast to each other. As of Windows XP, that was deprecated in favor of DNS Search Suffixes - by default now, a Windows DHCP server will distribute the AD Domain as the default search suffix for all DHCP clients.

With DNS Search Suffixes, when you try to perform name resolution, the computer does the following:

Attempts to resolve the name as entered - mycomputershortname
Tries to append each DNS Search Suffix in order to get a result - mycomputershortname.company.com, mycomputershortname.subdomain.company.com
Gives up and returns NXDOMAIN (no domain found)

This can occasionally lead to hilarity if external DNS is being flaky, because www.google.com can try to fall back to www.google.com.subdomain.company.com for resolution, but since that doesn't really return anyway (unless you've done some truly Special things with your DNS server), it's not a big deal, it just delays the NXDOMAIN point by 5 seconds per search suffix in your list. You can also force your lookup to not try search suffixes by using the TLD . at the end (www.google.com.), which tells Windows "this is a fully qualified domain name, don't try to help me"

Captain

@cartman82 Setting up a dns server is really easy. Don't be afraid to try. I like unbound. It's what the BSDs use by default now.

Unbound DNS Server Tutorial @ Calomel.org

heterodox

@captain said in Internal domains:

@cartman82 Setting up a dns server is really easy. Don't be afraid to try. I like unbound. It's what the BSDs use by default now.

Unbound DNS Server Tutorial @ Calomel.org

IMO Microsoft DNS is the easiest to set up because you can do it all from the GUI. But YMMV depending on whether you already have Windows servers.

Captain

@heterodox said in Internal domains:

IMO Microsoft DNS is the easiest to set up because you can do it all from the GUI. But YMMV depending on whether you already have Windows servers.

True. I've never set up a Microsoft DNS, but using the one that was already set up is easy to use.

It might be nice to be able to keep DNS records in version control, though.

cartman82

@izzion TIL about search suffixes.

Is that a MS only technology? All the articles I found in a quick Google search were tied to Microsoft stack.

As for the configuration through DNS idea, that frankly doesn't sound too useful. Almost all my products have many settings other than DB connection strings. Therefore, since I'll have to develop some way to manage configuration anyway, why not include domains in that same system?

cartman82

@pjh said in Internal domains:

We (by that I mean sysadmins, not dev) did it:

Using 172.16-31 private range, the hipsters.

Captain

@cartman82 It's not MS only. A properly configured linux/bsd would do it too, if you feed it the right DHCP lease.

cartman82

@captain said in Internal domains:

@cartman82 Setting up a dns server is really easy. Don't be afraid to try. I like unbound. It's what the BSDs use by default now.
        Unbound DNS Server Tutorial @ Calomel.org

I did automate a bunch of bind installs a few years ago, I know it's not rocket science. I'd still like to avoid involving the rest of the company with our internal (possibly flakey) on premise infrastructure.

cartman82

Status update.

I spent the entire day fiddling with this, and so far, it's working out pretty nicely. I even did a mail server on LAN, it can talk with other services fine once I shut down the graylister.

One thing that's worrying me is that not all services are using HTTPS. So far we only use desktops, so it's not a big deal. But once the wifi users start connecting their laptops, I'll want to move all coms to HTTPS only, even if we have to suffer red warnings with self-signed certs for a while.

Tsaukpaetra

@izzion said in Internal domains:

unless you've done some truly Special things with your DNS server

I couldn't figure out how to set up an a entry for my subdomain using dnsmasq (still can't) so occasionally I uncomment the line that says "Everything you don't know about is %Server%!".

izzion

@cartman82
dhcpd definitely supports it, some of the more esoteric stripped down DHCP servers may not.

theitdepartment / Aug 26, 2011

Multiple DNS Search Suffixes in dhcpd.conf

So this a quick post because I spent a few hours resolving this issue and wanted to share. The DHCP option domain-search (code 119) is used to specify the DNS domain search list (i.e. “search…

Basically, just add option domain-search with a quote encapsulated comma delimited ordered list of the search suffixes you want your DHCP clients to use.

There's a formal DHCP Option # that is the DNS Search Suffix, but finding the actual number is