Skip to content
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

only first name server attempted in finding the puppet server #9450

Closed
rtprio opened this issue Aug 15, 2024 · 4 comments
Closed

only first name server attempted in finding the puppet server #9450

rtprio opened this issue Aug 15, 2024 · 4 comments
Labels
accepted Valid issue that we intend to work on when we have the bandwidth bug Something isn't working

Comments

@rtprio
Copy link

rtprio commented Aug 15, 2024

Describe the Bug

I recently noticed all my puppet agents were failing when the primary DNS resolver was out. This was on FreeBSD.

Expected Behavior

I would expect that puppet would use the next nameserver in the list to look up the address of the puppet server.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Configure a host with two resolvers, the first one nonfunctional
  2. Run the agent, I used puppet agent -t -v --logdest console
  3. observe an error similar to the following

puppet-agent[29201]: Could not retrieve catalog from remote server: Host is down - sendto(2) for "10.0.17.2" port 53

Environment

  • Version 8.7.0
  • Platform FreeBSD 14.1

Additional Context

Add any other context about the problem here.

@rtprio rtprio added the bug Something isn't working label Aug 15, 2024
@joshcooper
Copy link
Contributor

joshcooper commented Aug 16, 2024

@rtprio can you provide more details about how you configured a "host with two resolvers, the first one nonfunctional"? Also does the hostname you're connecting to have multiple IPv4 addresses, or does it have both IPv4 and v6? Could you also add --trace and include the backtrace in the description.

@joshcooper joshcooper added the accepted Valid issue that we intend to work on when we have the bandwidth label Aug 27, 2024
@rtprio
Copy link
Author

rtprio commented Sep 3, 2024

sure thing;

the resolv.conf of the host was like this:

nameserver 10.0.17.2
nameserver 10.0.17.4

In this case, .2 crashed and was no longer answering DNS. These hosts only have a single ipv4 at the moment, I have not tested the ipv6 side of this condition.

@rtprio
Copy link
Author

rtprio commented Sep 4, 2024

I suppose I should have investigated deeper when it was happening; It seems to be properly using the next nameserver now. 🤷

@joshcooper
Copy link
Contributor

Thanks for letting us know. I'm going to close this, but if you can reproduce feel free to reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted Valid issue that we intend to work on when we have the bandwidth bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants