Ubuntu 18.04 Server - how to check DNS IP server setting being used [closed] - ubuntu-server

Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Working with Ubuntu 18.04 Server LTS. I am trying to find a way to check the DNS IP(s) that is actually being used when set via DHCP. The resolv.conf only will point to 127.0.0.53 now. /etc/systemd/network folder is empty. The NSLOOKUP output also always references the internal 127.0.0.53 IP. Seems all the old tricks aren't working.
The Ubuntu documentation is not updated yet as it still looks like the help for 16.04 referencing eth0, ifup and ifdown which are all deprecated on 18: https://help.ubuntu.com/lts/serverguide/network-configuration.html
I've tried setting a static adapter setup with Netplan via a custom .yaml. The settings work fine but I can't seem to find the DNS IP that I set anywhere. I expect it will be consistent between DHCP and static settings but I'm not sure where to look now.
I would settle for either a C library call or a bash CLI method at this point. Does anyone have a way to check this on 18.04 Server?

I found the following showed my the DNS servers by adapter towards the end of the output:
systemd-resolve --status
It contains a list under 'DNS Servers' organized by Link. I think this has changed from previous versions with Ubuntu. It will take a little text parsing work but this gives me what I'm after.

Another way is:
cat /run/systemd/resolve/resolv.conf
That file is dynamically generated by systemd-resolved, but contains the actual DNS servers instead of 127.0.0.53.
In fact, if you want make that the default for /etc/resolv.conf, you simply create symlink for it. (/etc/resolv.conf is a symlink that points to /run/systemd/resolve/stub-resolv.conf by default):
sudo mv /etc/resolv.conf /etc/resolv.conf.orig
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
Sample /run/systemd/resolve/resolv.conf :
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 10.1.2.3
search host.domain.com
For more info:
http://manpages.ubuntu.com/manpages/bionic/man8/systemd-resolved.service.8.html

You can also use:
nmcli dev show eth0
Replace eth0 with your network interface to see how it was configured. If you got the DNS address over DHCP, you should see it here.

I'm running ubuntu 22.04.
sudo nmcli dev show <interface> didn't have any dns listings, but sudo resolvectl status <interface> showed me the current dns server.

I am suprised at this too. I am running Ubuntu 16.04 LTS and see something similar.
If you issue a
dig www.google.ca +trace | grep 'Received'
The first host in the response is the one doing the lookups for your server.
$ dig www.google.ca +trace | grep 'Received'
;; Received 525 bytes from 127.0.1.1#53(127.0.1.1) in 19 ms
;; Received 42 bytes from 199.7.91.13#53(d.root-servers.net) in 32 ms
This means that this box is doing it's own dns lookups directly to the root servers and following the path recursively to get my dns lookups.
Found the issue is that dnsmasq is enabled. To disable it do as follows.
edit the NetworkManager.conf file
sudo gedit /etc/NetworkManager/NetworkManager.conf
comment out the dnsmasq line
#dns=dnsmasq
restart the network-manager service
sudo /etc/init.d/network-manager restart
then verify that it is using the dns-server assigned via dhcp
$ dig www.google.ca +trace | grep 'Received'
;; Received 525 bytes from 192.168.30.1#53(192.168.30.1) in 18 ms
;; Received 42 bytes from 198.41.0.4#53(a.root-servers.net) in 32 ms

Related

nameservers update differently with openconnect and openconnect-gnome in ubuntu 18.04

This seems to be a new issue with network-manager-openconect-gnome in Ubuntu 18.04+
I install sudo apt install network-manager-openconnect-gnome to get gnome integration with opeconnect and Cisco AnyConnect Compatible VPN (openconnect)
As an aside (which may actually be relevant) I do this to get *.local addresses to resolve:
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf as per systemd docs
Move dns before mdns4_minimal in /etc/nsswitch.conf
If I connect to the VPN with openconnect through the gnome network manager, VPN addresses (sites for work) do not resolve. Regular sites continue to work as expected.
If I connect to the VPN with openconnect on the command line with sudo openconnect vpn.mycompany.com, VPN addresses (sites for work) do resolve. Regular sites continue to work as expected.
I thought I would check to see if there were any differences between /etc/resolv.conf with each of these VPN connection methods and sure enough, there is one:
openconnect on the command line (working):
##VPNC_GENERATED# -- this file is generated by vpnc
# and will be overwritten by vpnc
# as long as the above mark is intact
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 10.10.10.10
nameserver 10.10.10.11
search broadband mycompany.com
openconnect gnome integration (not working):
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 192.168.1.1
nameserver 10.10.10.10
nameserver 10.10.10.11
search broadband mycompany.com
If I remove (or comment out) the nameserver 192.168.1.1, which is the difference in content between the working and not working files... everything works as expected. I can resolve addresses within the company and regular sites work as expected.
This does not happen with Fedora. Everything works out of the box. I'm not sure why the network-manager-openconnect-gnome package works differently or if there's a way I can make it work without either
Editing the file by hand.
Using the openconnect tool from the command line and keeping a terminal open running that command.

