Not respecting DNS TTL of syslog server

Status
Not open for further replies.

sky67

Cadet
Joined
Dec 25, 2014
Messages
8
Hello,

FreeNAS is not respecting TTL records of DNS records of configured external syslog server and apparently indefinitely using IP address resolved on start. Thus if you define syslog server by domain name and IP address is changed later, it sends log entries to old address.

It needs to be fixed to be usable this way for example with syslog server on DDNS. (Not mentioning that now it is leaking data to old IP used potentially by other user...)

Thanks.
 

SweetAndLow

Sweet'NASty
Joined
Nov 6, 2013
Messages
6,421
File a bug at bugs.FreeNAS.org
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,194
After you file the bug (I'd consider this one an important one), please post the issue number here, for future reference.
 

DrKK

FreeNAS Generalissimo
Joined
Oct 15, 2013
Messages
3,630
An interesting bug. I wonder how long that's been going on with no one noticing?
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
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.
 

DrKK

FreeNAS Generalissimo
Joined
Oct 15, 2013
Messages
3,630
Thanks for the information. An interesting quandary.

So, of course, this is now totally obvious now that you've said it, and the three ways that came to mind to address the issue (I am sure as you already know) had obvious pitfalls that made it not worth doing.

Yeah, so, OP, I think the correct thing to do is to nail down the syslog server!
 
Status
Not open for further replies.
Top