There is another fix for this HA to Github issue. Edit your ‘HOSTS’ file to include the mapping to the Github repository. That way, the DNS would not matter in the least.
I would be really grateful if someone tells me that info, I’ll edit my hosts file
John,
Thanks for replying to my comment. Because this is interesting to me.
I do not believe my statement was misleading.
Yes, the design of DNS servers (both authoritative and recursive) is what you have described. Authoritative servers own the IP address. Recursive dig into other servers (both authoritative and recursive) to get an address they do not own.
But DNS servers can be set with filters to ignore DNS names.
The fact that your next post about HOSTS files working proves this out. Your ISP is not blocking IPs. Your ISP’s DNS server is ignoring calls for Github. This is your ISP trying to prevent development type of functions from their clients.
You keep saying IOT gadgets have never needed Github is an assumption. If you have had IOT devices on other ISPs, they may have certainly made calls to Github that were not blocked by that ISP and just ‘worked’.
I doubt that most IOT devices are coded with IP addresses and generally need DNS.
So, again, I believe your ISP is blocking IOT devices that take updates by blocking Gibhub.
Of course, this is my opinion. That is kind of proved out by your DNS change.
Also, please select a post above as a solution. My opinion is that one of @123 's posts qualify.
Jeff
ISP breaks internet.
User blames Home Assistant.
This is news?
In point of fact @mobile.andrew.jones found the problem in post 4 of the thread when he said
Anyway good to know another thing to add to the troubleshooting toolbox, broken ISP DNS. Hope the rest of your ha journey goes smoother.
Just post this here: https://isitdns.com/
Thanks for taking the time to note down what it ended up being. It is on my todo list to improve the out-of-the-box experience in face of, let’s say, “not ideal” DNS environments 
Agners, there are posts all over the forum like this. It seems a common-ish problem. Some are admittedly to do with supervised installs, but not all.
Good to see O’Reilly is still about.
Maybe if ISPs are suggesting broken DNS servers, we need to go back to hosts files LOL.
Possibly a malware filter that is too agressive.
I know, but few have a good analyzes why the ISP provided DNS really failed.
To me it is a bit surprising that ISP DNS are really that messy, especially in the western world. But well, it is a wild wild west out there in the Internet 
I wonder if it’s worth the supervisor using a hardcoded known working DNS like 8.8.8.8 until it’s passed the landing page, and then using whatever the router provided once the system is up and running? @agners
It’s really not that uncommon, especially in rural areas with limited internet access. My parents internet provider is some random ass company and they have a really weird setup. I had to jump through hoops to get HA working with an out of the box configuration.
On Supervisor level we have CoreDNS as resolver which is used by Home Assistant Core, add-ons etc. CoreDNS has a fallback to Cloudflare.
On OS level, and that is what Docker uses and what failed in this case, we do have the fallback to Cloudflare too. However, the fallback mechanics in systemd-resolved are a bit different: From what I understand, if the DNS Server gives a response, it does not fallback. In a way this is the correct behavior, as it is privacy preserving. Unfortunately, I think that is exactly what many people run into.
One option would be to introduce a more forgiving fallback, but it comes at a cost privacy wise.
Ideally, I’d also have the same policy on OS and Supervisor level. But its all non-trivial, and I am worried that changing things too much around breaks setups which work today 
I was disheartened when /etc/resolv.conf became something that other processes took charge of.
Right, but operating on the principle that
a) we know the site must exist, so any response from the DNS server suggesting it doesn’t - should trigger a fallback DNS.
b) if the image is getting a 404, then we should fallback to a known working DNS.
It’s not really a problem with privacy, because it’s just to get us a working core. Once the supervisor says the system is healthy - it has the ability to reset the DNS of the actual host right?
if I was a betting man - I’d gamble on this being a very long running linux problem about sites that have IPv4 and IPv6 records. If the IPv6 address can’t be reached for some reason, it often fails to fallback to the IPv4 address.
Well, there could be a temporary outage server side. Fallback would then unnecessary try through other methods. In the end, it is a bit a question of the level of privacy you aim for. Usually if you are on that level, you probably want to block external DNS anyways
Which is also another case, we don’t handle all that gracefully: What if even the fallback is not reachable?Or http(s) access is blocked in general? Ideally I would really like to add more information if things go south. There will always be cases which we can’t resolve automatically 
Depending on the complexity of the network setup /etc/resolv.conf is really not enough. Add multiple network interfaces (e.g. VPNs), and various DNS suffixes, and it starts to fall apart. On such complex setup, systemd-resolved is really nice, IMHO.
What if we had a compromise for now which doesn’t fix anything as such - but - is basically a panic script that runs in the event that the system repeatedly cannot get to the image.
Essentially all it would do it print diagnostics to the log, with the results of DNS lookups. This would mean when someone was coming here to say the system wasn’t working, the log would contain a bit more useful information that would make it a lot easier for us to quickly say - yes, that’s a DNS problem, rather than having to step through the same troubleshooting steps every time.