wrong RD/RA flags cause exim4 to fail if no MX Record for a domain is set

[Sam Trenholme]

Thanks for the bug report; I will verify this fix is OK and hopefully
release new versions of MaraDNS next week sometime.

As an aside, RA serves *no* purpose in the DNS header.  There is no
good reason why clients should look at or care how this bit is set.
IMHO, Exim is broken because it cares how this bit is set.  I mostly
fixed this last fall (as you observed); however I didn't cover all of
the corner cases.

I wonder if this merits a 1.2.12.10 release.  Probably, since, among
other things, it has been months since the last MaraDNS release.

Note: If you send me a MaraDNS-related support question, I reserve the
right to post your support email to the Mara-DNS mailing list so that
the community at large can examine your issue. MaraDNS security
vulnerability reports, however, will be kept confidential.  Note that
I am aware of the July 2008 cache poison attack, and that MaraDNS is
immune, and has been immune since 2001.

- Sam

2008/8/1 Dr. Volker Jaenisch <volker.jaenisch at inqbus.de>:
> Hi Maradns-list!
>
> We use maradns on large exim mail-server-clusters and we like it.
>
> The stabe version on Debian 1.2.12.04 as well as the
> sourcecode for 1.3.11 shows the same behavior:
> MaraDNS does not return the RD and sets does not set RA Flag in case
> of a RECORD NOT FOUND case. (See attached maradns and bind output of
> such a case, below)
>
> In general the reflection of the RD/RA flags have been fixed with the
> last patches in the stable and developement branch.
> For this seldom case the existing bugfix should be extended by the
> following patch (against 1.3.11).
>
> --- MaraDNS.c~  2008-03-24 16:52:28.000000000 +0100
> +++ MaraDNS.c   2008-08-01 15:49:05.000000000 +0200
> @@ -1892,8 +1892,8 @@
>     header.qr = 1;
>     header.opcode = 0;
>     header.tc = 0; /* To do: truncation handling */
> -    header.rd = 0; /* RDBUG udpnotfound */
> -    header.ra = 0;
> +    header.rd = rd_val; /* RDBUG udpnotfound */
> +    header.ra = rd_val;
>     header.z = 0;
>     /* Code that verifies that this host does not exist in
>        any class.  If so, then we give them a rcode of NXDOMAIN_RCODE.
>
> This patch cures the exim problem. But I am pretty sure that it is not
> complete. Also there may be a conflict with
> the RDBUG udpnotfound bugfix.
>
> Background:
> If a domain has no MX entry exim decides to use the IP of the A entry.
> But exim have to be resonable sure that no other DNS error has ocurred.
> Since maradns does not return the RD and RA flags properly exim supposes
> an dns malfunction:
>
> I did send a recursive MX question and get a nonrecursive answer > the
> DNS may be broken
>
> and tries again and again to get a recursive answer. The bitter
> consequence is that emails to domains without MX records
> will completely fail on exim systems.
>
> It is no RFC violation not to set an MX record for a maildomain.
> Let's take a look at what RFC 2821 says:
> - Once the domain is identified SMTP must perform a DNS lookup and first
> attempt to locate an MX record.
> - If no MX records are found but an A record is found, it is treated as
> if it was associated with an implicit MX record with a preference of 0
> pointing to that host - also known as the "implicit MX" rule.
>
> With maradns the following happens:
>
> skylla:~/maradns-1.3.11# dig @10.1.0.8 -tmx +recurse mail.tropos.de
> ; <<>> DiG 9.3.4-P1.1 <<>> @10.1.0.8 -tmx +recurse mail.tropos.de
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24702
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;mail.tropos.de.                        IN      MX
>
> ;; AUTHORITY SECTION:
> mail.tropos.de.         85665   IN      SOA     sana.tropos.de.
> jagemann.tropos.de. 200807312 86400 3600 3600000 86400
>
> Compared to a bind DNS-server:
>
> skylla:~/maradns-1.3.11# dig @193.239.30.4 -tmx +recurse mail.tropos.de
>
> ; <<>> DiG 9.3.4-P1.1 <<>> @193.239.30.4 -tmx +recurse mail.tropos.de
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61493
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;mail.tropos.de.                        IN      MX
>
> ;; AUTHORITY SECTION:
> tropos.de.              10800   IN      SOA     sana.tropos.de.
> jagemann.tropos.de. 200807312 86400 3600 3600000 86400
>
> Best regards
>
> Volker
>
> --
> ====================================================
>   inqbus it-consulting      +49 ( 341 )  5643800
>   Dr.  Volker Jaenisch      http://www.inqbus.de
>   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
>   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
> ====================================================
>
>