Solved

some DNS servers will answer with a CNAME when asked for an A/AAAA record regardless of the type of the record assocated with the CNAME's target. is this the correct behavior

Posted on 2015-02-02
13
338 Views
Last Modified: 2015-02-03
basically everything is in the title but let's make it clear with an example

please assume the provided example domains to be fqdns as short vs long names are besides the point

dns contains the following
<dns entries>
red IN CNAME blue
blue in A 1.2.3.4
</dns>

asking for "red in A" produces both the CNAME record for red and A record for blue which is expected

asking for "red in AAAA" produces the CNAME record only which is not associated with any AAAA record

i would expect "red in AAAA" to produce an NXDOMAIN rather than the described behavior

i'm unsure about the correct behaviour : anybody knows how DNS servers are expected to behave ? pointers to the relevant RFC are more than welcome

thanks for your help

skull
0
Comment
Question by:skullnobrains
  • 5
  • 5
  • 2
  • +1
13 Comments
 
LVL 57

Expert Comment

by:giltjr
Comment Utility
You have to realize when you do a lookup for a host name that is a CNAME there are two lookups that are independent of each other.  In this case the lookup for "red" and then a separate  lookup for "blue".

So the first lookup is a A/AAAA for  red, in both cases I should get back that "red" points to the host name "blue."

In both cases now a separate lookup is going to be done.  An A and an AAAA for the host name blue.

For the A I would expect to get back the IPV4 address for blue.

For the AAAA I would expect to get "nothing" or no such host, back since there is no AAAA record for blue.
0
 
LVL 70

Accepted Solution

by:
Chris Dent earned 500 total points
Comment Utility
It's correct and expected behaviour which is discussed in RFC1034 (https://www.ietf.org/rfc/rfc1034.txt) 3.6.2:

CNAME RRs cause special action in DNS software.  When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class.  If so, the name server includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record.  The one exception to
this rule is that queries which match the CNAME type are not restarted.


Cheers,

Chris
0
 
LVL 35

Expert Comment

by:Mahesh
Comment Utility
If you have Alias (CNAME) pointing to Host(A) \ AAAA record, it will resolve both ALIAS and its associated FQDN (A \ AAAA) as nslookup output for ALIAS query

However if you run set type =AAAA in nslookup prompt, it will resolve only IPV6 (AAAA) addresses. Now If your ALIAS pointing to IPV4 (A) record, output won't show you Host(A) record because you told nslookup to only resolve IPV6 addresses

The same case is true when you run set type=A, in this case if your ALIAS pointing to Host(AAAA) record, it won't resolve that.

If you create blank ALAS, it won't resolve any host A \ AAAA records
0
 
LVL 35

Expert Comment

by:Mahesh
Comment Utility
Forget to mention that if you already have Host(A) record for some name (Ex:web1), you cannot create ALIAS named web1 and vice versa
If you trying to do so, DNS will gives you error

As a fact when you enter web1 for name resolution query dns will provide you whichever is available (either host A\AAAA or ALIAS), this is by default because for every name there is either Host A \ AAAA or ALIAS and not both
0
 
LVL 26

Author Comment

by:skullnobrains
Comment Utility
@giltjr

You have to realize when you do a lookup for a host name that is a CNAME there are two lookups that are independent of each other.  In this case the lookup for "red" and then a separate  lookup for "blue".

when you query for the CNAME, you only get the CNAME and you're expected to perform a second lookup if you need the address.

when you query for the A record and there is a CNAME (but no A), the server is supposed to perform the resolution of the target of the CNAME for you. afaik, authoritative servers that host zones with cnames outside of their own scope and cannot do regular resolution break the RFC.

here is an example performed on mail.google.com showing both information returned in the same DNS packet.

10:37:04.683268 IP localhost.48390 > localhost.domain: 19012+ A? mail.google.com. (33)
E..=.k..@..B...........5.).<JD...........mail.google.com.....
10:37:04.685892 IP localhost.domain > localhost.48390: 19012 3/4/4 CNAME googlemail.l.google.com., A 173.194.40.149, A 173.194.40.150 (228)
0
 
