An interesting bug. I wonder how long that's been going on with no one noticing?
How long? Since it was written. With no one noticing? Um, well, us admintypes always knew. More or less a "well DUH."
This isn't going to be fixed, at least not by FreeNAS. syslogd and some other key system daemons have always done name resolution at daemon instantiation. The resolver is a blocking function that can take an unknown amount of time, which is particularly unacceptable for something like syslogd, which is an important part of the security infrastructure.
It is unrealistic, for example, for each routed message to result in a separate DNS lookup for the target syslogd server. A syslogd server might be handling hundreds or even thousands of messages per second.
So then, do you do a lookup once a minute? Once an hour? etc. Remember that the resolver library on a UNIX system isn't a caching resolver... so you're talking about, at a minimum, IPC to a daemon, or network activity if the recurser isn't on the same box. Each lookup request has to involve other resources. And if the lookup process blocks for even a fraction of a second, you can easily start losing logging messages in a high volume environment. If it blocks for a minute because it's having trouble, that's similarly bad. And what if your DDNS target actually deregisters from the dynamic DNS environment?
The real answer is to nail down your syslogd server. Since a lot of gear that supports syslogd only supports it via IP address anyways, that's how a syslogd server is normally deployed. Your security and logging infrastructure shouldn't be randomly floating around on dynamic DNS.
Even pretending this works the way you want, trying to use dynamic DNS is basically guaranteeing that you will be missing out on messages now and then. Anytime the IP changes, all the messages from the time of the change to the time the TTL expires WILL BE LOST. You cannot even rely on TTL working the way you'd like (such as, let's say, 5 seconds) because a service provider may actually override TTL and set it to something more reasonable, like an hour.
Something that's a little bit more complex might be able to offer some sort of compromise. I believe that rsyslog provides for reliable delivery options but I don't know what it does about hostname lookups.