@tikiyetti for starters you should really update pfsense, that version is quite dated.

If you want to do your own dnssec, then yes you should just resolve which is what unbound does out of the box. Or if your wanting to forward then just pick a dns that does it already and uncheck dnssec in unbound.

I am not aware of any of the major dns providers that do not do dnssec out of the box - some of them have special IPs you can point to that don't do it - like the 9.9.9.10 IP for quad9, etc.. But pretty much any of the major players are doing it out of the box. So there is little point to having unbound try and do it if your forwarding - more likely than not just going to cause you possible issues at some point or another. Its just extra work for something that is already being done.

If you order a cheeseburger, do you scrape off the cheese when you get it an put your own cheese on?

If you want to control putting cheese on your burger, just order it plain (resolve) and then do your own thing for the cheese ;)

@gertjan said in DHCP static mappings that don’t specify hostnames:

@bp81 said in DHCP static mappings that don’t specify hostnames:

I am observing that any client that has a static mapping set but has the hostname field blank in the mapping does not get registered in dns. Non static clients will get registered as expected.

Ask pfSense what it is doing, and it will tell us :

/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid interface1 interface2 .....

The DHCP server config file /var/dhcpd/etc/dhcpd.conf shows me how known static leases are setup for the dhcpd process.
I guess, when creating a static based MAC lease, the info is used to create a /var/dhcpd/etc/dhcpd.conf so dhcpd knows about it, and at the same time a line is added to /etc/hosts.
/etc/hosts is read by unbound when it starts executing.

Take a look at the /var/dhcpd/var/db/dhcpd.leases file.
You will find some leases like :

lease 192.168.1.71 { starts 4 2022/07/21 09:10:02; ends 5 2022/07/22 09:10:02; cltt 4 2022/07/21 11:47:01; binding state active; next binding state free; rewind binding state free; hardware ethernet 18:e7:b0:cc:bc:d9; uid "\001\030\345\260\039\005\341"; client-hostname "iPhone-12-Jullien"; }

and other leases do not have a client-hostname at all.
Or worse, do have a client-hostname, but this name is not DNS-hostname format compatible.
Understand that the client-hostname is given to the dhcpd server by the device, using it's dhcp client. The client-hostname can be setup by the person who admins the device. If the device even has this capability. Many device have a client-hostname hard coded, or omit it.

My /var/dhcpd/var/db/dhcpd.leases file contains 276 leases, and only 12 have a client-hostname given by a device.

So : using the client-hostname given by the client is ..... not a safe solution.

@bp81 said in DHCP static mappings that don’t specify hostnames:

I am observing that any client that has a static mapping set but has the hostname field blank

There was a forum thread a while ago about this question.
Or was it : give MAC and hostname but no IPv4 in a static .... ? Don't recall.

Consider the "DNS" as a phone book.
One rule, no exception. Planet earth goes down ? Still no exceptions.
The rule is :
Phone number <=> Name.
If one of the two is missing the system goes belly up.
DNS down is bad for business (but a very popular amusement, see the forum, it''s an on going occupation for many)

So, I guess pfSense want you (forces you) to give a host name. That's the name that can be checked against DNS name compliance. That's the one being used in for DNS.

You can change this behaviour of course, no need to inform the dhcpd process with a setting. It's all 'pfSense GUI' scripted somewhere in the PHP files.

But take note : if you decide to add some script logic that uses the "client-hostname" (the name given by the client) then you need some other process that parses the /var/dhcpd/var/db/dhcpd.leases and now you have opened a can of worms. Just read the several thouands of forum post about this process :