LVL 70

Expert Comment

by:Chris Dent
Comment Utility
I suppose the problem here is that to adhere to RFC 1034 the name server must follow the CNAME record and restart name processing there.

There is a valid resource and a valid response for the original question (the request for a resource of arbitrary RRType where a CNAME exists), as such NXDOMAIN is not a valid response.

That the additional processing fails to return a useful response (no AAAA exists in the RR-Set) isn't necessarily a problem for the resolver. It will return the best information it can (the CNAME alone).

CNAMEs pointing to other CNAMEs suffer from the same processing break. There's only so much the resolver can do.

The constraints on alias processing is why CNAME records cannot co-exist with any other type, and why you cannot, for example, (reliably, because some people try it anyway) implement CNAME records at the zone apex.

Chris
0
Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

 
LVL 26

Author Comment

by:skullnobrains
Comment Utility
@Chris : thanks a lot for the RFC ! but i think it is rather unclear and was wishing to read something definitive on the subject :

it checks to see if the resource set consists of a CNAME
record with a matching class

... so i undersatand that the RFC actually specifies that the class should be the same but says nothing about the type

... the provided example in the RFC shows the expected behavior for an A query matching a CNAME + A record chain and later gives detailed expected behavior for other types

Both of these RRs would be returned in the response to the type A query,
while a type CNAME or * query should return just the CNAME.

... but nothing is stated regarding AAAA

since this RFC was written in 87, i believe that IPv6 was not really a concern, and other collisions such as PTR vs A are either meaningless or in the same case.

- unbound behaves like i described above (returning the CNAME but not following it)
- bind ( old 8.4.something ) does as well
- dnsmasq 2.68 as well

a funny thing is that the version of nslookup provided with bind8 translates the described server behavior into an NXDOMAIN while "host", "dig" and newer versions of "nslookup" do not

i'll keep the tread open for a little while since i'm interested into other servers and command-line clients behaviors as well as your thoughts on the subject. i'm also wondering if i did not miss an ulterior RFC that gives more detailed behavior on the matter.

btw, from my perspective, this behavior is rfc-complient but broken in essence. additionally, i even believe that following CNAMES might better be done on the client side if the CNAMES are exposed to the clients.

best regards
0
 
LVL 26

Author Comment

by:skullnobrains
Comment Utility
@ chris.

sorry, we cross-posted

There is a valid resource and a valid response for the original question (the request for a resource of arbitrary RRType where a CNAME exists), as such NXDOMAIN is not a valid response.

not quite : if you ask for type any, you end up with the cname and the server will not resolve the cname for you. this is definitely an expected behavior as long as the CNAME type is visible to clients.

the behavior i'm describing is when you specifically query for the A or AAAA of a record that has a CNAME that maps to a record of another type

... i understand your perspective though, but i have a hard time to adhere in this case

btw, cohabitation of A and CNAME records is forbidden by the RFC but is allowed by many servers and works pretty much as expected

best regards
0
 
LVL 70

Expert Comment