Linux Mint 19 Local DNS resolution problem

I installed Linux Mint 19 after using Ubuntu for a while,
I a have a local domain with subdomains,
I can ping mydomain.local
but I can't ping or access my subdomains with their names,
my DNS server IP = 10.0.0.4
Here's my /etc/resolv.conf generated with resolvconf:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 10.0.0.4
And here's my /run/systemd/resolve/stub-resolv.conf :
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 10.0.0.4
Please help me.
I found the problem, it was in the file /etc/nsswitch.conf in the line :
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
remark the "dns" is after the "[NOTFOUND=return]" part, so that is why the DNS resolution is not going correctly, so what I have done is moving "dns" before "[NOTFOUND=return]" part, and everything is good now.
I'm no Mint expert, don't know if I can help, but I'll certainly try... It's a bit 'blind leading the blind' in support forums :/
I recently installed Mint 19 but the only DNS issues I've had were caused by systemd's resolver. I have since replaced it with unbound.
I used this guy's instructions and it worked perfectly fine for me. YMMV.
https://blobfolio.com/2017/05/fix-linux-dns-issues-caused-by-systemd-resolved/
tl;dr: With systemd-resolve, LLMNR is used for short name resolution, which doesn't failover to a canonicalised DNS resolution. LLMNR is tried a few times and then it just fails without touching DNS.
I think there's a severe bug in it, TBQH - Others agree. Systemd's resolver behaves in an unexpected and possibly standards-breaking way and has done for 3-4 years.
HTH :D

