Describe the bug
The default configuration for dnsmasq is insecure and will bleed dns. I brought this up before and was told it works as intended and is not an issue.
To Reproduce
Start Minimega
vm config net 1000
vm config cdrom /root/tinycore.iso
vm config memory 256
vm launch kvm tiny
vm start tiny
tap create 1000 ip 1.0.0.1/24
dnsmasq start 1.0.0.1 1.0.0.2 1.0.0.254
This should launch a VM on mega_bridge vlan 1000 and assign an ip address in 1.0.0.0/24 from the dnsmasq service running on a tap in vlan 1000.
Now hop on the VM, open a terminal and ping google.com you'll see an ip address resolve, but the ping fails.
This is a problem. The only way it could know an ip address is if it somehow reached out to the internet and got a response back. This virtual network may seem isolated from the internet, but is clearly not.
Yes it is very bad practice to add this tap and not understand what it is doing. The better solution is to make sure to start dns using a vm or container in the experiment. But far too many people incorrectly assume dnsmasq is running in an isolated network because when they try and access the internet they see the internet fails.
Run tcpdump on the server and you'll see the domain traffic going outbound.
tcpdump -i eth0 port 53 -vv
Take a look at ps aux and you'll see dnsmasq is running with the -o option.
-o, --strict-order
By default, dnsmasq will send queries to any of the upstream servers it knows about and tries to favour servers that are known to be up. Setting this flag forces dnsmasq to try each query with each server strictly in the order they appear in /etc/resolv.conf
The default configuration of dnsmasq will resolve domains. This needs to be changed.
Expected behavior
We shouldn't use -o and -R should be enabled by default in dnsmasq.go. We should make a dnsmasq configure command to enable upstream resolving for when someone wants to use iptables forwarding.
Describe your environment
Describe the bug The default configuration for dnsmasq is insecure and will bleed dns. I brought this up before and was told it works as intended and is not an issue.
To Reproduce Start Minimega
This should launch a VM on mega_bridge vlan 1000 and assign an ip address in 1.0.0.0/24 from the dnsmasq service running on a tap in vlan 1000.
Now hop on the VM, open a terminal and
ping google.comyou'll see an ip address resolve, but the ping fails.This is a problem. The only way it could know an ip address is if it somehow reached out to the internet and got a response back. This virtual network may seem isolated from the internet, but is clearly not.
Yes it is very bad practice to add this tap and not understand what it is doing. The better solution is to make sure to start dns using a vm or container in the experiment. But far too many people incorrectly assume dnsmasq is running in an isolated network because when they try and access the internet they see the internet fails.
Run tcpdump on the server and you'll see the domain traffic going outbound.
Take a look at ps aux and you'll see dnsmasq is running with the
-ooption.From the man page
The default configuration of dnsmasq will resolve domains. This needs to be changed.
Expected behavior We shouldn't use -o and -R should be enabled by default in dnsmasq.go. We should make a
dnsmasq configurecommand to enable upstream resolving for when someone wants to use iptables forwarding.