Post:
zypper se -si firewall
# zypper se -si firewall
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+------------------+---------+--------------------+--------+---------------------
i+ | firewall-macros | package | 0.5.5-lp150.2.18.1 | noarch | (System Packages)
i+ | firewall-macros | package | 0.5.5-lp151.5.1 | noarch | openSUSE-Leap-15.1-1
i+ | firewall-macros | package | 0.5.5-lp151.5.1 | noarch | Main Repository
i+ | python3-firewall | package | 0.5.5-lp151.5.1 | noarch | openSUSE-Leap-15.1-1
i+ | python3-firewall | package | 0.5.5-lp151.5.1 | noarch | Main Repository
i+ | yast2-firewall | package | 4.1.12-lp151.1.1 | noarch | openSUSE-Leap-15.1-1
i+ | yast2-firewall | package | 4.1.12-lp151.1.1 | noarch | Main Repository
linux-dqd8:/home/ion #
Please show your repos, I see at least one 15.0 package firewall-macros.
# zypper lrRepository priorities are without effect. All enabled repositories share the same priority.
# | Alias | Name | Enabled | GPG Check | Refresh
---+---------------------------+------------------------------------+---------+-----------+--------
1 | openSUSE-Leap-15.1-1 | openSUSE-Leap-15.1-1 | Yes | (r ) Yes | Yes
2 | repo-debug | Debug Repository | No | ---- | ----
3 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ----
4 | repo-debug-update | Update Repository (Debug) | No | ---- | ----
5 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | ---- | ----
6 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes
7 | repo-oss | Main Repository | Yes | (r ) Yes | Yes
8 | repo-source | Source Repository | No | ---- | ----
9 | repo-source-non-oss | Source Repository (Non-OSS) | No | ---- | ----
10 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes
11 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes
linux-dqd8:/home/ion #
Please always post including the URIs. Now we have only the names and aliases local to your system, which does not say anything (execpt by guess) about what they are. E.g."
zypper lr -d
# zypper lr -d# | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service
---+---------------------------+------------------------------------+---------+-----------+---------+----------+--------+--------------------------------------------------------------------------+--------
1 | openSUSE-Leap-15.1-1 | openSUSE-Leap-15.1-1 | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/distribution/leap/15.1/repo/oss/ |
2 | repo-debug | Debug Repository | No | ---- | ---- | 99 | rpm-md | http://download.opensuse.org/debug/distribution/leap/15.1/repo/oss/ |
3 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ---- | 99 | rpm-md | http://download.opensuse.org/debug/distribution/leap/15.1/repo/non-oss/ |
4 | repo-debug-update | Update Repository (Debug) | No | ---- | ---- | 99 | rpm-md | http://download.opensuse.org/debug/update/leap/15.1/oss/ |
5 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | ---- | ---- | 99 | rpm-md | http://download.opensuse.org/debug/update/leap/15.1/non-oss/ |
6 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/ |
7 | repo-oss | Main Repository | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/distribution/leap/15.1/repo/oss/ |
8 | repo-source | Source Repository | No | ---- | ---- | 99 | rpm-md | http://download.opensuse.org/source/distribution/leap/15.1/repo/oss/ |
9 | repo-source-non-oss | Source Repository (Non-OSS) | No | ---- | ---- | 99 | rpm-md | http://download.opensuse.org/source/distribution/leap/15.1/repo/non-oss/ |
10 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/leap/15.1/oss/ |
11 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/leap/15.1/non-oss/ |
linux-dqd8:/home/ion #
Although dig can be used to test and troubleshoot name resolution, I prefer nslookup.
After invoking nslookup
nslookup
You can query the existing configured nameserver(s) for any Domain, note that the result verifies the DNS server address you are querying
www.opensuse.org
You can also change the DNS server to be queried from the CLI without altering any files.
For instance, the following changes the DNS server to be queried, and then you can query an address again (above command)
server 9.9.9.9
The above should be sufficient to query any reachable DNS servers to verify whether servers or domains are faulty.
When you want to exit nslookup
quit
If you have no problems resolving to specific or any DNS servers, then your problem isn’t name resolution on your machine, it’s something else… Maybe the application? Try using a different application if some app is having problems.
Although someone may be thinking of something I haven’t, if the above verifies name resolution is working, I’m not sure why looking at things lower in the OSI layers like firewall issues (and configured repos) is likely to reveal anything. I’d be looking for something higher in the OSI layers, which is why I’d suggest considering the application that’s having problems.
TSU
Looks fine. Except, as you can see now we have the URIs, that #1 and #7 are the same. Not fatal, but better remove one of them.
Well I have been trying to connect with both Firefox and Vivaldi. I think it’s unlikely they are both bad.
So I did the following…
# nslookup> www.opensuse.org
Server: 208.67.222.222
Address: 208.67.222.222#53
Non-authoritative answer:
Name: www.opensuse.org
Address: 130.57.66.6
linux-dqd8:/home/ion #
…and then tried the address (130.57.66.6) with both Firefox and Vivaldi and here’s the response for both…
Your connection is not secure
The owner of 130.57.66.6 has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.
Learn more…
Report errors like this to help Mozilla identify and block malicious sites
130.57.66.6 uses an invalid security certificate.
The certificate is only valid for the following names:
*.opensuse.org, opensuse.org
Error code: SSL_ERROR_BAD_CERT_DOMAIN
This is way above my level of understanding.
This simply means that the site is properly configured, i.e. IP is correct, but the https certificate is not valid for the IP address, only for the domain name.
Enough! Thank you all for trying to solve my problem but it’s been taking up too much of your time…and mine. Case closed.
That is for each one of us to decide.
That is your decision.
Looks like…
These apps do an SSL check to verify you are connecting to your intended website and not an impersonating website (which is good)
But
These apps don’t understand how to handle a wildcard Domain (That asterisk which signifies the Hostname part of the FQDN can be anything).
This is not totally unexpected, I can remember when wildcard SSL certificates were not valid but today is widely acceptable and handled properly.
You can assist those apps by reporting the error to them.
As for yourself,
This particular error is not something to be concerned about, and your DNS name resolution is working fine.
If you’re experiencing some other kind of problem testing a different URL, you can post what you have for others to comment.
TSU
I too have exactly the same problem did you solve it?
I have actually got mine up and running. I went into Yast -> network configuration and changed from Static address to DHCP exited then tried to browse and nothing worked. I then went back into Yast and put myself back into static address saved it. Went back to Firefox and browsed normally everything worked and without a reboot!
A potential “Gotcha” is in ‘/etc/nsswitch.conf’: check for the following – should be as follows:
hosts: files dns
networks: files dns
I did an upgrade of my father’s machine to 15.3 today and that failed halve-way because the upgrade could not find a certain file.
After a reboot a login screen came up but not possible to log in, even as root, the password was accepted but after 1 second the log in screen came back.
So back to the virtual console and I could log in as root. Tried a zypper dup but that failed on DNS.
Then did some debugging and did run into the same problem as in this thread, dig can resolve the address, but ping indicates it can not resolve any domain, and zypper has the same problem.
I did check the servers, they could be pinged and using dig @<server-adress> did show that these servers were also working (even tried 9.9.9.9), but still not on the command line, dig works but ping does not resolve host
One more thing I tried is adding the entries to /etc/hosts but even that did not work.
So what is different between how dig is resolve and the command line?
“dig” always used DNS. Other software check “/etc/nsswitch.conf” to decide how to resolve.
Thanks, I did check /etc/nsswitch.conf and it had (just like my running Tumbleweed system):
hosts: files mdns_minimal [NOTFOUND=return] dns
Having files as first I would have expected that static entries added to /etc/hosts would work, but they also did not resolve.
Also tried with “hosts: files dns” but also that did not work.
Does anybody has an idea with piece of software is responsible for resolving? I checked systemd but I did not see systemd-resolved running nor present.
Maybe better upgrade first to 15.3? Then it is easier for others to try to reproduce or otherwise communicate about the same system on all sides.