pfSense

Hosts file would work great I suspect, interface mock looks good too. Thanks!

Was that patched against 2.0.1 or 2.1? It doesn't appear to apply to 2.1.

Actually the patch is against the master branch on github. The last commit i see in my git log is https://github.com/bsdperimeter/pfsense/commit/a52706d5d8bbaff13e22c78990648f2e4e17b1c7 which is also the current head over here (a52706d5).

There is neither a tag nor a branch relating to version 2.1. Where exactly can I find that one?

mater is 2.1 (for now)

Interesting, I just did another gitsync to bring my VM up to the most current code and it still doesn't want to apply, but I re-fetched the patch and told it to ignore whitespace and now it likes it.

If you have that patch in a fork of the pfsense repo on github, you could submit a pull request once people have tested it out.

Done. https://github.com/znerol/pfsense Branch: feature/master/dns-host-alias

Whitespace is handled somewhat inconsistently throughout the pfsense codebase. I tried hard to mimic the style of existing code but apparently failed in services_dnsmasq_edit.php. I've pushed another one that should blend in better with the existing code.

Whitespace could use some cleanup, but usually patches will work so long as they are clean. It may have been that the newlines on your patch were DOS (I didn't check) but a patch on the box expects UNIX newlines.

The "System Patches" package I just added yesterday pulls them in as-is, so I just had to check the box to ignore whitespace and off it went. It makes testing things like this really easy from supplied patches. You can just paste in the download URL for the patch from redmine or a git commit url, tell it to fetch, then apply, no muss, no fuss.

The code seems to work fine for me. I added a host, gave it an alias, and it was populated in /etc/hosts as expected. Looks good to me. Submit a pull request and I'll approve it.

https://github.com/bsdperimeter/pfsense/pull/99

This doesn't address the original user's request. I have the same request that he does. I want a CNAME to work for DHCP entries.

The first hint that this wasn't going to work was when the UI said the IP was a required field. For a CNAME (or plain old /etc/hosts alias) there is no IP. It's an alias to another hostname, not an IP.

I went to hack the /etc/hosts PHP in pfSense to fix this, but what I found was that the lines aren't being generated by the PHP. The lines that are incorrect are being apparently written by a binary file called /usr/local/sbin/dhcpleases.

Instead of:
10.10.0.1 foo.internal foo # dynamic entry from dhcpd.leases

it needs to write a line like:
10.10.0.1 foo.internal foo thing-that-points-to-foo.internal thing-that-points-to-foo another.internal another # dynamic entry from dhcpd.leases

... assuming that you had two alias entries called "thing-that-points-to-foo" and "another", both with an alias of "foo"

Sorry for the delay, but the more I think about it yes, Univa IT is correct. This is a partial solution, but it does still require me to enter an IP address to begin with, which doesn't help if I'm creating an alias for a hostname outside the purview of pfsense; e.g. an internal CNAME to an external host.

I think the hosts file aliasing as presented is useful in its own right, but it's not the same as supporting CNAMEs, and not quite as flexible.

CNAME-support in dnsmasq is somewhat limited. If I'm not mistaken there is no way to specify a CNAME record pointing to a host whose IP address is not managed by / not known to dnsmasq.

The following excerpts from the dnsmasq documentation are relevant:

--cname=<cname>,<target>
Return a CNAME record which indicates that <cname> is really <target>. There are significant limitations on the target; it must be a DNS name which is known to dnsmasq from /etc/hosts (or additional hosts files) or from DHCP. If the target does not satisfy this criteria, the whole cname is ignored. The cname must be unique, but it is permissable to have more than one cname pointing to the same target.

That means that we have to specify each alias entry as a separate command line flag. Additionally the target must be managed by dnsmasq. And then later on:

Addresses in /etc/hosts will "shadow" different addresses for the same names in the upstream DNS, so "mycompany.com 1.2.3.4" in /etc/hosts will ensure that queries for "mycompany.com" always return 1.2.3.4 even if queries in the upstream DNS would otherwise return a different address. There is one exception to this: if the upstream DNS contains a CNAME which points to a shadowed name, then looking up the CNAME through dnsmasq will result in the unshadowed address associated with the target of the CNAME. To work around this, add the CNAME to /etc/hosts so that the CNAME is shadowed too.

IMHO people which need a really flexible DNS setup should probably use a more sophisticated software than dnsmasq.

Forgot the manpage link: http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

Are you saying that dnsmasq is the product that ships the /usr/local/sbin/dhcpleases file that generates the dhcpd.leases per my comment above?

(FYI, I'm not clear on what advantage at all their is to the current patch, since it fails to address the original issue. If this can't be fixed, it may make sense to revert the patch from the repository.)

There is no need to revert the change. Just because it doesn't address this issue does not mean it's useless. It's not exactly what I want, but it is "enough" to prevent the problem that caused me to open this ticket from occurring again.

If anything, I would suggest a patch to the dnsmasq people to allow CNAMEs to point to targets unknown to dnsmasq -- this seems like an arbitrary and pointless limitation -- and then proceed with adding true CNAME support. Once it's in place, then the proposed solution could potentially be backed out, as this would cover both cases.

FWIW, the tomato project uses dnsmasq with DNS forwarder-like functionality and allows mapping multiple hostnames to single IP addresses, optionally as part of a fixed DHCP lease by MAC address. This is exactly what I would like (of course, as I'm coming from a Tomato-product), but I believe is what's being asked here. I don't know if it has anything to do with /etc/hosts created from dhcpleases or not, as I have not delved into the dnsmasq code. I, too, would like to see this feature, but did I read somewhere that the pfsense dnsmasq could not support aliases/CNAMEs because it would interfere with the DHCP failover? Is that correct and the source of the "missing" feature? What if a user has no intention of using DHCP failover--it seems like the dnsmasq CNAME support could be used if it didn't conflict with something else the user was attempting. Just a thought from another camp. (And, yes, I'm a relative n00b trying to migrate from tomato to pfsense.)