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
Fix local DNS resolution issue #59
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- If DNS servers are configured manually and via DHCP, only use manually configured DNS servers not both
Fallback should be used. The possibility of disabling fallback can be added using within these scopes:
The solution in this PR does not match that. You already knew that, as that previous PR is yours as well... yet you choose to ignore it?
This comment has been minimized.
This comment has been minimized.
|
@frenck Can you please elaborate? Fallback is used:
This is a different issue. |
|
This PR has nothing to do with failover. Right now, if DNS servers are both manually configured and provided via DHCP, then both the manually configured and DHCP provided servers are used for load balancing. The manually configured DNS servers should overwrite the DHCP provided servers. |
I understand that is what you are trying to achieve, yet, we consider the DHCP servers a possible fallback/route as well, which is removed when servers have been manually set up. So, for the OS-based installs, resolving anything is considered more important than anything else. |
This comment has been minimized.
This comment has been minimized.
The current implementation doesn't resolve local dns names.... |
This comment has been minimized.
This comment has been minimized.
It does actually; for example, it gets mDNS local domains as known here: https://github.com/home-assistant/plugin-dns/tree/master/plugins/mdns; main reason for this is to work around issues with multicasting and Docker. As for my personal setup, I used even split DNS with custom local domains in the current method.
Because customizations on a managed systems are simply not supported by the core team. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This is not a generic discussion but a PR review. Your comments are general architectural comments and opinions on decisions made in the past for good reasons and are not reflecting the actual code being reviewed here. Please use or community forums or Discord chat if you'd like to discuss these types of things with others. Thanks. |
|
@frenck do you want to discuss via email or something? I'm looking for directions on how to move forward |
No? The direction to move forward has been pointed out already. I'm not sure what else you want from me at this moment. The project is willing to accept the capability of disabling fallback methods within the parameters pointed out already. |
I asked a few follow up question and never got a response... |
Sorry, maybe I missed something because of all the side spamming in this review. Could you point me out the question? |
This comment has been minimized.
This comment has been minimized.
What issue?
Okay
Okay
How should this work? My goal would be to find a way to make HA use the DNS server provided via DHCP and nothing else. |
|
@frenck Would it make more sense to just have a way to disable |
Multiple! The OS is aimed at the average Joe running this at home, with limited knowledge. We have had to deal with many many many different issues and network configurations (and misconfiguration) causing an absolute flood of issues. This has slowly (over time) resulted in what you see here. Most of the issues currently still there, are often the result of customizations or advanced network setup. This is fine, however, that is not the target audience. As a matter of fact, the number of DNS / name resolving issues hasn't been as low as it is right now. Broken local DNS, wrongly set up split DNS, misconfigured ad blockers, DNS loops, DNS of provides down causing issues, misconfigured Docker setups or virtual machines, wrongly configured firewalls, and many more.
A feature flag? I would say a boolean? Name... I dunno, something descriptive, however, that is just a name. Make it something descriptive, in the review of that specific PR that can be discussed (and adjustments to a name can be made quickly in general).
Add a flag to the supervisor and describe, pass the flag to the configuration of the DNS plugin so it can use it during the configuration generation. However, that is a bit out of scope for this PR as described I would say.
I don't think so, that will cause a different world of issues, as multiple parts of the system will assume it is there. |
Cloudflare DNS is currently setup as both a forwarding DNS server and a failover DNS server. I don't understand why this was done. It is hard to discuss a PR allowing this behavior to be changed when the reason for the behavior is unclear. Do you know why Cloudflare DNS was setup as both a forwarding DNS server and a failover DNS server?
But what configuration would this result in?
How do I discuss a PR I am working on then? |
Resolving anything is more important than solving nothing. The reason I gave in my last answer.
Disabling any fallback I would say? That is the goal you are trying to achieve, right?
This PR is titled: "Fix local DNS resolution issue", you are now discussing adding a supervisor feature flags for disabling fallback. I'm sorry, but that feels offtopic and not related to the content written in this PR (nor can this PR be modified to achieve that even remotely). |
The first PR you closed could have... but it has been locked so I can't ask for feedback now. Read the discussion in the PR, I actually asked about a feature flag before you even reviewed it. There was a lot of off topic discussion, but not from me. I have just been trying to get feedback on my PR. I give up :( nevermind |
This comment has been minimized.
This comment has been minimized.
Sorry it did not, the feature flag needs to be added to the supervisor as described before. None of the PRs I closed added a flag to the supervisor.
Yeah I know, sorry about that, its really distracting :(
:( If you change your mind and are up for a shot, let me know |
|
@alexdelprete This formal and final warning. That the last comment is unneeded and condescending (and not the first) another one will result in a ban. |
Supervisor just contains the flag, not the logic for what the flag does. I would assume it makes more sense to discuss what the flag does in the
If you are willing to work with me, I would like to tackle this. But I am not going to start working on the PR for supervisor to add a flag until after we figure out what the flag actually does. I don't know about you, but I write code THEN documentation, not the other way around. I will submit a new PR to |
This is not about adding documentation, this is about adding the controls. If there aren't controls and flags created in the supervisor, there will be nothing to test or control to implement. As for documentation that will be required before merging the final PRs
If you do, please do that in conjunction with the matching supervisor and CLI PRs that go with it. |
So you are saying you won't discuss the change here until after I write the PR for supervisor and CLI? So if you provide feedback on this PR that requires a change then I will have to rewrite all 3 PRs... doesn't it make more sense to review the DNS change and confirm it is good before implementing the flag? |
|
The dns part is the smallest part of the implementation and a fairly simple of statement handling the state of the flag (thus barely interesting or discussable imho) The other parts require way more implementation, code and tests. |
But I don't know what change to make in supervisor until we discuss this. There is a high probability that using more than one feature flag is the best way forward. Or maybe you don't want to use multiple flags but instead use a string config option. I think you will understand once I submit a PR. |
|
I don't think it's that difficult: use dns fallback or not. If the fallback is disabled only use the configured DNS servers... |
How should the following scenarios be handled? DNS servers have been provided both manually and via DHCP.
And this is assuming we aren't including the Docker DNS server anywhere. Should the Docker DNS server be used? |
|
Maybe instead of a single
|
|
I really don't think we should handle those cases at all from a flags perspective. If the single flag is turning off fallback: In case manual server are provided use those, else use DHCP provided one. |
Ok. What about Docker DNS server? Only use Docker if no servers are provided manually or via DHCP? |
|
Docker dns has no part in this, nor does it need to be. It will match the already available info, as the supervisor manages the network settings. |
|
@frenck The case I am trying to handle is if no servers are provided manually and no servers are provided via DHCP? Should the forward line just contain |
Hey, this describes me pretty well, I have some really limited knowledge, probably don't even belong in this discussion, but I'm having trouble getting Home Assistant to recognize the .local hosts that raspberry pi custom builds tend to set up. I have like three of them and I'm really going to hate to have to re-do each card when that device powers up and gets a new IP. It'd be really good if there was a thing to handle that. |
|
"a thing to handle that".. well that would be DNS...except HAOS devs have decided to break it, for "reasons". |
Note, this does not remove Cloudflare DNS server fallback.