[/usr/local/sbin/dhcpleases -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php -l /var/dhcpd/var/db/dhcpd.leases

This process is activated when you select this option :
cd729aba-4fc9-4b9c-af35-d7bc5b3c9d92-image.png

This process stops and unbound (your local DNS !) every time a DHCP lease comes in, or gets renewed.

Now you know why I strongly advice to disable this option :

7db176b8-31f7-4071-9d1b-529db9fa7fd7-image.png

for every device that you have to know by hostname, pick an easy DNS hostname, and make a static MAC lease.
I know this isn't the perfect solution, but it's the one that works, is easy to maintain, and unbound will restart far less often, so DNS keeps on working, and the cache gets build and stays valid.

This one :

a26ab38c-7ba1-4263-8bb0-5a5f9e192d9a-image.png

is 'harmless' as /etc/hosts only gets read when unbound starts.

In short, it appears it is not possible to create the behavior I'm looking for. It's not terribly important to us, it just would've been nice.

The background on our infrastructure is that we have a mixed environment administered by Active Directory and Windows DNS. We have Windows workstations, laptops, and servers, but we also have some Linux and FreeBSD systems, as well as some IoT devices. Hostname resolution of Windows machines in Windows DNS is easy; Active Directory joined workstations have a group policy set to register their hostnames in Windows DNS.

To get non-Windows systems registered in DNS, we are using some scripting to read the dhcp leases file and dhcp config file from dhcpd, then doing some filtering to determine which leases belong to non-Windows devices and dynamically register those in Windows DNS. This is being done with a powershell script. The end result being that we now have resolution by hostname for every single device provisioned by DHCP in our network (and that is ALL devices at this point. We don't do manual IP address assignment on any system at this point). The scripting based solution works very nicely, it just would've been nice if we had the option to assign an IP address via DHCP static reservation without having to assign a hostname in the static reservation. That creates a condition where, when I create static reservations, I have to remember to leave the hostname field blank for Windows machines (which will register their DNS hostnames directly with AD DNS) but specify hostnames in the reservations for non-Windows systems.

It's not really that big of a deal, it would just be more convenient to be able to write my DHCP reservations in a consistent manner for all entries rather than having one kind of entry for Windows systems and a different kind of entry for non-Windows systems.

Moved to general

@wifi-will said in Captive Portal - Change redirect from IP to a DNS name:

does that mean they would have to type the full URL?

Easy answer : when the portal user types in the 'bare' domain name of the captive portal, like

https://portal.my-network.tld

there will be a fail.

Look at the index.php file that gets loaded, it's here : /usr/local/captiveportal/index.php
The port number has to be present, as the portal is not listing on default port 443
The 'zone' parameter has to be supplied.

So, yes, this is the minimum :

https://portal.my-network.tld:8003/index.php?zone=xxxxx

@wifi-will said in Captive Portal - Change redirect from IP to a DNS name:

DNS host over ride can replace the IP address, but it wont get rid of all the information

Take your pick here.

My simple explanation :
First, the browser take the host name, and resolves it to an IP. Because the local host over ride will match the host name, this will be a quick job.
Now, the browser has the IP (of our captive portal network) and will connect to it.
When it connects, it asks for the (a) default page - file actually, index.php and add parameters to it (if present).

@wifi-will said in Captive Portal - Change redirect from IP to a DNS name:

HTTPS needs to be dies to a real domain that we would host. Such as a subdomain on our website or something?

It needs to be a doman name you rent.
Otherwise Letsencrypt can't give you a cert.

@wifi-will said in Captive Portal - Change redirect from IP to a DNS name:

But you think HTTPS may not be needed as HTTP works fine for most devices?

Forget about "http", it's dead. https is not some sort of option. In a nearby future, browser won't be able to use it anyway (without a boat load of warnings etc)

And what about this one :
A captive portal does not use WPA or WPA2 wifi encrypting. This is not really an issue because :
every mail you get and send, every web page you visit, every request an App in your Phone makes (to your bank), is TLS encrypted. There is no need to encrypt encrypted data.
True, DNS traffic will go over the Wifi in clear. So, some one might know you just visited facebook. But nothing more.

@wifi-will said in Captive Portal - Change redirect from IP to a DNS name:

If I was to setup ACME, would that achieve the desired result of the portal being reached at portal.hotelname.net?

You should use the acme pfSense as it permits you to automatize the entire process. The needed certs will get renew automatically, no maintenance needed.
Normally, I never need to 'manage' our captive portal.
I could even take a 6 month holiday, and will still work just fine.

You can also buy some where else a cert with a validity of one year, or two.
This means you have to come back after some time to put in place the new certs.
So, why bother ?
Get a domain name (a couple of $ a year). Get acquainted with what Lets-encrypt is, what "acme" does, set it up and enjoy.

@wifi-will said in Captive Portal - Change redirect from IP to a DNS name:

Or, is there a way for the client to type portal.hotelname.net and it redirects to https://portal.my-network.tld:8003/index.php?zone=cpzone1 for example?

I understand your question, as I had the same way, way back.
You will discover over time that your question fades away.
Again, all devices on planet earth use OS's that are captive portal ready.
It goes like this :

The client actiavtes the Wifi and connects to an visble SSID - like your "Your Hotel".
When it connects, many things happen, and end user don't know, don't need to know.
You are the admin,you should know what happens now.
The client device thtows out a DHCP request to obtain a network, IP, gateway and DNS.
Then, the devices throws out a initial 'http' (not https !!) request to a known URL, like http://portal.apple.com - see https://discussions.apple.com/thread/7491051
Android based devices work the same way.
Microsoft (Windows) works the same way.
Any 'Linux' based OS works the same way.

As said, the clients in our hotel are not smarter as elsewhere, and they all connect just fine without me giving any instruction.

This doesn't mean it works for everybody.
There will always be people that use devices that use anti virus stuff with strict firewall rules that do not accept any other connection as their own 'home' known network.
These guys won't be able connect anywhere, as their security was set up to enforce this behaviour. The funny part is : they don't know this themselves ...

Btw : things will get easier in the future : see https://developer.apple.com/news/?id=q78sq5rv