Proxychains unable to locate file on kali linux [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
Improve this question
I'm having a problem with my kali linux and the proxychains: it outputs following error. It seems it cannot find the reference pointer for the exec or the exec has wrong info.
I have checked the resolv.conf file everything seems to be ok and also the proxychains.conf file seems to be running fine. I've tried multiple dns servers but the same error results.
Anyone has any solution ?
Output from the command line:
root#kali:~# proxychains iceweasel www.google.com
ProxyChains-3.1 (http://proxychains.sf.net)
|DNS-request| www.google.com
can't exec proxyresolv: No such file or directory
|DNS-response|: www.google.com is not exist
|DNS-request| www.google.com
can't exec proxyresolv: No such file or directory
|DNS-response|: www.google.com is not exist
Had the same issue, the symlink for proxyresolv seems to have been destroyed. Coincidence? I think not. Something to do with the latest upgrade.
Fix:
ln -s /usr/lib/proxychains3/proxyresolv /usr/bin/
I had the same issue on
Linux kali 3.18.0-kali3-586 #1 Debian 3.18.6-1~kali2 (2015-03-02) i686 GNU/Linux
root#kali:~# proxychains msfconsole
ProxyChains-3.1 (http://proxychains.sf.net)
[*] Starting the Metasploit Framework console...-[-] Failed to connect to the database: could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
Here's how I managed to get it up and running:
First make sure that this symlink is present:
ln -s /usr/lib/proxychains3/proxyresolv /usr/bin/
Comment out the proxy_dns line in /etc/proxychains.conf:
# Proxy DNS requests - no leak for DNS data
#proxy_dns
I haven't figured out the correct way to get this to work with proxy_dns enabled.
Trying again, seems to work fine.
root#kali:~# proxychains msfconsole
ProxyChains-3.1 (http://proxychains.sf.net)
[*] Starting the Metasploit Framework console...|
# cowsay++
____________
< metasploit >
------------
\ ,__,
\ (oo)____
(__) )\
||--|| *
Trouble managing data? List, sort, group, tag and search your pentest data
in Metasploit Pro -- learn more on http://rapid7.com/metasploit
=[ metasploit v4.11.1-2015042001 [core:4.11.1.pre.2015042001 api:1.0.0]]
+ -- --=[ 1445 exploits - 820 auxiliary - 229 post ]
+ -- --=[ 370 payloads - 37 encoders - 8 nops ]
+ -- --=[ Free Metasploit Pro trial: http://r-7.co/trymsp ]

SUSE Linux 12 - configuring IP alias

I want to setup an IP address alias on a Network card. I created a file /etc/sysconfig/network/ifcfg-ens160:0 and file contents are
BOOTPROTO=static
STARTMODE=onboot
IPADDR=192.168.0.2
NETMASK=255.255.255.0
Contents of file /etc/sysconfig/network/ifcfg-ens160 are
BOOTPROTO=static
STARTMODE=onboot
IPADDR=192.168.0.0
NETMASK=255.255.255.0
IPADDR_1=192.168.0.1
NETMASK_1=255.255.255.0
LABEL_1=ENS160:0
I restart the network by running systemctl restart network.service
and then run command /sbin/ipconfig -a, but I do not get both the IP address in results. I am not sure how to configure this.
You have filenames mixed up. If you use labels, you can just put everything into one file, namely the file which configures the main interface.
For example, put the following into /etc/sysconfig/network/ifcfg-ens160 to get interfaces ens160 and ens160:foo:
BOOTPROTO=static
STARTMODE=onboot
IPADDR=192.168.0.2
NETMASK=255.255.255.0
IPADDR_1=192.168.0.1
NETMASK_1=255.255.255.0
LABEL_1=foo
As a side note, this question should be in superuser or Unix & Linux Stack Exchange instead of SO as it's not a programming question.

DHCP overwrites Cisco VPN resolv.conf on Linux

I'm using an Ubuntu 8.04 (x86_64) machine to connect to my employer's Cisco VPN. (The client didn't compile out of the box, but I found patches to update the client to compile on kernels released in the last two years.) This all works great, until my DHCP client decides to renew its lease and updates /etc/resolv.conf, replacing the VPN-specific name servers with my general network servers.
Is there a good way to prevent my DHCP client from updating /etc/resolv.conf while my VPN is active?
If you are running without NetworkManager handling the connections, use the resolvconf package to act as an intermediary to programs tweaking /etc/resolv.conf: sudo apt-get install resolvconf
If you are using NetworkManager it will handle this for you, so get rid of the resolvconf package: sudo apt-get remove resolvconf
I found out about this when setting up vpnc on Ubuntu last week. A search for vpn resolv.conf on ubuntuforums.org has 250 results, many of which are very related!
If you are using the Ubuntu default with NetworkManager, try removing the CiscoVPN client and use the NetworkManager vpnc plugin to connect to the Cisco VPN. This should avoid all problems, since NetworkManager then knows about your VPN connection.
I would advice following the advice from #Sean, but if that fails for whatever reason, it should be possible to configure dhclient to not request DNS servers in /etc/dhcp3/dhclient.conf
chattr +i /etc/resolv.conf should work. ( -i to undo )
But the better thing is to configure your dhclient.conf:
https://calomel.org/dhclient.html
Look at superceding domain-name-servers, and domain-name.
Also look at "send hostname;"
If it works at your work place, you will have a cool hostname for your PC and not some weird name that DHCP servers assign.
vpnc seems to be doing the right thing for my employer's cisco concentrator. I jump on and off the vpn, and it seems to update everything smoothly.
The DHCPclient daemon can be told not to update resolv.conf with a command line switch. (-r I think, depending on the client)
That's less dynamic, because you'd have to restart/reconfigure DHCP when you connect, but not too hard. Similarly, you could just stop the service, but you might lose your IP in the meantime, so I wouldn't really recommend that.
Alternatively, you could run the dhcpclient from within a cron job, adding the appropriate process checks.
This problem is much more noticeable on networks with low DHCP lease ages. There is a bug filed in Ubuntu's dhcp3 package launchpad:
https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/90681
Which includes this patch in the description:
--- /sbin/dhclient-script.orig 2007-03-08 19:19:56.000000000 +0000
+++ /sbin/dhclient-script 2007-03-08 19:19:46.000000000 +0000
## -13,6 +13,10 ##
# The alias handling in here probably still sucks. -mdz
make_resolv_conf() {
+ # don't overwrite resolv.conf at RENEW time, since a VPN/PPTP tunnel may
+ # have updated it with remote DNS servers
+ [ "$reason" = "RENEW" ] && return
+
if [ -n "$new_domain_name" -o -n "$new_domain_name_servers" ]; then
# Find out whether we are going to mount / rw
exec 9>&0 </etc/fstab
This change to /sbin/dhcp-script stops DHCP client from overwriting /etc/resolv.conf when it renews its lease.

Resources