0

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.

3
  • What is the problem you are having? Dec 10, 2015 at 17:50
  • I am querying a webpage using IPV4 and experiencing intermittent DNS failures. The traceroute/ping for this webpage during these failures show blank so I am unable to determine whether I was sent an IPV6 record instead. Dec 10, 2015 at 17:55
  • 4
    You were not sent an IPv6 record "instead". If you are having a DNS failure, then that bears investigating. But it sounds like you are having more general Internet connectivity issues. Dec 10, 2015 at 17:57

3 Answers 3

5

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
2
  • Since the tidbit regarding the additional section is creating a bit of contention/confusion (see below), it's worth mentioning that dual-stack DNS clients don't rely on the additional section in this context. They shotgun requests for both A and AAAA and use the explicit answers that come back.
    – Andrew B
    Dec 11, 2015 at 16:10
  • Ask for something that isn't a nameserver so you don't automatically get the extra glue. (yes, my default go-to dns query is to a cname.)
    – Ricky
    Dec 11, 2015 at 23:00
0

In a word: NO

When you ask for an "A" record (IPv4), you will get an "A" answer or nothing. Likewise, when you ask for a "AAAA" record (IPv6), you will get a "AAAA" answer or nothing.

(IPv4 and IPv6 are different protocols. Just because they share the letters EYE and PEE, doesn't mean they are even remotely compatible.)

Ask for an "A"

~/[05:35 PM]:host -d -v -t a www.yahoo.com
Trying "www.yahoo.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50970
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.yahoo.com.                 IN      A

;; ANSWER SECTION:
www.yahoo.com.          240     IN      CNAME   fd-fp3.wg1.b.yahoo.com.
fd-fp3.wg1.b.yahoo.com. 30      IN      A       98.138.252.30
fd-fp3.wg1.b.yahoo.com. 30      IN      A       98.138.253.109

;; AUTHORITY SECTION:
wg1.b.yahoo.com.        55959   IN      NS      yf4.a1.b.yahoo.net.
wg1.b.yahoo.com.        55959   IN      NS      yf3.a1.b.yahoo.net.
wg1.b.yahoo.com.        55959   IN      NS      yf2.yahoo.com.
wg1.b.yahoo.com.        55959   IN      NS      yf1.yahoo.com.

;; ADDITIONAL SECTION:
yf1.yahoo.com.          56036   IN      A       68.142.254.15
yf2.yahoo.com.          56036   IN      A       68.180.130.15
yf3.a1.b.yahoo.net.     55420   IN      A       68.180.130.15
yf4.a1.b.yahoo.net.     55420   IN      A       68.180.130.15

You get an "A". (well, CNAME and it's "A"'s)

Ask for a "AAAA"

~/[05:35 PM]:host -d -v -t aaaa www.yahoo.com
Trying "www.yahoo.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7501
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yahoo.com.                 IN      AAAA

;; ANSWER SECTION:
www.yahoo.com.          205     IN      CNAME   fd-fp3.wg1.b.yahoo.com.
fd-fp3.wg1.b.yahoo.com. 49      IN      AAAA    2001:4998:44:204::a7

You get a "AAAA".

Ask for "any"

~/[05:35 PM]:host -d -v -t any fd-fp3.wg1.b.yahoo.com
Trying "fd-fp3.wg1.b.yahoo.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17586
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;fd-fp3.wg1.b.yahoo.com.                IN      ANY

;; ANSWER SECTION:
fd-fp3.wg1.b.yahoo.com. 52      IN      A       98.138.253.109
fd-fp3.wg1.b.yahoo.com. 52      IN      A       98.138.252.30
fd-fp3.wg1.b.yahoo.com. 52      IN      AAAA    2001:4998:44:204::a7

(If I asked for www, I'd get only the lone CNAME.)

And if you want to see a "loaded answer"...

[root:pts/3{2}]debian1:~/[06:00 PM]:host -d -v -t any gmail.com 8.8.8.8
Trying "gmail.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55161
;; flags: qr rd ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com.                     IN      ANY

;; ANSWER SECTION:
gmail.com.              299     IN      A       64.233.185.19
gmail.com.              299     IN      A       64.233.185.18
gmail.com.              299     IN      A       64.233.185.83
gmail.com.              299     IN      A       64.233.185.17
gmail.com.              299     IN      AAAA    2607:f8b0:4002:c09::12
gmail.com.              3599    IN      MX      30 alt3.gmail-smtp-in.l.google.com.
gmail.com.              21599   IN      NS      ns4.google.com.
gmail.com.              21599   IN      SOA     ns1.google.com. dns-admin.google.com. 2015031901 21600 3600 1209600 300
gmail.com.              3599    IN      MX      10 alt1.gmail-smtp-in.l.google.com.
gmail.com.              3599    IN      MX      20 alt2.gmail-smtp-in.l.google.com.
gmail.com.              21599   IN      NS      ns3.google.com.
gmail.com.              3599    IN      MX      5 gmail-smtp-in.l.google.com.
gmail.com.              21599   IN      NS      ns2.google.com.
gmail.com.              3599    IN      MX      40 alt4.gmail-smtp-in.l.google.com.
gmail.com.              299     IN      TXT     "v=spf1 redirect=_spf.google.com"
gmail.com.              21599   IN      NS      ns1.google.com.
6
  • As pointed out by @richardb, you can get additional records, so asking for an A would return an A with potentially AAAA as an optional extra. Dec 10, 2015 at 22:20
  • Learn how DNS works. Glue and hints ("additional data") don't matter. When an application asks for an "A", that's what it's going to look for in the answer ("answer section"). If your resolver answers with a "AAAA", it's broken. If you asked for "any", the the answer RRs can literally be any available data. When you ask for a specific resource, you get only that RR in the answer.
    – Ricky
    Dec 11, 2015 at 1:16
  • I run DNS servers, and have done so for years Dec 11, 2015 at 8:19
  • 1
    @roaima You're both right, if we want to be pedantic, which is why it's not worth a downvote in my opinion. As far as the answer section goes, this answer is correct unless we're going to get into CNAME+A chaining. Yes, the additional section may also contain a AAAA record when querying a recursive server, but is a resolver client actually going to consume that within the context of this question? No. Dual stack resolvers send two queries without waiting for the first answer to come back, and the result of the explicit query for AAAA is what gets used. Let's all play nice, folks.
    – Andrew B
    Dec 11, 2015 at 16:04
  • @AndrewB downvote retracted. I appreciate persuasive arguments Dec 11, 2015 at 22:51
0

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:

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

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .