[syslog-ng] 'network' Destination With Hostname Resolution (IPv4 vs IPv6)
Balazs Scheidler
bazsi77 at gmail.com
Fri Oct 5 22:58:37 UTC 2018
Sorry, I was traveling this week. The dns related options affect dns
resolution for incoming messages.
On the outgoing side the hostnames of destination hosts are always
resolved, and yes my patch should fix this issue, i think.
Bazsi
On Fri, Sep 28, 2018, 16:54 David Hauck <davidh at netacquire.com> wrote:
> Hi,
>
>
>
> So I’m continuing to try to get this working. Part of this is that I’m
> having to re-do some v3.9.1 configuration for use with testing v3.17.2
> (unpatched). Not surprising that the canonical representation of an IPv6
> destination (my 2nd example below) works fine. Indeed the first example
> also appears to work fine (I do see resulting send on the network (source
> address is the correct local IPv4 address and this going out as IPv4). This
> is all great! Except I do see the following being logged everything the
> first destination used:
>
> 20180928 19:52:12.850 err syslog(syslog-ng):Error resolving hostname;
> host='192.168.1.1'
>
> 20180928 19:52:12.850 err syslog(syslog-ng):Initiating connection failed,
> reconnecting; time_reopen='10'
>
>
>
> Is this a consequence of the issue you mention below (and that you
> provided a patch for)? I wasn’t expecting that I would need that since I’ve
> turned off all DNS resolution (use-dns(no, dns-cache(no)) globally(*).
> However, maybe there is some sort of reverse lookup that’s required to
> satisfy the ip-protocol(6) with IPv4 address string logic?
>
>
>
> Thanks,
>
> -David
>
>
>
> * BTW, I also set keep-hostname(yes) globally. After reading closely it
> appears that DNS lookups **will** occur in this case. Is this true? How
> to force no DNS lookups while also keeping hostnames as-is (i.e., don’t
> attempt to DNS resolve) if they exist?
>
>
>
> *From:* syslog-ng <syslog-ng-bounces at lists.balabit.hu> * On Behalf Of *David
> Hauck
> *Sent:* Wednesday, September 26, 2018 7:35 AM
> *To:* Syslog-ng users' and developers' mailing list <
> syslog-ng at lists.balabit.hu>
> *Subject:* Re: [syslog-ng] 'network' Destination With Hostname Resolution
> (IPv4 vs IPv6)
>
>
>
> Hi Balazs,
>
>
>
> Excellent, that all makes sense. I expect this will appear in the next
> release of syslog-ng.
>
>
>
> And to fully confirm the below, the following will also then work I
> presume:
>
>
>
> destination d_one {
>
> network("192.168.1.1" ip-protocol(6));
> };
>
>
>
> destination d_two {
>
> network("fd07::1" ip-protocol(6));
> };
>
>
>
> If so, this all makes things much easier on my side (not having to detect
> the destination token’s applicability wrt ip-protocol(4) vs
> ip-protocol(6)). Moreover, all of the old (deprecated?) udp6/tcp6 vs.
> udp/tcp usage/distinctions can also go away.
>
>
>
> Thanks,
>
> -David
>
>
>
> *From:* syslog-ng <syslog-ng-bounces at lists.balabit.hu> *On Behalf Of *Balazs
> Scheidler
> *Sent:* September 26, 2018 7:01 AM
> *To:* Syslog-ng users' and developers' mailing list <
> syslog-ng at lists.balabit.hu>
> *Subject:* Re: [syslog-ng] 'network' Destination With Hostname Resolution
> (IPv4 vs IPv6)
>
>
>
> It should work, yes. Hmm.. I've tried what I've recommended in production
> and it does not work without this patch:
>
>
>
> ```
>
> diff --git a/lib/host-resolve.c b/lib/host-resolve.c
> index b685264f9..66915fe47 100644
> --- a/lib/host-resolve.c
> +++ b/lib/host-resolve.c
> @@ -144,6 +144,7 @@
> resolve_hostname_to_sockaddr_using_getaddrinfo(GSockAddr **addr, gint
> family, co
> hints.ai_family = family;
> hints.ai_socktype = 0;
> hints.ai_protocol = 0;
> + hints.ai_flags = AI_V4MAPPED | AI_ADDRCONFIG;
>
> if (getaddrinfo(name, NULL, &hints, &res) == 0)
> {
> ```
>
>
>
> With that patch, this configuration worked even if no ipv6 address was
> available:
>
> destination d_ipv6 {
>
> network("host.name.somewhere.com" ip-protocol(6));
> };
>
>
>
> The flags above basically mean the following logic (quoting from
> getaddrinfo):
>
> If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4
> addresses are returned in the list pointed to by res only if the local
> system has at least one IPv4 address config‐
> ured, and IPv6 addresses are returned only if the local system has
> at least one IPv6 address configured. The loopback address is not
> considered for this case as valid as a con‐
> figured address. This flag is useful on, for example, IPv4-only
> systems, to ensure that getaddrinfo() does not return IPv6 socket addresses
> that would always fail in connect(2)
> or bind(2).
>
> If hints.ai_flags specifies the AI_V4MAPPED flag, and
> hints.ai_family was specified as AF_INET6, and no matching IPv6 addresses
> could be found, then return IPv4-mapped IPv6
> addresses in the list pointed to by res. If both AI_V4MAPPED and
> AI_ALL are specified in hints.ai_flags, then return both IPv6 and
> IPv4-mapped IPv6 addresses in the list pointed
> to by res. AI_ALL is ignored if AI_V4MAPPED is not also specified.
>
>
>
> This means that as long as you have a local ipv6 address configured
> (loopback does not count) and the server has an IPv6 address, syslog-ng
> would be using that. If the server does not have one or there's no local
> ipv6 address, it'd be using an IPv4-mapped address (e.g. ::ffff:1.2.3.4)
> and would continue to use ipv4 on the wire.
>
>
>
> I am posting this fix as a PR on github in a moment.
>
>
>
> On Tue, Sep 25, 2018 at 3:59 PM David Hauck <davidh at netacquire.com> wrote:
>
> Hi Balázs,
>
> Thanks for your thoughts. Please see below.
>
> On Fri, 21 Sep 2018 at 04:52:00, syslog-ng <
> syslog-ng-bounces at lists.balabit.hu> On Behalf Of Scheidler, Balázs wrote:
> > The reason you need to explicitly ask for ip-protocol(6) is that
> > sometimes, syslog-ng by itself can create such a socket, can even
> > resolve DNS names to ipv6 addresses and then communication wouldn't
> > work without an actual ipv6 tunnel/connectivity. Setting ip-protocol(6)
> > everywhere would achieve auto-detection and it probably would make sense
> > to make this configurable globally, not on a per-destination basis.
>
> Independent of a potential globally configurable hint would it work to use
> ip-protocol(6) in all of my destination configurations directly, regardless
> of whether the specified <destination-address> is a hostname (which may be
> resolve to an IPv4 or IPv6 address), an IPv4 address string, or an IPv6
> address string?
>
> I would really like to just specify this once for each/all destinations (I
> don't mind doing it for each destination, I just don't want to have to
> evaluate whether to use ip-protocol([46])*).
>
> Regards,
> -David
>
> * The destination configurations are performed programmatically and the
> extra determination for whether the configured <destination-address> falls
> into any of the above three categories is cumbersome/tricky at the locale
> where this done.
>
> > That would probably be something like this:
> >
> > * introduce ipv6 related attributes in GlobalConfig, defaulting to
> ipv4
> >
> > * have those attributes configurable through cfg-grammar.y (e.g.
> > the main configuration parser)
> > * in each destination that supports ipv6, inherit the global value
> > unless overridden locally
> >
> > There are similar patterns in the configuration/destination relation,
> > for instance with log-fifo-size() where there's a global and a local
> setting as well.
> >
> >
> > With that said, I'd say that patches are welcome, I couldn't work on
> > it myself right now, but I am happy to review any solutions.
> >
> >
> > On Thu, Sep 20, 2018 at 6:03 PM David Hauck <davidh at netacquire.com
> <mailto:davidh at netacquire.com> > wrote:
> >
> >
> > Hi Balazs,
> >
> > On Wednesday, September 19, 2018 9:21 PM, syslog-ng
> > <syslog-ng-bounces at lists.balabit.hu
> > <mailto:syslog-ng-bounces at lists.balabit.hu> > On Behalf Of Balazs
> Scheidler wrote:
> > > Ip protocol v6 should support both ipv4 and v6. So if you use
> that and
> > > the name resolves to a v4 address or should work.
> >
> > OK, interesting.
> >
> > For a different reason it would also be good if I could always
> > specify ip-protocol(6) (non-default) for any value of "myhost" below -
> > i.e., even when this is an explicit IPv4 or IPv6 address string. Would
> > this also work? And if this were to work (I see no reason why it
> > wouldn't if what you say about hostname resolution above) then I guess
> there is no value in specifying ip-protocol() at all, right (i.e.,
> syslog-ng could also just know to do the right thing in these cases)?
> >
> > Thanks,
> > -David
> >
> > > On Wed, Sep 19, 2018, 19:23 David Hauck <davidh at netacquire.com
> > <mailto:davidh at netacquire.com> <mailto:davidh at netacquire.com
> > <mailto:davidh at netacquire.com> > >> wrote: > >
> Hi, > >
> > Thought I would reach out again to see if anyone had any thoughts on the
> > item below. > > Thanks for the consideration, >
> -David >
> > > On Wednesday, September 12, 2018 3:39 PM, syslog-ng
> > <syslog-ng-bounces at lists.balabit.hu
> > <mailto:syslog-ng-bounces at lists.balabit.hu> >
> > <mailto:syslog-ng-bounces at lists.balabit.hu
> > <mailto:syslog-ng-bounces at lists.balabit.hu> > > On Behalf Of David Hauck
> > > wrote: > Hi, > > I have a question regarding how
> to
> > specify a network > destination when using a hostname when the >
> > hostname can be resolved > to either IPv4 or IPv6. In particular
> what
> > should be specified by the > ip- > protocol() parameter? There are
> > some configuration scenarios > and/or target installations that don't
> > > know a priori whether the DNS > configuration will resolve to an
> > IPv4 or IPv6 address.
> >>> E.g., > >
> > > destination d_tcp6 { > network( > "myhost"
> >>
> > > port(514) > transport(udp) >
> > ip-protocol(6 or 4 or ??)
> > > > ); > }; > > It seems like it would
> > simple enough to have
> > > syslog-ng simply validate the resulting IP address string to
> >>
> > > determine which of ip-protocol(4) or ip-protocol(6) is actually
> needed.
> > > In fact, I would argue that > specifying an IP address
> > string (as the
> > > "<destination-address>" value) could result in the same
> >> determination
> > > (the address string necessarily unambiguously determines whether
> the
> > > reference is an > IPv4 or an IPv6 address and I would think
> > there is a > 1-1 relationship between this determination and >
> > whether > ip-protocol(4) or ip-protocol(6) is used - (in other
> words it
> > would > never make sense to have > these mixed: "::1" and
> > ip-protocol(4) would > be invalid). > > Thanks, -David >
> >
> > ________________________________________________________________________
> > ______ Member info:
> https://lists.balabit.hu/mailman/listinfo/syslog-ng
> > Documentation:
> > http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ:
> > http://www.balabit.com/wiki/syslog-ng-faq
> >
> >
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation:
> http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>
>
>
> --
>
> Bazsi
>
> ______________________________________________________________________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation:
> http://www.balabit.com/support/documentation/?product=syslog-ng
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20181005/e242c2dc/attachment-0001.html>
More information about the syslog-ng
mailing list