On Jan 16 21:51, Sebastian Benoit wrote:
> Eric C. Landgraf([email protected]) on 2020.01.15 12:11:30 -0500:
> > >Synopsis: relayd will not launch when listener host is a CNAME
> > >Description:
> > DNS of host listener:
> >
> > www.seaturtle.pw. 338 IN CNAME seaturtle.pw.
> > seaturtle.pw. 338 IN A 73.12.116.18
> >
> > Error thrown by `relayd -n`
> >
> > host_dns: www.seaturtle.pw resolves to more than 1 hosts
> > /etc/relayd.conf:29: relay www.seaturtle.pw:http or listener
> > defined twice
> >
>
> Why do you need to use the CNAME in the listen statement and cant use the
> seaturtle.pw name? Or an IP address?
I left out the entirety of the listen statement: I had listeners
configured for several different names---in this case all CNAMEs for the
same IP: this allowed me to TCP proxy services for hosts of different
names on the same port, and it *appeared* to work as expected, cueing
off of SNI for TLS connections and other indications of server name for
generic TCP connections. Such generic TCP relaying is certainly a
function of f5 appliances and HAProxy. But I may be mistaken in the
behaviour there.
So prior, I had config e.g.:
relay "seaturtle.pw:https" {
listen on "seaturtle.pw" port 443
forward to $pewserv4 port 443 inet
}
relay "www.seaturtle.pw:https" {
listen on "www.seaturtle.pw" port 443
forward to $pewserv4 port 443 inet
}
and, as I recall, if they forwarded to different hosts (instead of the
same), they would still both work.
All this is to say, my error should probably be revised to say "relayd
now fails to launch when multiple names resolve to the same IP(s)".
Whether that is the correct behaviour is a different discussion, as it
certainly is a regression.
> This may be a result of this commit:
>
> Author: denis <denis>
> Date: Mon Oct 22 07:08:02 2018 +0000
>
> Make host_*() AF-agnostic
>
> Merge host_v{4,6}() into much simpler host_ip() using just getaddrinfo().
>
> With input & test by kn@ and benno@
>
> OK benno@ kn@
ECL
