Azure – The Azure DNS service does not return IP address on CNAME record lookup

azureazure-networkingcname-recorddomain-name-system

I have found that the Azure DNS service does not return an IP address on the CNAME record lookup. For example Google or AWS Route 53 DNS servers kindly return IP addresses of corresponding A record on the same query. For test purposes I created www1 CNAME record pointing to the www.myzone.com:

AWS Route 53 test

$ dig www.myzone.com @ns-560.awsdns-06.net
;; ANSWER SECTION:
www.myzone.com.        7200    IN      A       MY.IP.ADD.RESS

$ dig www1.myzone.com @ns-560.awsdns-06.net
;; ANSWER SECTION:
www1.myzone.com.       3600    IN      CNAME   www.myzone.com.
www.myzone.com.        7200    IN      A       MY.IP.ADD.RESS

Google DNS servers shows same result:

$ dig www1.myzone.com @8.8.8.8
;; ANSWER SECTION:
www1.myzone.com.       3599    IN      CNAME   www.myzone.com.
www.myzone.com.        7199    IN      A       MY.IP.ADD.RESS

MS Azure test

$ dig www.myzone.com @ns1-02.azure-dns.com
;; ANSWER SECTION:
www.myzone.com.        7200    IN      A       MY.IP.ADD.RESS

$ dig www1.myzone.com @ns1-02.azure-dns.com
;; ANSWER SECTION:
www1.myzone.com.       3600    IN      CNAME   www.myzone.com.

Note that the Azure DNS returns no IP address on the 2nd query.

My question: is it an expected behavior and can I configure Azure DNS to return corresponding A record on the CNAME request like AWS or Google do?

I've found couple of the similar but unanswered topics on the MS forums (1, 2).

Best Answer

Yes, name server should return both CNAME and A in your specific scenario. RFC1034 says "Both of these RRs would be returned in the response to the type A query".

Related Solutions

Should BIND return an A record in the ANSWER SECTION for a glue record

Records returned as glue are never authoritative and will never appear in the answer section. If the provider just wants to verify that the glue exists, they should see it in the additional section.

Whoever is running the a-f.ns.test.example.com nameservers will need to add the A or AAAA records in the test.example.com zone since your delegating nameserver cannot.

BIND will automatically turn A records into glue when they are providing addresses for nameservers for zones you are delegating away. Once you set up a delegation as you have with test.example.com, BIND will treat any A or AAAA records for hosts you're delegating to as glue only.

Here is a dig with the delegation removed:

; <<>> DiG 9.7.0-P1 <<>> +norecurse @0 a.ns.test.example.com a
...
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;a.ns.test.example.com.     IN  A

;; ANSWER SECTION:
a.ns.test.example.com.  5   IN  A   1.1.1.1

;; AUTHORITY SECTION:
example.com.        5   IN  NS  gir.example.com.

;; ADDITIONAL SECTION:
ns.example.com. 5   IN  A   2.2.2.2

;; Query time: 0 msec

It is answering authoritatively. Here is the same with only the delegation added (the first block in your question):

; <<>> DiG 9.7.0-P1 <<>> +norecurse @0 a.ns.test.example.com a
...
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6

;; QUESTION SECTION:
;a.ns.test.example.com.     IN  A

;; AUTHORITY SECTION:
test.example.com.   5   IN  NS  f.ns.test.example.com.
test.example.com.   5   IN  NS  d.ns.test.example.com.
test.example.com.   5   IN  NS  a.ns.test.example.com.
test.example.com.   5   IN  NS  c.ns.test.example.com.
test.example.com.   5   IN  NS  e.ns.test.example.com.
test.example.com.   5   IN  NS  b.ns.test.example.com.

;; ADDITIONAL SECTION:
a.ns.test.example.com.  5   IN  A   1.1.1.1
b.ns.test.example.com.  5   IN  A   1.1.1.2
c.ns.test.example.com.  5   IN  A   1.1.1.3
d.ns.test.example.com.  5   IN  A   1.1.1.4
e.ns.test.example.com.  5   IN  A   1.1.1.5
f.ns.test.example.com.  5   IN  A   1.1.1.6

;; Query time: 0 msec

Notice the A records for a-f.ns.test are now glue. This is done automatically. Since you are delegating test.example.com, the superordinate nameservers can no longer answer authoritatively for anything in test.example.com. They can, however, return the A records in the zone as glue since they are delegating to them.

Centos – Cannot find solution to “One or more of your nameservers did not return any of your NS records.” on intoDNS site

In your named.conf file, you listen only to the localhost adapter, not to any external addresses. That will definitely be a problem since the rest of the world is talking to you through your external addresses. Fix that, then keep debugging (if needed).

Related Topic

Azure DNS – How to Set Local CNAME