HTTP request node fails with CNAMEs

General
1

I see HTTP requests failing because of unresolvable names ("getaddrinfo ENOTFOUND").

The names could be resolved if the original CNAME entry delivered back from the server would be used for another request. It is my understanding that this the expected behavior from a client trying to get a name resolved. Am I missing something?

I crosschecked it with the node-red-contrib-dnsquery node and this behaves properly.

2

I think that it should work. There is a setting that prevents it from following redirects but it allows them by default.

followRedirects
If set to false prevent following Redirect (HTTP 301).true by default

Do you have a publicly accessible example?

3

Thanks for the comment. I am afraid this is within my LAN. I'll see if I can find a public CNAME entry to compare it to.

4

I think I found a reason why this is happening but I'm still not sure the behavior is correct or if my pihole does something wrong.

The response to the query for mail.google.com. includes both, the CNAME and the respective A record (verified with dig from the command line). The response for influxdb.lan. from my pihole instance only returns the CNAME record and no corresponding A entry (database.lan). If it matters, /etc/hosts does not contain influxdb.lan but database.lan.

Edit: Just to be clear, this is on a different protocol level. Name resolution happens before the actual GET request that could encounter a 301 redirect.

5 
home@home:~$ dig mail.google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> mail.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47227
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mail.google.com.               IN      A

;; ANSWER SECTION:
mail.google.com.        604698  IN      CNAME   googlemail.l.google.com.
googlemail.l.google.com. 198    IN      A       172.217.169.37

;; Query time: 14 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun Dec 20 12:12:57 GMT 2020
;; MSG SIZE  rcvd: 87

home@home:~$ nslookup mail.google.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
mail.google.com canonical name = googlemail.l.google.com.
Name:   googlemail.l.google.com
Address: 172.217.169.37
Name:   googlemail.l.google.com
Address: 2a00:1450:4009:816::2005

So that is the same I assume?

Assuming that you are getting back a definitive IP address that you can access, as far as I can see, that should work. The CNAME to IP address conversion should happen at the DNS level so I don't believe that Node-RED would have any issues.

Have you tried doing the nslookup from an exec node inside Node-RED? I think the problem is much more likely to be related to your environment.

Unfortunately, without an equivalent example, I can't reproduce your issue so not sure what I can do to help.

6

Thanks again for your comments.

Nice DNS servers serve both records (CNAME and A) in the first response. But when it only gets a CNAME response, the expected behavior of a client is to ask again but this time with the name extracted from the CNAME record.

Pihole's DNS implementation doesn't seem to be nice but it should still work and clients should follow up with a second query. Regrettably, I don't know a publicly accessible DNS server that behaves as unfriendly as pihole's.

7

I use pihole and have not had any problems. Can you post an example that I can import, which uses a publicly accessible site that causes the problem when pihole is enabled?

8

I solved my issue by adding an explicit DNS entry for the canonical host in pihole. Queries now get a response with the alias and the proper A record.

Even though my situation is solved, I am not sure if the HTTP node should not issue another query after initially only receiving a CNAME record (this source confirms the assumption that a second query should be issued). Regrettably, I cannot point to an example of a DNS server showing this kind of behavior for further testing.

9

Also the underlying request library is no longer maintained so is unlikely to be fixed until another library is identified

10

Is that something that needs help? I rely on that enough to be somewhat motivated :wink:

1 Like
11

Already noted here - https://github.com/node-red/node-red/issues/2481
so yes please join in, push in forward.

2 Likes
12

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.