Russell Nelson wrote:
> [EMAIL PROTECTED] writes:
> > BIND can return incomplete glue records in some cases, possibly many fewer
> > than the threshold of overflowing the packet. A scenario I've been testing
> > is with 2 MX hosts and 12 A records for each. The whole mess won't fit in
> > one packet. BIND then decides to not include all of the A records for the
> > 2nd MX host. Will qmail go back for those A records if it needs them? And
> > what if the glue A records sent were for the higher of the two MX hosts?
> > Will it handle that (yes, BIND decides which MX records get glue records
> > after it does order cyclic, so order fixed is apparently going to be
> > appropriate here).
>
> qmail's dns algorithms are exposed in the dns* programs. They're not
> documented, nor are they installed in /var/qmail/bin, but they're
> there in the source directory and you can play with them to see what
> results you get from various queries. In the absence of an smtproute,
> qmail uses the results returned by dnsmxip, in the order returned.
>
> Oh, interesting! ipal.net has a useless MX record at priority ten.
>
> desk:~$ src/qmail-1.03/dnsmxip ipal.net
> 206.97.151.200 0
> 206.97.151.200 10
> 206.97.151.14 20
> 206.97.151.8 20
<verbositywarning>
Yup. When you look at it as IPs only, it's certainly useless with no obvious
reason. It's actually from an older script that generated simplistic DNS zone
data using pseudonym hosts. There are 2 pseudo-hosts, mx1 and mx2. If the
destination host is one of those in the A records for mx1 or mx2, then it
comes out that way. But mx1 is just one host (for now) and the script that
generated it didn't look far enough to realize it. If mx1 were 2 hosts
then there would still be a useless 10 but one that is useable, too.
The basic principle was that for all hosts in domain.xxx then mx1.domain.xxx
would be priority 10 and mx2.domain.xxx would be priority 20. Those names
would then have their own A records. They would happen to point to the same
IP as some hosts (such as rigel.ipal.net). It gets complicated when this
is happening over a couple dozen domains. But as you see, the overlap case
looks ugly.
As I migrate to a better database I'll be rewriting those scripts. I have
yet to put thought into a better way to approach this; that will begin with
I get the new servers fully configured and loaded (sendmail-free, this time).
My initial quick thought is to allow a per-host override in the database
for the MX list. That solves the problem if I think to manually configure
it different in the database. I'd like some intelligence in the script to
do it different. Just OTTOMH, the script could build an IP list much like
dnsmxip does (but from the database, not DNS, since it's building zone data)
and detect the condition. If so, it will fall back to treating the host as
a whole domain. So for host.domain.xxx instead of using mx1.domain.xxx and
mx2.domain.xxx it will use mx1.host.domain.xxx and mx2.host.domain.xxx and
delete the redundancy (and the whole name if the IP list becomes empty).
The old script worked from a file that was generated from /etc/hosts, which
basically gave it a list of FQDNs. It took the SLD part and blindly generated
the MX records for each one. Because I need to generate new files for qmail
control, I'm going to be addressing that issue RSN. And for many other
reasons a new database has been considered, although I'm still undecided on
whether to use SQL, LDAP, or hierarchical property files. I tend to favor
the latter two, but still have some issues on interpreting LDAP.
</verbositywarning>
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
