Documentation question: DNS

[JonTheNiceGuy]

In the example config is a block of config relating to DNS. Does this allow lookups of other nodes by name (e.g. if I have a node "manage_node_a", can I do a DNS lookup of manage_node_a)? Do I need to specify a certain suffix (e.g. manage_node_a.nebula)? Or is it purely to move DNS across the Nebula infrastructure to a specific node in the network? If so, can we control where the DNS will pop out?

[rawdigits]

Exactly right! When you query the nebula dns server, it will return results based on any host it knows about based on that host's name. Of note: if you use a fqdn as the nebula node name, you can use it for dns as well. In my personal network i have delegated .nebula.mydomain.com to my lighthouse, and can now resolve my nebula ips over normal public dns. (which is a security tradeoff I'm willing to make for convenience)

Another handy query type is TXT, which will give you back the certificate details for a host. The txt query must be for a nebula IP (not hostname)

to test each:
dig @[lighthouse_ip] manage_node_a

dig @[lighthouse_ip] -t txt [ip of manage_node_a]

[coderobe]

The txt query must be for a nebula IP (not hostname)

Now that you mention it, what's the reason for that, anyways?

[allout58]

It seems like the lighthouse itself isn't a valid DNS query. Is there a way to add it to the DNS resolver? (and maybe this would be better as a separate issue, let me know if it is)

[rawdigits]

@coderobe I think my initial reasoning was that the IP is the closest thing to a nebula "primary key" of sorts. An overlapping name/etc is probably a mistake that can happen commonly, but only one host can actively have an IP (from the lighthouse perspective) at any moment. (note: if you give the same ip to two hosts, via valid certs, they will fight back and forth, but at the moment you query it will be correct.)

[rawdigits]

@allout58 we don't name them because we don't want to get too attached.

jokes aside, it seems a reasonable request. we register hosts with the hostmap when they connect, and the lighthouse never connects to itself, so it isn't there.

[JonTheNiceGuy]

One other question - is the DNS feature in the lighthouse block intended only for use on Lighthouses, or can any node also expose the DNS feature?

[rawdigits]

@JonTheNiceGuy good question! - It is intended only for lighthouses, mainly because they are the only nodes that generally have tunnels to all nodes in a nebula network, which makes them well positioned for these queries. If it was every node in the network, they would only have partial information, unless they happen to talk to every other host on the network.

[crinklywrappr]

I understand some of this but not all.

Can anyone tell me if the lighthouse uses the certificate hostnames for DNS lookups, and how to configure it, and if any additional configuration is required on the individual hosts?

[rawdigits]

@crinklywrappr you are correct, the "name" field in each certificate becomes something the dns resolver will answer for dynamically. beyond setting serve_dns: true on the lighthouse there is no further configuration to do, besides, of course, telling other nodes to use the lighthouse as a dns server.

[crinklywrappr]

I configured it for port 4253 and it appears to have conflicted with adguard which is running on the same device. After reversing the change adguard seemed happy again. I guess nebula ignored the port setting?

besides, of course, telling other nodes to use the lighthouse as a dns server.

Would I edit the connection the normal way, or can this be placed in config.yml?

[JonTheNiceGuy]

@crinklywrappr Probably worth opening this in a separate issue, with more details about your config file and setup that you're trying to configure, if the following doesn't help you.

As a note, assuming your lighthouse has a Nebula IP of 192.0.2.1/24, it's probably worth defining the lighthouse block like this:

lighthouse:
  am_lighthouse: true
  interval: 60
  serve_dns: true
  dns:
    host: 192.0.2.1
    port: 42453
  hosts:

You'd then configure your downstream hosts to have a DNS server of 192.0.2.1:42453. You would need to ensure that your firewall block on your Lighthouse permits inbound TCP and UDP connections on 42453 from "all" and that your firewall blocks on your nodes permit outbound TCP and UDP connections to 42453 to your lighthouses.

[crinklywrappr]

Updated to 1.1.0 and still couldn't get dns to work.

[crinklywrappr]

Got some help in slack and it turns out that dns was working just fine, only I had a knowledge gap with name resolution policies in windows which was preventing ping from finding the nameserver running on the lighthouse.

If anyone else has a similar issue, they can run:

dig @<lighthouse ip> <name> using WSL (windows subsystem for linux)

If that doesn't resolve the host ip then there is still something wrong with your nebula config/network setup.

If it does work then

Add-DnsClientNrptRule -Namespace ".<domain>" -NameServers "<lighthouse ip>" using powershell will tell windows to include your lighthouse dns server in name lookups.

This means that your nebula hosts will need to share a domain name. You may be able to omit the -Namespace option but I didn't try it.

[NickHerrig]

@allout58 @rawdigits I just opened Issue #560 to address the dns listener not resolving itself in dns queries. I didn't see an related issue filed yet out there, but if so, feel free to combine them and close mine. I'll start looking at the code base and see if I can figure it out!

[ghost]

Anyone else kinda wish they could leverage lighthouse DNS to fallback to specified nameservers to get around having to use dnsmasq?