Meet the Gang   1   2   3   4   5   6   7   8   9

Postfix name resolution fails, dig doesn't

From Faber Fedor

Answered By Ben Okopnik, Dan Wilder, Yann Vernier, Jay R. Ashworth, Heather Stern

Hey Gang! You probably haven't noticed, but I've been a bit quiet the past few days. It's certainly not by choice, however. I was recently switched over from @Home to the lovely Comcast network. After a few birthing pains, everthing seemed to be going well. However, I've sent out a few emails, including to the Gang, and I've not seen them show up.

Looking into /var/log/maillog, I see, as an example, the following:

Mar  7 22:52:25 uranus postfix/smtp[12586]: 0A9F2FE16:
to=<tag@lists.linuxgazette.net>, relay=none, delay=28121, status=deferred
(Name service error for ssc.com (Host not found, try again) while looking up
the MX record.)

and I see this for every email I've tried to send for the last few days.

So I check my ability to do name resolution. I do a `dig ssc.com mx` and I get the correct response. dig, ping, nslookup works for every email address I've sent to in the pat few days, but no emails are sent because of "Host not found while looking up MX record".

Any ideas where to look next?

===== Sincerely, Faber Fedor

[Den] Maybe postfix has managed to latch in your old nameserver information. You might try the command:

postfix reload

[Yann] Quite probable. Postfix also has a tendency to run as much as possible in a chroot jail; to update the contents of that, you probably have to run the /etc/postfix/chroot-setup-LINUX2 script. This had me stumped for a while after changing /etc/localtime but still getting american timestamps in the mail.

[Heather] Err, the Postfix FAQ has a point here and there of saying "oh, you want to copy /etc/resolv.conf and /etc/services.switch down into the jail"

Which would likely be true whether there is a script to help it do the right thing or not.

[Ben] My familiarity with Postfix is no more than skin-deep, but if it follows the Exim way of doing things (i.e., emulating Sendmail options), you might be able to try some of the following:

sendmail -d11 -bt	# Address testing mode
sendmail -d11 -bv	# Address testing mode, skips "no_verify" routers

A debug level of 11 or above turns on DNS debugging (at least in Exim.) Here's hoping that all this stuff is at least close... you might want to read the Postfix manpage; if it's not the same options, they should at least implement similar functionality.

[Dan] Sorry Ben, no direct debugging. Use syslog. Postfix isn't a monolithic program, but a cluster of cooperating daemons, with no protocol for centralizing debugging info and having one of them dump to standard out. Rather than reinvent the wheel, Wietse Venema has Postfix consolidate its log streams via syslog.

Put it into verbose mode then tail -f whatever syslog puts the various mail.* syslog streams into.

  postfix -v reload
  tail -f whatever_log_file

and in another window

  postfix flush

to make it retry all pending spool entries and log what it sees happen.

All nameservers in your /etc/resolv.conf, or the nameservers assigned by DHCP (see logs) are reachable, I presume.

In a manner of speaking, yes. postfix uses /var/spool/postfix/etc/resolv.conf for name resolution. I assume that has to do with the chroot jail that Yann was refering to (although I don't have a script in /etc/postfix that corrects the problem).

I didn't see the message about /var/spool/postfix/etc/resolv.conf not being the same as /etc/resolv.conf since that only shows up when you start/stop the postfix (NOT when you reload, btw).

I think I'll go and find out why /var/spool/postfix/etc/resolv.conf isn't (shouldn't?) be a symlink to /etc/resolv.conf.

Either way, all better now!

-- Regards, Faber

[Ben] Erm, 'cause it's a chroot jail (best as I can tell from your description.) Assuming that '/var/spool/postfix' is your jail's '/', "postfix" won't be able to see anything above that level once it's chrooted.

My knowledge of chroot jails is limited - I keep promising myself to build a few of the damn things and experiment, as soon as I have the time (yah, shuuure...) - but it only makes sense. A link _inside the jail to '/etc/resolv.conf' is going to point at the _inside version of '/etc/resolv.conf' (a.k.a., "/var/spool/postfix/etc/resolv.conf" when seen from the outside.)

By my understanding of setting up ftp chroot jails, you can have symlinks from inside the jail to the outside. This is A Bad Thing, of course, because the entire purpose of a chroot jail is to keep the user in a specific directory.

Now, I understand that symlinking libraries is a securoty breach, but I don't see how symlinking a text file is a security breach. Can anyone explain how an exploit like that would work?

[Jay] Nope. Unless there's a bug.

You can have hard links, though, but only between files, obviously.

You can symlink into a chroot, but not out of it.

Or, more properly: you can make a symlink that looks like it points to an external file, but when it's interpreted by a program inside the chroot environment, it probably won't point anywhere useful.

[Heather] If you're wondering why it wasn't just automagically set up as a hard link, it's not the way of distro's package folk to assume they have any idea how your hardware is laid out, and hardlinks only work on the same filesystem (for ext2/3 ... for other fs' you may not have the ability at all).

Besides, I don't think my postfix is chrooted; there's only one library in /etc/var/postfix/lib and postfix has got to need access to more than one library to function.

[Dan] Depends on how it was set up. The postfix source has a file called INSTALL which discusses the pros and cons of chroot in some detail, and gives procedures to establish it. Default (as of some time back) was not to chroot.

[Heather] Postfix comes in parts, some are jailed and some not; you have to look at /etc/postfix/master.cf (a table describing features Postfix should apply to its children) to be certain. And even then it's only for sure if you recently reloaded postfix It doesn't lurk on the file watching for it to change.

This page edited and maintained by the Editors of Linux Gazette Copyright © 2002
Published in issue 77 of Linux Gazette April 2002

HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

Meet the Gang   1   2   3   4   5   6   7   8   9