Resolve wildcard.hostname in local network?

Question

For web development on my local server (nginx) I like to create subdomain vhosts for some projects, mostly for convenience and flexibility. For example

server {
    listen       80;
    server_name  project.myHostname;

    root         /that/projects/html/root;
    ....
}

While technically questionable(?) it works fine when making a request to http://project.myHostname on that same machine. But I would like to end up with a configuration where I could access http://project.myHostname from any device connected in the local network (and only there). Just like it works when I access myHostname (Because, I guess my routers DNS resolves that to the local ip). But for the other thing I get all kinds of errors screaming there is no such thing as subdomain.hostname.

The only solution I have found so far is to manually edit the hosts file for every device that should be able to request that "address". Is there a more convenient solution?

I think a major issue here might be my poor grasping of the concepts and relations between hostname, domain name and such. I've been struggling with this for a while but have a hard time getting my head around it.

u1686_grawity · Answer 1 · 2015-12-14T08:20:33.647

You want DNS features, so you should use DNS.

Set up a DNS server such as Bind9 or Unbound – you should use one that's capable of acting as recursive and authoritative at the same time;
Configure your computer to use that server for DNS, instead of your router's;
For performance, set your DNS server to use your usual DNS server addresses as "forwarders" (to make use of their cache).

That's the "preparation" part.

Now create a new zone named "myHostname". It's mostly the same as hosting your own domain like example.com, so you can follow various existing tutorials.

(A zone corresponds to an area of authority – usually a TLD or a "regular" first-level domain, but in some cases a subdomain can be its own zone too.)

Many people use dnsmasq for this purpose, but I don't know if it supports wildcards. Plus its configuration is really obscure, so I'll skip it.

In Unbound (mainly a recursor with very limited authoritative hosting features), it looks like this:

server:
    (other settings...)
    local-zone: "myHostname." static
    local-data: "myHostname. A 192.168.1.234"
    local-data: "*.myHostname. A 192.168.1.234"
    (other settings...)

forward-zone:
    name: "."
    forward-addr: 8.8.8.8
    forward-addr: 8.8.4.4

This points both myHostname and <anything>.myHostname to the given IP address.

In Bind9 (which is a full-featured authoritative server), it's slightly more complex – you need to create a separate "zone file":

; /etc/named.conf

options {
    (other settings...)
    forwarders { 8.8.8.8; 8.8.4.4; };
};

zone "myHostname" {
    type master;
    file "/var/named/myHostname.zone";
};

; /var/named/myHostname.zone (example in short form, with $ORIGIN)

$ORIGIN myHostname.
$TTL 1h
@  SOA  localhost. whatever. ( 1 4h 1h 7d 1h )
@  A    192.168.1.234
*  A    192.168.1.234

; /var/named/myHostname.zone (same example but in full form)

$TTL 1h
myHostname.    SOA  localhost. whatever. ( 1 4h 1h 7d 1h )
myHostname.    A    192.168.1.234
*.myHostname.  A    192.168.1.234

($ORIGIN gets automatically appended to all names if they don't already end with a dot.)

phew, looks like I'm in for a little learning process :-) Thanks for the directions, I will revisit this post as soon as I get around to do this, still have to tackle some priorities first. — Arsylum, Dec 14 '15 at 08:56
The unbound config doesn't seem to work right (anymore? I'm testing with 1.10.1). It'll answer queries to `myHostname.` and literally `*.myHostname.` but not `foo.myHostname.` or `bar.myHostname.` etc. — kbolino, Jul 26 '20 at 16:02

score 1 · Answer 2 · answered Dec 14 '15 at 08:20

There are two issues here.

1) Resolving a name to an IP.

Grawity's answer on this is dead on. For this you either manuyally edit the host file on all the computers (doable for one of two system, but not for large numbers of system).

or you use a system desgined for that. This system is DNS.

DNS is not entirely trivial, but there are many simply guides on how to set it up for limited work. After you have done that you choose to which IP a hostname will resolve by editing a single file.

1B)

I think a major issue here might be my poor grasping of the concepts and relations between hostname, domain name and such. I've been struggling with this for a while but have a hard time getting my head around it.

This might be a good point to start with then. Without a good foundation you are building on quicksand. A full ansswer on that would probably not fit in a single post. So look elsewhere for a full answer.

2) HTTP.

HTTP is a strange protocol. Almost all protocols on the internet work over TCP/IP. Datagrams are send over TCP or UDP to an IP.

HTTP on the other hand also includes the hostname in its requests. This is what allows you to run several different webpages from one IP:port combination. Usually this is very convenient, but it does require you to send (and resolve) the right host. Which means you first want to google around and read a primer on DNS.

Resolve wildcard.hostname in local network?

2 Answers2