[Dnsmasq-discuss] REQ: Clarification
gypsy
gypsy at iswest.com
Fri Aug 26 08:56:15 BST 2005
Simon Kelley wrote:
>
> gypsy wrote:
> > Simon,
> >
> > I have read the man page but I still need assistance. Because dnsmasq
> > cannot reload the cache from a dump, this must be perfect before I stop
> > and restart dnsmasq, else I will again have Email messages backed up for
> > hours (a few deferred 4 days last time!) while the cache rebuilds.
> >
> > I need MX. In dnsmasq.conf there are 4 lines; which do I set, please?
> > mx-host
> > (What is the meaning of "mx_name[, hostname][, preference#]"? Do I need
> > to set mx-host?)
> > mx-target
> > (mx-target seems inappropriate, if I read the man page correctly.)
> > selfmx
> > (???)
> > localmx
> > (???)
> >
> > Here is the scenario:
> > eth1 EXTERNAL IP FQDN INTERNAL IP eth0
> > 66.209.101.194 yesican.chsoft.biz 192.168.1.1
> > 66.209.101.195 news.chsoft.biz 192.168.1.205
> >
> > When "news" emails to "yesican", I need for dnsmasq to return
> > 192.168.1.1 to the MX request. (? and the A request if there will be
> > one, and to return 1.1.168.192.in-addr.arpa to the PTR request if there
> > is one of those ?)
> >
> > WBTH (What Bad Thing Happens):
> > The present configuration causes this
> > Aug 24 02:05:05 YesICan dnsmasq[123]: query[MX] yesican.chsoft.biz from
> > 192.168.1.205
> > Aug 24 02:05:05 YesICan dnsmasq[123]: forwarded yesican.chsoft.biz to
> > 207.178.128.21
> > --->>>^^^ This should not be forwarded! ^^^<<<---
> > Aug 24 02:05:05 YesICan dnsmasq[123]: query[A] yesican.chsoft.biz from
> > 192.168.1.205
> > Aug 24 02:05:05 YesICan dnsmasq[123]: /etc/hosts yesican.chsoft.biz is
> > 66.209.101.194
> > Aug 24 02:05:05 YesICan dnsmasq[123]: query[PTR]
> > 195.101.209.66.in-addr.arpa from 127.0.0.1
> > Aug 24 02:05:05 YesICan dnsmasq[123]: cached 66.209.101.195 is
> > 66-209-101-195.skyriver.net
> > Aug 24 02:05:05 YesICan dnsmasq[123]: query[A]
> > 66-209-101-195.skyriver.net from 127.0.0.1
> > Aug 24 02:05:05 YesICan dnsmasq[123]: forwarded
> > 66-209-101-195.skyriver.net to 207.178.128.21
> > Aug 24 02:05:05 YesICan dnsmasq[123]: reply 66-209-101-195.skyriver.net
> > is <NXDOMAIN>-IPv4
> > Aug 24 02:05:05 YesICan dnsmasq[123]: query[A]
> > 66-209-101-195.skyriver.net.chsoft.biz from 127.0.0.1
> > Aug 24 02:05:05 YesICan dnsmasq[123]: forwarded
> > 66-209-101-195.skyriver.net.chsoft.biz to 207.178.128.21
> > Aug 24 02:05:05 YesICan dnsmasq[123]: reply
> > 66-209-101-195.skyriver.net.chsoft.biz is <NXDOMAIN>-IPv4
> >
> > More generally, any MX request from an internal machine should return
> > the internal IP of the specified computer.
> >
> > dnsmasq version 2.22 running on Slackware Linux version 10.0.
> >
> > 1) Your explanations in this mailing list are clear; please add some
> > (more) explanatory text to the man page so it too is clear. An example
> > in the config file would be a huge help as a supplement to the man page.
> > 2) Please supply an external program to reload the cache from a SIGUSR1
> > dump for those of us who are in serious need of an equivalent to
> > dnscache's SlurpCache feature. If I had this, I could take the time to
> > work out the answer to my question for myself. I realize that the load
> > on my setup exceeds the "light weight" in the description of dnsmasq,
> > but except for this single lack, dnsmasq is ideal.
>
> First, MX. You seem to believe that the result of an MX lookup is an IP
> address; this is wrong. An MX lookup returns a domain name. A mailer
> then has to do a A record lookup on that domain name to get to the IP
> address it needs to talk to.
>
> Actually an MX lookup returns a set of domain names, each of which has a
> preference. A mailer will try each of the result in turn, in reverse
> order of preference.
>
> So for example.
>
> scratchy:/usr/src/modules# dig mx thekelleys.org.uk
>
> ; <<>> DiG 9.3.1 <<>> mx thekelleys.org.uk
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8732
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 5
>
> ;; QUESTION SECTION:
> ;thekelleys.org.uk. IN MX
>
> ;; ANSWER SECTION:
> thekelleys.org.uk. 43200 IN MX 30 eyas.biff.org.uk.
> thekelleys.org.uk. 43200 IN MX 5 thekelleys.org.uk.
>
> A mailer would first attempt to deliver mail to
> someone at thekelleys.org.uk to the machine called thekelleys.org.uk but it
> will need another A record lookup to do that.
>
> scratchy:/usr/src/modules# dig thekelleys.org.uk
>
> ; <<>> DiG 9.3.1 <<>> thekelleys.org.uk
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15618
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4
>
> ;; QUESTION SECTION:
> ;thekelleys.org.uk. IN A
>
> ;; ANSWER SECTION:
> thekelleys.org.uk. 60 IN A 81.108.205.124
>
> If that fails, then the mail will go to the backup, eyas.biff.org.uk
> (after another DNS A record lookup to get the Ip address of that host.
>
> The fields in mx-host are just these: so to get the MX records above, do
>
> mx-host=thekelleys.org.uk,thekelleys.org.uk,5
> mx-host=thekelleys.org.uk,eyas.biff.org.uk,30
That's fine for mail going outside. My question is about mail inside,
between two different computers on the lan.
> > More generally, any MX request from an internal machine should return
> > the internal IP of the specified computer.
Allow me to amend that to say
> More generally, any MX request from an internal machine for a mail record for chsoft.biz should return the internal IP of the specified computer, not its external IP.
In the dump, "internal machine" is news and "specified computer" is
yesican, but that can vary. I have 5 servers, each with both an
internal and an external IP and each sends mail to various lan
destinations. Only yesican sends mail over the internet, but it also
sends mail to lan destinations.
> That's not clear,
Then please read this and the dump again. I don't know how to clarify
it further:
news.chsoft.biz asks, on the internal interface, for the MX record for
yesican:
> Aug 24 02:05:05 YesICan dnsmasq[123]: query[MX] yesican.chsoft.biz from 192.168.1.205
I want that request to be answered by dnsmasq.
Allow me to expand on that here. If the request was
query[MX] thekelleys.org.uk
then yes, it should be forwarded because my dnsmasq is not authoritative
for thekelleys.org.uk. However, it sure as heck IS authoritative for
chsoft.biz!
Thus, I think this should _not_ be forwarded, so this is A Bad Thing:
> Aug 24 02:05:05 YesICan dnsmasq[123]: forwarded yesican.chsoft.biz to 207.178.128.21
IMO dnsmasq should say "Hey, I know the answer to that!", so that
yesican's internal IP is returned, not its external IP as happens next:
> Aug 24 02:05:05 YesICan dnsmasq[123]: query[A] yesican.chsoft.biz from 192.168.1.205
> Aug 24 02:05:05 YesICan dnsmasq[123]: /etc/hosts yesican.chsoft.biz is 66.209.101.194
AFIAC, the correct response here is 192.168.1.1, not 66.209.101.194, and
it should come from dnsmasq, not from hosts. The questions are:
1) how do I accomplish that (return 192.168.1.1 to the A query)?
2) how do I avoid/prevent the forwarding of the MX query?
> but assuming you want an MX record which sends mail
> addresses to each internal machine to itself, rather than a smarthost,
IIUC, nope, that is not what I want. Please don't overlook that I
originally asked for amplification in the man page and examples in
dnsmasq.conf. What you have explained herein would go a long way if
included in 2.23RC3.
> then just
>
> selfmx
>
> will do. That returns an MX record for each internal machine, pointing
> to itself, with priority 1, so it's equivalent to doing
>
> mx-host=hostname,hostname,1
>
> for all hosts in /etc/hosts and named via DNS.
>
> Second, Slurpcache. I'm sorry, but I don't understand how that would
> help. Can you tell me?
SlurpCache was especially important for dnscache because dnscache
hammered the root servers; Another Bad Thing. RHETORICAL QUESTION:
Which is worse, hammering the root servers or hammering my upstream
servers?
When I ran dnscache, I patched in a DumpCache and SlurpCache so it did
not have to go outside in order to recreate what it had already learned
when the cache was stopped and restarted. There is a huge amount of
activity otherwise because there are so many entries in the cache and it
takes a long time (= much bandwidth, long delays, Etc.) to rebuild the
cache from the upstream servers. As I said at the top of this message,
the length of time it took dnsmasq to obtain some IPs was so excessive
that it caused a few Email messages to be deferred (by Postfix) for four
days. Count 'em.
All of those delays and requests to the upstream servers could have been
avoided just by putting back what was there before the shutdown.
Avoiding the need to ask an upstream server is what a caching name
server is for, isn't it?
In order for me to try enough times to edit a "correct" entry into
dnsmaq.conf, I would have to stop and start several times. When finally
right (or I give up trying), the cache has to be rebuilt. When
"nothing" else is going on (NNTP receives but does not send, Apache and
Postfix shut down entirely, FTP throttled but running because it must,
Etc.), rebuilding the cache takes days. The last time I shut down
dnsmasq, I rebuilt its cache by parsing the output of USR1 into a script
that pinged (ping -c1 $FQDN) each FQDN. I started that about 7:30 PM on
a Friday and it finished sometime Sunday night/Monday morning.
Perhaps there is a quicker way than ping, but I don't know what that
might be other than a SlurpCache equivalent.
I need to remove 2 upstream servers from dnsmasq.conf. That requires a
restart.
I would also like to try adding 3 new upstream servers to dnsmasq.conf.
That requires a restart. If they don't work out, removing them requires
another restart.
I've put these things off because I don't want to piss my boss off
again. He's not a Happy Camper when his outgoing messages are deferred,
and he comes to ask when he is expecting a message and it hasn't yet
arrived <cringe>.
Does that give you an idea why I so desperately want a SlurpCache
feature in dnsmasq? ;) Or rather, an external program to pump the USR1
dump back into its cache. I don't advocate bloating dnscache for this,
but neither do I understand why a supplemental program that restores the
cache does not yet exist. Perhaps it does and I just haven't found it
yet. Had I listened to Dan Bernstein, I'd never have had SlurpCache...
> Cheers,
>
> Simon.
Feel free to snip any reply or to take this off the list.
I am always pleased with the way you handle our questions. Thank you.
I wonder if you realize how rare you are? In my experience with
programmers (and I have 19 years of experience to prove it), most
programmers are a**holes and you are definitely a refreshing exception.
Regards,
gypsy
More information about the Dnsmasq-discuss
mailing list