[syslog-ng] 'network' Destination With Hostname Resolution (IPv4 vs IPv6)
David Hauck
davidh at netacquire.com
Fri Sep 28 20:54:28 UTC 2018
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<mailto: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<mailto: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<http://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<mailto: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<mailto: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> <mailto: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>
> <mailto: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>> <mailto: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>> >
> <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20180928/b2d21baf/attachment-0001.html>
More information about the syslog-ng
mailing list