pfSense

Thanks but we cannot migrate to the new version of DNSMASQ until someone writes a replacement for the isc log scanning option that they removed in haste.

I see. Would'nt it be possible to substitude isc dhcpd entirely with dnsmasq?

No. We would loose too many features such as failover-dhcp (CARP).

I did some more research on this matter.

• There are reasons not to use CNAME records:
  http://cr.yp.to/djbdns/notes.html#aliases
• I found that there is no problem in having multiple records with the same IP address in /etc/hosts. The pfSense webinterface does not prevent me from entering multiple names (aka A-record) for a single IP address and dnsmasq happily serves them all. For some reason I foolishly thought that this might be a problem...

  pfSense:~#  cat /etc/hosts
  127.0.0.1    localhost localhost.local
  192.168.82.22    pfSense.local pfSense
  192.168.82.22    somehost.local somehost
  192.168.82.22    someotherhost.local someotherhost

So, please close this ticket (wontfix) and forget about it.

I would like to request that this ticket be reopened and the feature reconsidered. Regardless of what DJB may think, there are good reasons to use CNAMEs (or some other form of hostname aliasing).

In our network we have a single intranet server, intranet01. It gets its address from DHCP; in fact, everything on the LAN side of the network gets its address from DHCP, be it static or dynamic. Services hosted by intranet01 have their own hostnames that are accessed via apache named virtual hosting, such as cacti, nagios, svn, and so on. Presently the only way to create these named aliases in pfsense is by IP address, which means the address must be static, and moving the host to a new address or subnet is tedious and error-prone.

Ideally the IP address for a server should only be entered once or never, and aliases used everywhere else, so the address can be changed quickly, easily, and safely.

This problem was demonstrated (somewhat catastrophically) today when we moved DHCP into a different network range, and were left with many invalid and non-working aliases throughout the system that had been created referencing the IP address of a DHCP client; in the aftermath we found that we could not fix these by changing the address to the server name.

Cancel that, entering new ticket for this in 2.x.