-2

I'm running into the following situation and am wondering how to properly resolve it:

A nameserver is configured to not return CNAME records (not under my control), only if an A record is requested (for the same name) the CNAME is returned in the additional section.

Question 1: why would someone configure a DNS server to act like this? It doesn't make sense to me? (asked them several times, never got an answer)

Practical problem: When we resolve a hostname, say testa.hosta.com, we query an A record. In the response we get:

# query for A of `hosta.com`
testa.hosta.com CNAME testb.hostb.com  TTL=5
testb.hostb.com A     1.2.3.4          TTL=60

So we're storing both records in our cache. Since we didn't get the A record we were looking for, we now try a CNAME record. But this one is in the cache, it points to testb.hostb.com. Now trying an A record for testb.hostb.com, which is also in the cache, so we finally resolve to 1.2.3.4. So all is fine up till now.

After 5 seconds the TTL of the CNAME expires. Because the data is stale, we need to refresh it. So we query for testa.hosta.com CNAME, and this delivers an empty response. Now our lookup is broken...

Question 2: is this lookup logic faulty? I went through many rfc's to figure it out, but couldn't find anything. What would the proper lookup order be?

Any help is greatly appreciated.

  • If you do something like dig CNAME hosta.com @DOMAIN_ORGIN dose it return error? Is it working for say CNAME record test.hosta.com? Keep in mind that serving CNAMEs for domain root is not RFC complaint so most DNS providers won't allow such record at all. (there are tricks like CNAME flattening, but very few providers provide this) – Daniel Apr 2 '18 at 11:54
  • 1
    In answer to question 1, there is likely no good reason at all. CNAME records are often abused as people sometimes forget there's more to DNS than addresses. – Torin Apr 2 '18 at 11:56
  • 2
    It doesn't make much sense to perform a lookup with the type set to CNAME. How are you managing to do this? WHY are you doing it? – Michael Hampton Apr 2 '18 at 14:10
  • After 5 seconds the TTL of the CNAME expires. Because the data is stale, we need to refresh it. So we query for hosta.com CNAME, and this delivers an empty response. Now our lookup is broken... -- This is what your question needs to focus on. The rest is assumptions, up to and possibly including this statement. In all likelihood you are misunderstanding the actual problem. Please provide examples to demonstrate that this is in fact the case. Keep in mind that the recursive server might temporarily be unable to answer on the refresh if the auth servers are taking a long time to respond. – Andrew B Apr 2 '18 at 20:18
  • 1
    How about updating it with the actual domain names in question? It makes the whole thing much easier to answer. – MadHatter Apr 3 '18 at 13:49
3

Q1

I have no idea why, that rather sounds like a broken implementation which returns inconsistent results.

Q2

Yes, the logic you describe is faulty; you have no reason to change the query type.

It sounds like what you are actually looking for is the very fundamentals of recursive resolver server behavior.

From RFC1034 Resolver internals / Algorithm section (5.3.3):

5.3.3. Algorithm

The top level algorithm has four steps:

  1. See if the answer is in local information, and if so return it to the client.

  2. Find the best servers to ask.

  3. Send them queries until one returns a response.

  4. Analyze the response, either:

    a. if the response answers the question or contains a name error, cache the data as well as returning it back to the client.

    b. if the response contains a better delegation to other servers, cache the delegation information, and go to step 2.

    c. if the response shows a CNAME and that is not the answer itself, cache the CNAME, change the SNAME to the canonical name in the CNAME RR and go to step 1.

    d. if the response shows a servers failure or other bizarre contents, delete the server from the SLIST and go back to step 3.

  • yes, this is exactly what I was looking for. Thank you. I must have skipped over this while being braindead from reading too many of those RFC docs – Tieske Apr 4 '18 at 7:33
3

Based on this information:

Practical problem: When we resolve a hostname, say hosta.com, we query an A record. In the response we get:

# query for A of `hosta.com`
hosta.com CNAME hostb.com  TTL=5
hostb.com A     1.2.3.4    TTL=60

This is entirely expected. If you query for an A record, but only get a CNAME back (as shown in this blurb you posted) that indicates that there is no A record for that domain, but instead it is a CNAME to a different A record.

Question 1: why would someone configure a DNS server to act like this? It doesn't make sense to me? (asked them several times, never got an answer)

As @michaelhampton pointed out, why are you querying for a CNAME in the first-place? If you are attempting to perform a host-lookup to resolve a host-name to an IP address, then you should be querying for A records. If the owner of the domain has instead opted to use a CNAME record for this host-name, then it is appropriate that you will receive the CNAME and A record back in the response.

UPDATE:

After 5 seconds the TTL of the CNAME expires. Because the data is stale, we need to refresh it. So we query for testa.hosta.com CNAME, and this delivers an empty response. Now our lookup is broken...

This is fine, except you should not be querying the CNAME and instead re-query it as an A record. The moment your cached value expires, you can no longer assume you know anything about it; you must take the assumption that it's an A record and allow the DNS system to perform its work and let it you tell you otherwise.

You should always query for A records unless you are trying to debug or diagnose something.

  • as mentioned in the other comment, if the recursive server doesn't have the CNAME yet, or it temporarily is unavailable, then the resolver logic would, after having failed the A lookup, at some point have to go look for a CNAME anyway right? so somewhere in the process there is in the end a reason to request a CNAME... – Tieske Apr 3 '18 at 10:58
  • No. The query will continue as an A query until the authoritative nameserver responds. The response will be what you see, where it responds stating that the requested hostname is actually a CNAME and then will return what the CNAME resolves to until an A record is returned. Recursive queries are not querying CNAMEs, they don't know that it's a CNAME until an authoritative response says otherwise. – Andrew Apr 3 '18 at 13:07
  • That makes sense, but not all the way (sorry for being a pita, just trying to learn). Playing devils advocate; recursive server initially resolves 5 second TTL and returns them to me. After 5 seconds the server should discard the CNAME (expired). But the missing response for the A record for testa.hosta.com is cached longer (negative cache from SOA). So when my client requeries the A record, then according to specs I'd expect an empty response. Since caching TTL is based on records not answers. (and no lookups to the authoritative server). So still might have to do a CNAME query – Tieske Apr 3 '18 at 21:03
  • @Tieske The recursive server cannot just randomly change the query type, the client did not ask for CNAME. What if the name is no longer an alias, then it would sit there with a negative response for something no one has asked it to look up. Also, there was never a negative response for testa.hosta.com A in your scenario, so that cannot possibly have been cached. Ie, when the CNAME expires from the cache, the testa.hosta.com A query will be made again as needed, and if nothing has changed in that zone it will get that same CNAME response again and cache that. – Håkan Lindqvist Apr 3 '18 at 23:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.