Today I've got a similar issue, without Debian/Elive involved. But the proxy/DHCP is wrong configured.
lupus@k411e:~$ LANG=C sudo apt update
Err:1 http://http.kali.org/kali kali-rolling InRelease
Temporary failure resolving 'http.kali.org'
An other distribution, but the same result. Let me show my steps of analysis:
Is the cable plugged in? Or the Wifi connected?
lupus@k411e:~$ sudo ethtool eth0 |grep Link
Link detected: yes
Okay, where should all the traffic go to?
lupus@k411e:~$ ip r
default via 10.0.2.2 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
Here we have a VirtualBox VM with NAT to the Host network ... Not very helpful at this moment.
But let's try to resolve the hostname by hand:
lupus@k411e:~$ dig http.kali.org
;; connection timed out; no servers could be reached
I've expected this result ... Lets use another DNS Server:
lupus@k411e:~$ dig http.kali.org @184.108.40.206
;; ANSWER SECTION:
http.kali.org. 184 IN CNAME hebe.kali.org.
hebe.kali.org. 184 IN A 220.127.116.11
Okay, here we go. But how?
lupus@k411e:~$ cat /etc/resolv.conf
At this point it is helpful to know the real net of the host is 192.168.151.0/24 and 192.168.178.0/24 is existing, but only a transfer network for an old environment. The root cause is a wrong plugged cable from the hub of the transfer net to the hub of the work net. The DHCP of the transfer net answered first and the configuration for the client is not to use.
But even if we know the right network, what is the IP of the DNS? We don't care, because we already have a working DNS ... With the google DNS we can perfectly work in the internet, but not with local servers. Be careful while using a local ADS or something like this for your credentials.
The really short way is:
lupus@k411e:~$ echo "echo nameserver 18.104.22.168 >> /etc/resolv.conf" | sudo bash
lupus@k411e:~$ sudo apt update; sudo apt dist-upgrade
397 upgraded, 79 newly installed, 0 to remove and 0 not upgraded.
Need to get 1124 MB of archives.
After this operation, 1540 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Maybe we should delete the wrong lines in the
/etc/resolv.conf. for a better performance. But the system will try every name server listed, until one is answering.
Our changes should be overwritten after a restart or a new DHCP request (after unplugging the false cable).
If it was a proxy issue, the switching to https should be better. Using https is always a good idea. Because if somebody is performing a MITM (man in the middle) attach between your system and the repo, it is easy to change the whole repo, including the list of the checksum, which should protect us from malicious packages.
See SecureApt - Debian Wiki ... Because apt is still using MD5, it should not be rated as secure.