Is there anything preventing this from happening? Is it a possible scenario?

ns1.edgecastdns.net. 172,800 IN (Internet) A (IPV4 Host Address) 192.16.16.5

ns1.edgecastdns.net. 172,800 IN (Internet) AAAA (IPV6 Host Address) 2606:2800:3::5

These two records have the same name so I think it could be serving the wrong record.
['https://serverfault.com/questions/742224', 'https://serverfault.com', 'https://serverfault.com/users/326614/']
It's always possible that the DNS server could be buggy but it seems unlikely. If you query for a record of a particular type, that's the type you should get.

However, it is common for DNS servers to answer questions that haven't been asked as an optimization. In this case, it does appear to supply AAAA records as 'additional answers'. That's perfectly fine. 

```
QUESTIONS:
    ns1.edgecastdns.net, type = A, class = IN
ANSWERS:
->  ns1.edgecastdns.net
    internet address = 192.16.16.5
    ttl = 3582
...
ADDITIONAL RECORDS:
...
->  ns1.edgecastdns.net
    has AAAA address 2606:2800:3::5
    ttl = 63143

```
Just adding a little to the other answers.

The others answers are correct regarding what you get in the answer section of your packet. If your client asks for an `A` record in the query, the answer section will only return an `A` record or a `CNAME` which may or may not point to a different record containing an `A` value. This means that it's never possible for the other to *accidentally* be used.

*Purposefully* is a different story entirely. Let's take a look at [RFC4213](https://www.rfc-editor.org/rfc/rfc4213#section-2.2):

> 
> DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of
> handling both AAAA and A records. However, when a query locates an
> AAAA record holding an IPv6 address, and an A record holding an
> IPv4 address, the resolver library MAY order the results returned
> to the application in order to influence the version of IP packets
> used to communicate with that specific node -- IPv6 first, or IPv4
> first.
> 
> 
> The applications SHOULD be able to specify whether they want IPv4,
> IPv6, or both records [RFC3493](https://www.rfc-editor.org/rfc/rfc3596).
> That defines which address families the resolver looks up. If
> there is not an application choice, or if the application has
> requested both, the resolver library MUST NOT filter out any
> records.
> 
> 
> Since most applications try the addresses in the order they are  
> 
> returned by the resolver, this can affect the IP version "preference"
> of applications.
> 
> 
> The actual ordering mechanisms are out of scope of this memo.  
> 
> Address selection is described at more length in
> [RFC3484](https://www.rfc-editor.org/rfc/rfc3484).
> 
> 
> 

So to break it down:

* An application can ask the resolver library explicitly for an IPv4 or IPv6 based DNS lookup. Many applications don't.
* If the system is dual-stack (IPv4 and IPv6), the default is to make no assumption and provide all possible answers. This means explicit lookups for both the `A` and `AAAA` variants of the requested name.
* The ordering of the combined IPv4+IPv6 result is a complicated topic (see the linked RFC3484).

The IPv6 address will not be used unless your device is IPv6 enabled. If you're using both, then the operating system will make an educated guess about how it wants to order the returned answers (assuming that the application will try to use the first value returned), and then the application will do whatever it wants with the answers in the order they were returned.

Complicated? Yes. The long story short is that your OS+application *may* prefer the `AAAA` record that exists, but it will not be an "accident" if that happens, and the remote server (assuming standards compliance) will *never* return an `AAAA` response when an `A` record is requested.