What are the DNS servers listed in /etc/resolv.conf?
nameserver 10.139.1.1
nameserver 10.139.1.2
These are virtual IP addresses, how do they work?
I didn’t find this IPs in a local network, firewall, /etc/hosts, systemd-resolved, unbound. No info in the kicksecure wiki, anything. How does it work?
[user ~]% traceroute 10.139.1.1
...
27 * * *
28 * * *
29 * * *
30 * * *
Judging by tcpdump -i any port 53, if the tor is running, then the DNS is resolved via tor.
The /etc/resolv.conf file begins to be used if the tor@default systemd service is stopped.
I don’t know how that works.
[user ~]% sudo ip netns list
[user ~]%
[user ~]% nmcli device status
DEVICE TYPE STATE CONNECTION
lo loopback connected (externally) lo
XXXXX ethernet unmanaged --
XXXXX ethernet unmanaged --
[user ~]% sudo ip rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
[user ~]% sudo iptables-save
sudo: iptables-save: command not found
root@localhost:/home/user# nft list ruleset
...
nft: command not found
root@localhost:/home/user# resolvectl
...
resolvectl: command not found
This is beyond my comprehension. I wouldn’t say I like it when I can’t control the system, I’ll use it as a tor gateway, unlikely for my applications, but i’m not sure yet.
And it’s also odd that the tor config doesn’t have a DNSPort directive to resolve hosts IP addresses.
[user ~]% pgrep -af tor
8266 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
[user ~]% grep DNSPort /usr/share/tor/tor-service-defaults-torrc /etc/tor/torrc
zsh: exit 1 grep --color=auto DNSPort /usr/share/tor/tor-service-defaults-torrc
What are the DNS servers listed in
/etc/resolv.conf?
It’s an address within the range that’s assigned by the DHCP server.
You can control that range via dnsmasq.conf.
# Uncomment this to enable the integrated DHCP server, you need
# to supply the range of addresses available for lease and optionally
# a lease time. If you have more than one network, you will need to
# repeat this for each network on which you want to supply DHCP
# service.
#dhcp-range=192.168.0.50,192.168.0.150,12h
If you don’t want this at all, simply disable it and add a DNS server of your choosing. Just don’t forget to add dns=none to /etc/NetworkManager/NetworkManager.conf or /etc/resolv.conf will be overwritten by network-manager.
It’s an address within the range that’s assigned by the DHCP server.
At first, it’s not true. Be careful, the first my post is about unbound, the second is about network maganer. They both do not participate in dns resolve.
Second, my question is, why are the values in /etc/resolv.conf ignored by the system? And how DNS resolving works in kicksecure OS?
Just look up the source code.
It’s just network-manager-gnome plus some modifications. Otherwise same as Debian.
iptables is deprecated upstream. Use nftables equivalent or install iptables if you insist.
It’s not a control issue. You can install missing software as you like.
They aren’t. Why do you make the assumption? Comment out all entries or delete the file. In result, nslookup command will be broken.
Network Manager has a built-in DHCP client and can update /etc/resolv.conf.
Of course network-manager interferes with /etc/resolv.conf, that’s why I advised you to add dns=none to the NetworkManager.conf, in case you intended to manually change it.
I thought this was a KVM related case, that’s why I mentioned dnsmasq.
Either way, a bunch of different things update /etc/resolv.conf on Debian.
dhclient or network-manager are the usual culprits.
dhclient fix:
echo 'make_resolv_conf() { :; }' > /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone
chmod 755 /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone
last resort:
chattr +i /etc/resolv.conf
Here are No Intentional User Freedom Restrictions. Only sysadmin tasks.
why are the values in
/etc/resolv.confignored by the system?It’s not a control issue
Yes, you’re right. Everything is working fine today, i must have made a mistake and confused in my own hosts. /etc/resolv.conf works.
I’m still investigating the system. I am interested in the Kicksecure standard DNS address 10.139.1.1.
I use Kicksecure for KVM with CLI. Network manager is disabled, I use /etc/network/interfaces and /etc/resolv.conf files to configure network settings. I don’t use DHCP server and a DHCP local client.
[user ~]% sudo systemctl is-active NetworkManager
inactive
[user ~]% pgrep -af dhc
zsh: exit 1 pgrep -af dhc
The resolv.conf file contains standard Kicksecure DNS servers. These aren’t my servers, this is standard OS file:
[user ~]% cat /etc/resolv.conf
nameserver 10.139.1.1
nameserver 10.139.1.2
These IP addresses are likely part of a private network, as they fall within the range of private IP addresses defined by the Internet Engineering Task Force (IETF). Private IP addresses are not routable on the public internet and are typically used within local networks.
[user ~]% sudo tcpdump -i any port 53
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
15:06:30.294506 vmbr4 Out IP 192.168.4.50.45050 > 10.139.1.1.domain: 16119+ A? google.us. (27)
15:06:30.536671 vmbr4 In IP 10.139.1.1.domain > 192.168.4.50.45050: 45045 1/0/1 AAAA 2a00:1450:4017:810::2004 (66)
Private nameserver IP 10.139.1.1, 10.139.1.2 is not from my network, that is standard Kicksecure address, but somehow they works.
Maybe the answer is in wiki - DNS Security - Kicksecure, but I didn’t see it or understand it.
So you do use KVM, which means you probably have dnsmasq installed.
sudo apt list dnsmasq*
If that’s the case then these private IP addresses are probably from dnsmasq’s dhcp server. If the default network is used, then it’s usually in the range of 192.168.0/24. NAT like the one used in Whonix-External, uses 10.0.2.2
<network>
<name>Whonix-External</name>
<forward mode='nat'/>
<bridge name='virbr1' stp='on' delay='0'/>
<dns enable="no"/>
<ip address='10.0.2.2' netmask='255.255.255.0'/>
</network>
Are you using NAT with a 10.139.0/24 ip?
You can Search the Source Code. There is no mention of textual strings:
10.139.1.1
10.139.1.2
Therefore these IP addresses are not hardcoded in Kicksecure source code.
dnsmasq is not installed:
[user ~]% sudo apt list dnsmasq*
Listing... Done
dnsmasq-base-lua/stable 2.89-1 amd64
dnsmasq-base/stable 2.89-1 amd64
dnsmasq-utils/stable 2.89-1 amd64
dnsmasq/stable 2.89-1 all
[user ~]% pgrep -af dns ; pgrep -af dhc
zsh: exit 1 pgrep -af dns
zsh: exit 1 pgrep -af dhc
The NAT:
[user ~]% ip r
default via 192.168.4.40 dev vmbr4 onlink
192.168.4.0/24 dev vmbr4 proto kernel scope link src 192.168.4.50
192.168.5.0/24 dev vmbr5 proto kernel scope link src 192.168.5.50
[user ~]% ping 10.139.1.1
PING 10.139.1.1 (10.139.1.1) 56(84) bytes of data.
^C
--- 10.139.1.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9214ms
A packets to 10.139.1.1 are sent to an external network and domain names somehow resolved there.
Since resolv.conf works, i added the lines:
[user ~]% cat /etc/resolv.conf
#nameserver 10.139.1.1
#nameserver 10.139.1.2
nameserver 127.0.0.1
and line to /etc/tor/torrc:
DNSPort 127.0.0.1:53
For name-solving through tor like i wanted to.
On Linux, DNS libraries read the /etc/resolv.conf file. A DNS-resolving client such as Unbound is optional and not strictly required for basic DNS resolution.
Documented here just now:
Linux Default DNS Mechanism
wget https://www.kicksecure.com/download/libvirt/17.2.8.5/Kicksecure-CLI-17.2.8.5.Intel_AMD64.qcow2.libvirt.xz
tar -xvf Kicksecure-CLI-17.2.8.5.Intel_AMD64.qcow2.libvirt.xz
qemu-nbd -c /dev/nbd0 /home/user/Kicksecure-CLI-17.2.8.5.Intel_AMD64.qcow2
mount /dev/nbd0p3 /mnt/
root@host:~# cat /mnt/etc/resolv.conf
nameserver 10.139.1.1
nameserver 10.139.1.2
These DNS IP addresses are not in the source code, but now they are inside the qcow2 image.
These are leaking from the Qubes build VM into the image during the official build process for redistributable builds, which isn’t great, but also isn’t a big deal. It’s functional by accident rather than design.
grml-debootstrap copies /etc/resolv.conf.
[ -f “${MNTPOINT}”/etc/resolv.conf ] || cp ${VERBOSE:±v} /etc/resolv.conf “${MNTPOINT}”/etc/resolv.conf
Handling of /etc/resolv.conf during the build process is difficult. For details, see mentions of:
/etc/resolv.conf
in derivative-maker/help-steps/chroot-raw at master · Kicksecure/derivative-maker · GitHub.
The question is what would be a good default value for /etc/resolv.conf for Kicksecure KVM and Kicksecure VirtualBox?
Why mention Kicksecure VirtualBox? Because these are built at the same time to safe build time. The only difference is the image format conversion later during the build process (.qcow for KVM, .ova for VirtualBox).
So the VM image default /etc/resolv.conf needs to be compatible with both virtualizers.
It would be preferable to have an explicit default /etc/resolv.conf.
Should /etc/resolv.conf be managed by package? Probably not. A good default value written explicitly during the build process would be better. Otherwise, this file should later be user managed (not managed by a package).
That is, unless… Related:
Changes have been made. In 17.3.0.4 and above, the Kicksecure image will come without an /etc/resolv.conf file by default. It should get auto-generated at boot time by Network Manager.