Forum

Not sure if this would qualify as a bug or not, but I'm seeing odd behavior when using ReverseProxy with IPv6. If a V6-resolvable-only host is listed as a ReverseProxy target on a dual-stack Linux server, the Hiawatha configuration check will fail thusly:

Using /etc/hiawatha
Reading hiawatha.conf
Can't resolve hostname 'ipv6.google.com'
Syntax error in hiawatha.conf on line 127.

It is indeed resolvable via both targets:

[root@tiberius ~]# cat /etc/resolv.conf
# Generated by resolvconf
domain multics.lan
nameserver 172.16.0.1
nameserver 2001:470:8a59::1
[root@tiberius ~]# dig @172.16.0.1 ipv6.google.com aaaa

; <<>> DiG 9.9.2-P2 <<>> @172.16.0.1 ipv6.google.com aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2651
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipv6.google.com. IN AAAA

;; ANSWER SECTION:
ipv6.google.com. 12929 IN CNAME ipv6.l.google.com.
ipv6.l.google.com. 162 IN AAAA 2607:f8b0:4006:807::1006

;; Query time: 2 msec
;; SERVER: 172.16.0.1#53(172.16.0.1)
;; WHEN: Tue Feb 25 09:47:50 2014
;; MSG SIZE rcvd: 103
[root@tiberius ~]# dig @2001:470:8a59::1 ipv6.google.com aaaa

; <<>> DiG 9.9.2-P2 <<>> @2001:470:8a59::1 ipv6.google.com aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59376
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipv6.google.com. IN AAAA

;; ANSWER SECTION:
ipv6.google.com. 12862 IN CNAME ipv6.l.google.com.
ipv6.l.google.com. 95 IN AAAA 2607:f8b0:4006:807::1006

;; Query time: 3 msec
;; SERVER: 2001:470:8a59::1#53(2001:470:8a59::1)
;; WHEN: Tue Feb 25 09:48:57 2014
;; MSG SIZE rcvd: 103

Hiawatha is configured to listen on both transports:

[root@tiberius ~]# cat /etc/hiawatha/hiawatha.conf | grep Interface
Interface = 172.16.0.10
Interface = 2001:470:8a59::10
Interface = ::1

Using strace to start Hiawatha looks like it is preferentially using the IPv4 transport for the lookup (understandable, since it appears first in resolv.conf), but failing for reasons unknown.

What's more concerning is that it appears the way ReverseProxy works is a one-time lookup at startup to do target resolution. This is problematic for all sorts of reasons, including a) what happens if the transport or DNS is down when the web server is restarted? [probable answer: Hiawatha doesn't come back] and b) what happens if the ReverseProxy target is a dynamically-addressed host? [probable answer: all proxy attempts after the remote IP changes will fail until Hiawatha is manually restarted].

Would it be possible to help me better understand why the initial resolution is failing and perhaps revisit the design of how ReverseProxy (and presumably any remote resolution) in Hiawatha functions?

Thanks,

Rodney

FYI, this is on Hiawatha 9.3 - if these issues are addressed in 9.3.1, please advise and I will upgrade ASAP.

Rodney

It was easy enough to pop it up to 9.3.1 - same issue.

Rodney

Hiawatha was using gethostbyname(), which seems to be obsolete. I've replaced them with getaddrinfo() and the problem seems to be gone. Will do some proper testing this evening. I will then also look at the 'one-time lookup' issue.