Feat: resolver DNS accept qType ALIAS/ ANAME

[renanbastos93]

Based on RFC today this draft, I guess interesting to give us support in a resolver recursive to query types ALIAS/ ANAME.
I did see how lib DNS works, below show reference of the files to possible changes.

• variable: ns_t_cname

  • deps/cares/include/nameser.h
  • src/cares_wrap.cc

• variable: T_CNAME

  • deps/cares/include/nameser.h
  • deps/cares/src/ares_parse_a_reply.c
  • deps/cares/src/ares_parse_aaaa_reply.c
  • deps/cares/src/ares_parse_ptr_reply.c

Also, we can need a change in this file https://github.com/nodejs/node/blob/master/lib/dns.js

see ya

[cjihrig]

I think we'd want any changes to deps/cares/ to land in the upstream c-ares project first.

[silverwind]

Why would you want to query those rrtypes? My understanding is that they will just return the resolved A and AAAA if the server supports them. The client should not have to explicitly support them.

[renanbastos93]

How this RFC still is draft, we can it feature as experimental.
The ALIAS/ NAME is a similarity with CNAME, I will try to explain advantages and disadvantages.

• advantages
  • Faster final answer resolution speed. In most cases, the authoritative servers for example.com are more powerful and have faster Internet connectivity than your own computer and connection. They can therefore traverse the DNS hierarchy and retrieve the final answer much faster than you can.
  • Answer looks like an A record. Since an ALIAS record returns the final answer consisting of one or more IP addresses, it can be used anywhere an A record can be used—including the zone apex. This makes it more flexible than a CNAME, which cannot be used at the zone apex.
• disadvantages
  • Geotargeting information is lost. Since it is the authoritative server for example.com that is issuing the queries for lb.example.net, then any intelligent routing functionality on the lb.example.net record will act upon the location of the authoritative server, not on your location. The EDNS0 edns-client-subnet option does not apply here. This means that you may be potentially mis-routed: for example, if you are in New York, and the authoritative server for example.com is in California, then lb.example.com will believe you to be in California and will return an answer that is distinctly sub-optimal for you in New York.

Reference about advantages and disadvantages: https://ns1.com/knowledgebase/comparing-alias-and-cname-records

@cjihrig I understood your comment, it's ideal first implement in c-ares but from what I saw our community is very more activate.

@silverwind yep, resolution back is A or AAAA, today some resolver that are use recursive to ANAME/ ALIAS normally is unbound

Do you have more questions? Ask-me

[silverwind]

Still not sure I follow. ANAME or ALIAS are DNS server features. Node.js does not implement a DNS server, only a client and to my understanding, a DNS client does not need to have specific support for these types, they query either A or AAAA and get the same type back, so the existance of ANAME or ALIAS is completely transparent to a DNS client, hence there's nothing to do for us (or c-ares for that matter).

[renanbastos93]

Okay, but we go presume that I am creating a server-side using NodeJS, but my server will be a DNS resolver, so it needs to resolve the ALIAS\ ANAME same the browsers.
However for me this treatment the lib DNS have to do.

Does it make sense to you?

[silverwind]

The dns module is not meant to implement a authorative DNS server and likely never will be. There are various userland modules for running a JavaScript-based DNS server and those would of course need to add support for these record types.

[renanbastos93]

Do you guess we should not implement this feature?
Okay, if not possible implement a DNS server authoritative this native lib, for me, we do not have why to have her.

What's the suggestion for me?

Sorry my form of the manifest, my English is more less.

[silverwind]

It's not a question of wanting. Every client (or more specifically, resolver) that can resolve A or AAAA already supports those types out of the box. The actual feature support is done on the authorative server.

[silverwind]

Looked at the RFC and it does actually feature a ANAME question. While I see no real purpose in doing it, it seems to be a valid feature request for a resolver, but as other mentioned, it needs to be added upstream in c-ares first.

;; QUESTION SECTION:
;example.com.                   IN      ANAME

;; ANSWER SECTION:
example.com.            5       IN      ANAME   example.com.my-cdn.example.net.

;; ADDITIONAL SECTION:
example.com.my-cdn.example.net. 5 IN    A       192.0.2.1
example.com.my-cdn.example.net. 5 IN    AAAA    2001:db8::1

[renanbastos93]

how nice, now I understand. After c-ares add this upstream them we community NodeJS we go add?

[silverwind]

Yes, but I would not bet on support soon. We have a few outstanding requests for c-ares tracked in #14713, I added yours. Closing this issue, ping us if c-ares has implemented it.