Once a CNAME exists for a name, no record of any other type may exist for that same name (it's an override for all types).

But for a query like this, a server is allowed to return both a CNAME and its relevant target(s) ... as long as they are within-bailiwick. It can go right into the answer section, e.g.;

  % dig example.allcosts.net @ns-22.awsdns-02.com.            
  ...
  ;; ANSWER SECTION:
  example.allcosts.net. 300     IN      CNAME   at.allcosts.net.
  at.allcosts.net.      3613    IN      A       85.91.5.16

this is permitted because the original type of the query was "A", so we can include it as an answer, and it will avoid a round-trip on behalf of the recursor. That's all regular RFC1035 behaviour.

It's more common to use the additional section to include details about the target(s) of MX, SRV and NS records. That's more of a "I know you asked for an MX record, but you're going to need this A / AAAA record too pretty soon, so here it is in the additional section" kind-of thing. The additional sections in the responses to the following queries should be illustrative;

  dig NS  ns_example.allcosts.net @ns-22.awsdns-02.com
  dig MX  mx_example.allcosts.net @ns-22.awsdns-02.com
  dig SRV srv_example.allcosts.net @ns-22.awsdns-02.com

Something I forgot to mention; Being that DNS is the chaotically documented protocol that it is, I'm glad they launched early with a minimally viable product. It's the best way to get feedback like this for free! I think the real scope for real-world error is something like 1 in 100 users experiencing a problem as-is. Most resolvers are hyper tolerant of any amount of DNS crud, because they've been beaten on so much by poor implementations over the years. But the 1% of the time it breaks will cause you hours of pain in debugging.

In fact, returning both the CNAME and the A in the initial response is required. Returning just the CNAME and setting NOERROR tells a recursor 'the target name exists but I do not have an A record for it'. Luckily, all recursors I am aware of are stubborn and will then ask for the A anyway.

This is a good example of where things get tricky in DNS. A resolver could never really infer non-existence of the A record from mere non-presence in an answer like that.

Although RFC1034 outlines that a server typically would do that, it also says that it shouldn't include data that it's not authoritative for.

So a conflict arises when you CNAME to a sub-delegated child zone. E.g.

  foo.example.com IN CNAME baz.example.com

That response may come from a server that's authoritative for example.com - and so "baz.example.com" is technically in-bailiwick from the point of view of a resolver who has made only this query.

However baz.example.com may itself be delegated to other nameservers, and so is "really" out of bailiwick. But the response won't signal this to resolvers at this stage (though in theory could via the additional section).

The simplest reason why resolvers ignore it though is that there's no SOA in the response from which to derive the negative caching time - so it wouldn't know how long to cache that non-existence - and almost all resolvers are caches.

Even if it is required, some authoritative DNS server implementations don't, so far I have found BIND that came with FreeBSD 8.0 doesn't, nor does tinydns.

So recursors would have to account for possibly broken implementations and try the query anyway.

Ah, here is where implementation becomes important... not all of the authoritative DNS servers I have tested actually have this behaviour. So far I have found that BIND and tinydns don't send the A record even-though it is in bailiwick for the CNAME.