DNS service should self-register a host's own certificate as well

[luismanson]

Lighthouses are not able to resolve their own host name when queried.

[vobloeb]

As far as I understood, it is a feature.
The root problem is lighthouses do not report to each other, so, although a lighthouse knows about itself, it has no glue about other lighthouses.

That means a good practice is to run either lighthouse (without tun) or edge (with tun).
If you need both on a machine - run 2 nebula processes, listening on different ports.
That implies lighthouses IPs are fake and not accessible, thus there is no reason to show them in DNS

[bcrisp4]

For anyone who's wondering, I think I've implemented the solution recommended by @kvtb with the following:

$ ./nebula-cert ca -name "Foo CA"
$ ./nebula-cert sign -name lighthouse -ip 192.168.10.1/24
$ cat lighthouse.yml 
---
pki:
  ca: ca.crt
  cert: lighthouse.crt
  key: lighthouse.key
listen:
  host: 0.0.0.0
  port: 4242
tun:
  disabled: true
lighthouse:
  am_lighthouse: true
  serve_dns: true
  dns:
    host: 0.0.0.0
    port: 53
$ cat host.yml 
---
pki:
  ca: ca.crt
  cert: lighthouse.crt
  key: lighthouse.key
listen:
  host: 0.0.0.0
  port: 0
tun:
  dev: nebula1
static_host_map:
  192.168.10.1: <LIGHTHOUSE PUBLIC IP>:4242
lighthouse:
  hosts:
    - 192.168.10.1

Run two Nebula processes. One configured as a lighthouse but with tun disabled (lighthouse.yml) and another configured as a host/client that is configured to connect to this lighthouse (host.yml).

$ sudo ./nebula -config lighthouse.yml
$ sudo ./nebula -config host.yml

Note that root access is still required for the lighthouse Nebula instance even though tun is disabled as we're binding DNS to a privileged port (53).

Now if we query the lighthouse DNS for the hostname set when issuing the certificate (which is just "lighthouse") it should work:

$ nslookup lighthouse 127.0.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   lighthouse
Address: 192.168.10.1

As I understand it, this works because the node is acting as a lighthouse but also connecting to itself as a regular Nebula client, meaning it "learns" about itself.

Using systemd template units would make this pretty easy to manage (e.g. lighthouse@nebula.service and host@nebula.service)

[KillianKemps]

@bcrisp4 I tried your configuration, but I got the following error on the lighthouse: Refusing to handshake with myself. I couldn't query the lighthouse itself in the DNS.

[SamSirry]

@bcrisp4 I tried your configuration, but I got the following error on the lighthouse: Refusing to handshake with myself. I couldn't query the lighthouse itself in the DNS.

I didn't test it, but probably the reason is you must start the real lighthouse process first, so that it can catch the port 4242.

[remcodelange]

Is this a conscious choice to disable this functionality? What are the downsides of this?

[johnmaguire]

Is this a conscious choice to disable this functionality? What are the downsides of this?

As noted earlier by kvtb:

The root problem is lighthouses do not report to each other, so, although a lighthouse knows about itself, it has no glue about other lighthouses.

The DNS server creates entries for hosts which have handshaked with the DNS-serving host. Lighthouses work well for this because in a general sense, "all" hosts connect to Lighthouses. Except themselves and other Lighthouses that is.

See the suggestion above for a workaround: #271 (comment)