by:Chris Dent
Comment Utility
You rightly note that RFC 1034 (and it's partner 1035) are old. These are the original significant RFCs and are still authoritative for most of the behaviour of the DNS system.

AAAA was introduced with RFC 3596 (http://www.ietf.org/rfc/rfc3596.txt) but it doesn't do much to redefine the behaviour seen by 1034 (at least not with respect to processing of an RR-Set where an Alias exists). Instead it notes that the existing mechanisms must be extended to return both A and AAAA if called for.

Given that nothing states otherwise we will have to assume that the original behaviour of the RR set remains as stated in RFC 1034. That is, the response RR-set will include the RFC and the result of any additional processing.

So we should see this return the CNAME only:

dig red aaaa

And this return both CNAME and AAAA:

dig red any

The generation of an NXRecord response is a resolver side function, you shouldn't see this change regardless of the client. That is, unless the client is generating entirely the wrong question.

In all cases there's only one DNS header so no opportunity to change the RCode if additional processing produces nothing at all. Any additional processing will still be bound / limited by the Record Type requested in the question.

It is perhaps reasonable to test other records defined in RFC 1034 rather than introducing newer types. For example, you can produce the same alias response if you request a TXT record.

dig red txt

This isn't to say that server behaviour doesn't vary. Not all DNS servers strictly conform to published RFCs.

If you're feeling brave you're welcome to try my own DNS client to play with this behaviour (http://www.indented.co.uk/indented-dns/ or http://dnsshell.codeplex.com/). It was written based on the RFCs we're discussing here.

Finally on this:

> btw, cohabitation of A and CNAME records is forbidden by the RFC but is allowed by many servers and
> works pretty much as expected

This is true and I am aware of it, but I would note that no one should expect it to work and it will not work universally. Therefore it is a foolish mechanism to base a service on.

Depends on perspective though, if you're operating a DNS service for a bunch of clients you entirely control you are perfectly within your rights to use the mechanism as you see fit. If you're operating a public DNS service for hundreds of thousands of clients it's not such a good idea :)

Finally, if you are operating a large DNS service you may find lurking (or participating) in the DNS ops mailing list might be useful. Questions of this nature come up on there from time to time:

https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Chris
0
 
LVL 70

Expert Comment

by:Chris Dent
Comment Utility
Sorry one last item.

I can think of at least one reason why it's better to return a bare CNAME with NOERROR than an empty answer with NXDOMAIN. The CNAME response can be cached potentially reducing future processing even if the target RR set for that particular question doesn't contain the hoped-for RR type.

Ultimately the response to the CNAME may come from two different authoritative servers. It's not really the original servers (or indeed the resolvers problem) that the target doesn't contain the requested RR type. It can still be said to conform to RFC 1034 in my opinion.

Such things are slightly subjective and open to interpretation though, this is why we see slight differences in behaviour across different DNS server authors.

Chris
0
 
LVL 26

Author Comment

by:skullnobrains
Comment Utility
thanks @chris.

i'll happily accept your answer(s) and possibly dig into the mailing list as well

unfortunately, i won't be testing or using your client soon because my current projets don't require a different client, and i already have my own wrapper client that has extra RR types such as MXA, and variants of A and AAAA that skip cnames and i'll probably add records that follow CNAMES but produce the behavior i expect... but at a quick glance, your client library seems great and very complete and i'll be happy to use it whenever i get a chance.

i must concur with your assertion that RFC1034 still holds regarding that matter : after quite some digging into other RFCs, i can't seem to find any more precise information either.

thanks for pointing out the TXT case which i can confirm produces the same behavior on the above-mentioned servers at least.

nevertheless i'm unsure this actually is the kind of behavior the RFC authors intended in the first place, but this is all a matter of personal belief...

thanks for pointing out the caching issue, which is a valuable argument towards this behavior

one last point regarding this :

The generation of an NXRecord response is a resolver side function, you shouldn't see this change regardless of the client. That is, unless the client is generating entirely the wrong question.

actually, in this specific case, nslookup generates the proper question but transforms the answer. i did not peek at the source code, but a trace clearly shows the same queries and answers as with other tools. this only helps us remind that nslookup is not the best tool around when debugging dns issues.

best regards

@skull
0
 
LVL 26

Author Closing Comment

by:skullnobrains
Comment Utility
closest answer available

 my actual question apparently does not really have one

i'd advise future readers to read @chris's other posts as well if they are interested in this issue
0
 
LVL 70

Expert Comment

by:Chris Dent
Comment Utility
Good catch finding out that nslookup was rewriting. It's slightly concerning that debugging tools have been written to do such things, significantly lessens their usefulness. Ah well, it's a free world I suppose :)

Thank you for the interesting little discussion anyway, a nice little distraction from a never-ending bit of PKI management code I must finish writing :)

Chris
0

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
CISCO refresh sheets 2 33
Route summarization 5 20
WiFi Blackspot within home network 7 36
active directory 3 16
Let’s list some of the technologies that enable smooth teleworking. 
Don’t let your business fall victim to the coming apocalypse – use our Survival Guide for the Fax Apocalypse to identify the risks and signs of zombie fax activities at your business.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now