AA record missing = mails rejected

[Kevin Darcy]

Quadri, Jay wrote:

> I have a  problem, an ISP (demon) will not receive mails from my mail relay
> because apparently, my AA record flag is not set in my name server.

Ahem! That's the AA *flag* or *bit*, not an "AA record" (as you describe in the
Subject: line). We already have A records, AAAA records and A6 records; please
don't confuse matters further.

> When ever I query any of my host  using dig,  my name server header shows
> this:
>  dig @neptune.cwplc.com. www.cwplc.com <http://www.cwplc.com> .
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> ;; QUERY SECTION:
> ;;      www.cwplc.com <http://www.cwplc.com> , type = A, class = IN
>

Whoa! What's with all of the "http://" stuff? Was that part of the query you
actually made? If so, then I'm not surprised that the answer came back
non-authoritative. You should just be querying "www.cwplc.com". When I do that
against neptune.cwplc.com or orion.cwplc.com, the AA bit is set in the
responses.

> AS you can see the flags reads: flags: qr rd ra;
> It should be:   flags: qr aa rd ra;
>
> I have re-checked my zone files and I can't see anything wrong with it,
> Could you please help?

If their mail server software actually requires the AA bit, then it can no
longer just use the standard system resolver mechanisms: *it* has to do the
hard work of contacting authoritative servers *directly*, which may actually be
impossible if the mail server is forwarding through a firewall. Frankly,
I think it's a stupid requirement. I don't think the "AA" bit was really
intended to be a security mechanism. After all, why trust some random
nameserver on the Internet more than your own local nameserver, just because it
answers "authoritatively" for a particular domain? The only argument I can
imagine for this is that non-authoritative answers usually come from
nameservers that are "farther away" from the original source of the data (i.e.
the master) and therefore there is more chance for tampering or spoofing
somewhere along the line. But that's a weak argument at best: even master/slave
replication involves an extra "step" -- often a fairly insecure one -- and
sometimes even delegated servers are slaves 2 or more steps away from the
master. So the AA flag is hardly a reliable gauge of "distance" and, in fact,
by making the resolver issue more queries over the Internet to resolve the
name, you *increase* the chance that maybe one of the responses is spoofed,
moreover, the spoofing is likely to be less traceable since
application-embedded resolvers are less likely than full-blown nameservers to
keep track of where they get their answers from.

My suspicion is that either the AA bit is unrelated to the mail problem at all
-- I heard a similar line of reasoning from one of our anti-virus gateway
vendors until I blew their theory out of the water -- or the product simply
isn't smart enough to track down the authoritative servers. In either case,
it's not the fault of your DNS setup.


- Kevin