[Dnsmasq-discuss] Feature enhancement to rebind protection

[Eric Luehrsen]

Sorry, I must have been typing and dumb thumbed the touch bad at the
same time for odd results. Please see misplaced thread here:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q1/011922.html

[Eric Luehrsen]

Post by Eric Luehrsen
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q1/011922.htm
Some circumstances may be vulnerable to DNS rebinding attacks against
global IPv6 address. Through DHPCv6-PD the local network is a
uniquely identifying global subnet. This makes DNS rebinding to a
local machine on its global IPv6 as easy as traditional RFC1918. It
would be a good idea to eliminate any local network IP (RFC1918 or
otherwise) from global DNS responses... ...
Notable use case: if you actually have outward facing servers such as
http or vpn, then they should probably be on a unique subnet DMZ. If
excluding those interfaces in the rebind protection (maybe
=dhcp,[tag]), or running a separate dnsmasq instance for the subnet,
then such subnet would resolve globally and locally without filtering.

I would consider that a BUG (Actually it does exist as bug ... in AVM
Fritz!Boxes).
Public IPs are public IPs are public IPs.
One of the benefits of IPv6 is, that everybody incl. normal private
users, can finally get*public* IPs for all devices.
This effectively removes the need to use different IPs (and sometimes
even ports) for access to the very same ressources, depending on if
you are at home/at your office or outside.
That means I can put up a web server on 2001:db8:dead::beef, create an
AAAA record for it and use that new host name from inside as well as
from the outside of my LAN.
No need to use 192.168.blah.blubb:80 from inside and bla.dyn.com:88
from the outside ....
So actually I want my hostnames to resolve anywhere, also at home.

Hi Ziggy,

It would not be a Bug if it is an appropriately selectable option for
local administration to configure for their own security requirements.
Local administration may already want anonymity for their client
computers. IPv6 obscurity is a desired option implemented in RFC 4941
and discussed more in RFC 7721 for example. The general theme should be,
however, that local security is a decision to be left to the authority
over the respective network. Tools and options should be made available
to make the necessary choices possible.

I had already imagined your concerns, and attempted to address them the
use case. Externally facing servers should be placed in a DMZ, or that
is a specially configured subnet separate from the client access local
subnet. This includes special firewall, DHCP, DNS and other network
configuration rules. Also dnsmasq has a white list domain option for
rebinding protection "--rebind-domain-ok" which allows that your own
domain may resolve with local network address. This allows for one,
dnsmasq to work in chains through routed subnets in corporate
configuration. Yet still protected, "customer97134.ad-pirates.net"
cannot resolve to your local address.

Hopefully this clarifies the idea.

Eric

[Kurt H Maier]

Post by Eric Luehrsen
It would not be a Bug if it is an appropriately selectable option for
local administration to configure for their own security requirements.

[ snip ]

Post by Eric Luehrsen
I had already imagined your concerns, and attempted to address them the
use case. Externally facing servers should be placed in a DMZ, or that

I hope it's not your intent to claim that all software should support
"security requirements" and then proceed to mandate those security
requirements, but that's what it sounds like you're doing.

The "security requirements" you're discussing are side-effects of ipv4
address scarcity, so accustomed to which are securitists that they've
become cultural touchstones. That scarcity does not exist in the ipv6
space and it would probably be unwise to continue behaving as though it
did. It is not a matter of course to invent a DMZ or put specific
machines into one. In many organizations, every machine is "externally
facing"; this used to be called "being connected to the internet" and
is, I assure you, extremely survivable without DNS prestidigitation.

Please keep in mind that while there's nothing stopping you from doing
whatever you'd like with your computers, deliberately configuring DNS
servers to lie to each other wasn't ever really part of the design, and
it's not particularly polite to inflict the resulting complexity on the
rest of us.


khm

[Eric Luehrsen]

Hi Kurt,

I think that my one example use case may have thrown off my intent.

Post by Kurt H Maier

Post by Eric Luehrsen
It would not be a Bug if it is an appropriately selectable option

for local administration to configure for their own security requirements.

Post by Kurt H Maier
I hope it's not your intent to claim that all software should support

"security requirements" and then proceed to mandate those security
requirements, but that's what it sounds like you're doing.

I thought I was putting enough emphasis on the concept of choice and
option. Suggesting I might "mandate" such a thing seems a bit over the
top. Managing and filtering misuse and abuse of the global DNS for local
network resolution is a choice for local administration.

Post by Kurt H Maier
... deliberately configuring DNS  servers to lie to each other wasn't

ever really part of the design, and it's not particularly polite to
inflict the resulting complexity on the rest of us.

It is odd that you say this. The problem you mention is the neighborhood
DNS rebind attacks live in. The global DNS is  abused to put addresses
that belong to one organization under the domain-names of another
organization. Private address space is just a special case. The option I
am asking for fights this abuse. It protects "the rest of us" from this
problem. You should be able to use'--rebind-domain-ok' and
'--stop-dns-rebind' to filter these attempted hijacks. The former to
white list the domain you own. The later to prevent the rest of domains
from resolving with the network block you operate.

- Eric