No subject

is crucial that
the DNS is absolute reliable. So every evidence that DNS goes wrong is
needed to prevent
a desaster.
Imagin a DNS server that is misconfigured the following way: No
recursive queries for MX and therefore answer  "Answer: 0" to every MX
DNS query but  "Answer:1" for A records. In the best case no email can
be delivered. In worst case every email is delivered a wrong way (send
to the A entry). So I understand the developers of exim that the try to
do some sanity checks
to avoid such a desaster.

On the other hand I do not like such workarounds as exim have. They
produce systems with nearly unpreductable behavior.
The best efford should be to define and implement better standards.

And you are right that this is a corner case. I will bring this point to
the exim mailing list. Maybe they can omit the
flag checking. 
> Don't get me started on RFC1912 section 2.2, where the serial number
> is supposed to be in a format that is only meaningful if you edit the
> SOA serial by hand.
>   
Oh No! You are on the right track to implement what is truly used and
what is resonable.
> Yes, this would be a useful bit in the header if it was, say RP
> (recursion performed) telling you that the query in question was one
> processed recursively, and not coming from the local DNS server.
>   
I agree strongly.
> I also feel RD is handled wrong in BIND.  BIND's handling of RD has
> privacy implications: BIND simply doesn't recurse to process a given
> query, but if the query is already in the cache, BIND will give you
> the query from the cache.
>
> In MaraDNS, if RD is cleared, MaraDNS will not ever give you any
> information from the cache, but will only answer authoritative
> queries.
>   
The behavior of maradns seems to me the definitive better choice.
I like the security aspects of maradns much. After the last BIND
incident our team
has put feet on the desks while the other admins get into panic to fix
their bind systems.
These are the moments when you know for sure that you have choosen the
right DNS server.

Another of this moments was that I was able to track down this flag
issue within some hours.
Within the Bind sources I suppose I have been lost.

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
====================================================