-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remote hostname resolved only once #29
Comments
I think you are correct. I will look at the PR tonight, lets get this embarresing issue solved as soon as possible. Thanks for reporting the issue! |
No worries, glad to help :) |
FantasticFiasco
pushed a commit
to nbaztec/serilog-sinks-udp
that referenced
this issue
Sep 9, 2018
Fixes issue where the hostname only resolves into an IP address when the sink is created. The very nature of hostnames is to provide a route to instances whose IP address may change, and these code changes allows for this situation. One limitation with the changes is that currently only IPv4 addresses are supported, but an upcoming PR will solve that issue. Closes FantasticFiasco#29
FantasticFiasco
pushed a commit
that referenced
this issue
Sep 9, 2018
Fixes issue where the hostname only resolves into an IP address when the sink is created. The very nature of hostnames is to provide a route to instances whose IP address may change, and these code changes allows for this situation. One limitation with the changes is that currently only IPv4 addresses are supported, but an upcoming PR will solve that issue. Closes #29
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Step 1: Describe your environment
Step 2: Describe the problem
Currently the UDP Sink supports a hostname as a destination in the configuration. Due to the implementation however the hostname is resolved only once at the application startup. This effectively removes the advantages associated with using hostnames since any future changes to the DNS won't be adjusted by the application at all.
Steps to reproduce:
foobar.local
via/etc/hosts/
. Point it to a locally available UDP listener (service, etc.). For example, running on192.168.1.100
.remoteAddress
=foobar.local
in the configuration. Keep it running so it's sending contant packets to the UDP listener service.192.168.1.200
./etc/hosts
to pointfoobar.local
to the new IP192.168.1.200
.Observed results
Expected results
The text was updated successfully, but these errors were encountered: