'network' Destination With Hostname Resolution (IPv4 vs IPv6)
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
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@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
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. On Wed, Sep 19, 2018, 19:23 David Hauck <davidh@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@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
Hi Balazs, On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@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@netacquire.com <mailto:davidh@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@lists.balabit.hu <mailto:syslog-ng-bounces@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 >
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. 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@netacquire.com> wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng < syslog-ng-bounces@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@netacquire.com <mailto: davidh@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@lists.balabit.hu <mailto:syslog-ng-bounces@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
Hi Balázs, Thanks for your thoughts. Please see below. On Fri, 21 Sep 2018 at 04:52:00, syslog-ng <syslog-ng-bounces@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@netacquire.com <mailto:davidh@netacquire.com> > wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@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@netacquire.com <mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com <mailto:davidh@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@lists.balabit.hu <mailto:syslog-ng-bounces@lists.balabit.hu> > <mailto:syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@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
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@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@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@netacquire.com <mailto:davidh@netacquire.com> > wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@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@netacquire.com <mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com <mailto:davidh@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@lists.balabit.hu <mailto:syslog-ng-bounces@lists.balabit.hu> > <mailto:syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@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
It's PR2312 on github. On Wed, Sep 26, 2018 at 4:01 PM Balazs Scheidler <bazsi77@gmail.com> wrote:
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@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@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@netacquire.com <mailto:davidh@netacquire.com> > wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@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@netacquire.com <mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com <mailto:davidh@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@lists.balabit.hu <mailto:syslog-ng-bounces@lists.balabit.hu> > <mailto:syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@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
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@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@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@netacquire.com<mailto:davidh@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@lists.balabit.hu<mailto:syslog-ng-bounces@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@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com>> > wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@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@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com>> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@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@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> > <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@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
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@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@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@lists.balabit.hu<mailto:syslog-ng-bounces@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@lists.balabit.hu<mailto:syslog-ng@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@netacquire.com<mailto:davidh@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@lists.balabit.hu<mailto:syslog-ng-bounces@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@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com>> > wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@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@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com>> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@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@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> > <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@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
Hi, thought I would check in again to see if there were any comments on my questions below? Thanks, -David From: syslog-ng <syslog-ng-bounces@lists.balabit.hu> On Behalf Of David Hauck Sent: Friday, September 28, 2018 1:54 PM To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Subject: Re: [syslog-ng] 'network' Destination With Hostname Resolution (IPv4 vs IPv6) 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@lists.balabit.hu<mailto:syslog-ng-bounces@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@lists.balabit.hu<mailto:syslog-ng@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@lists.balabit.hu<mailto:syslog-ng-bounces@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@lists.balabit.hu<mailto:syslog-ng@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@netacquire.com<mailto:davidh@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@lists.balabit.hu<mailto:syslog-ng-bounces@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@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com>> > wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@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@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com>> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@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@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> > <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@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
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@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@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@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@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@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@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@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@netacquire.com <mailto:davidh@netacquire.com> > wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@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@netacquire.com <mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com <mailto:davidh@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@lists.balabit.hu <mailto:syslog-ng-bounces@lists.balabit.hu> > <mailto:syslog-ng-bounces@lists.balabit.hu <mailto:syslog-ng-bounces@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
Excellent, thx for clarifying. I am seeing that the patch is working for all of these variants. Very nice – allows me to not have to condition separate “destination” statements depending on whether the endpoint is specified as a name, IPv4 address, or IPv6 address. Thanks, -David From: syslog-ng <syslog-ng-bounces@lists.balabit.hu> On Behalf Of Balazs Scheidler Sent: Friday, October 05, 2018 3:59 PM To: Syslog-ng users' and developers' mailing list <syslog-ng@lists.balabit.hu> Subject: Re: [syslog-ng] 'network' Destination With Hostname Resolution (IPv4 vs IPv6) 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@netacquire.com<mailto:davidh@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@lists.balabit.hu<mailto:syslog-ng-bounces@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@lists.balabit.hu<mailto:syslog-ng@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@lists.balabit.hu<mailto:syslog-ng-bounces@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@lists.balabit.hu<mailto:syslog-ng@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@netacquire.com<mailto:davidh@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@lists.balabit.hu<mailto:syslog-ng-bounces@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@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com>> > wrote:
Hi Balazs,
On Wednesday, September 19, 2018 9:21 PM, syslog-ng <syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@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@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com>> <mailto:davidh@netacquire.com<mailto:davidh@netacquire.com> <mailto:davidh@netacquire.com<mailto:davidh@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@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> > <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu> <mailto:syslog-ng-bounces@lists.balabit.hu<mailto:syslog-ng-bounces@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
participants (3)
-
Balazs Scheidler
-
David Hauck
-
Scheidler, Balázs