[PING] Re: DNSSEC support in stub-resolver

[Petr Spacek]

ping

On 30.4.2014 11:00, Petr Spacek wrote:
> On 28.4.2014 15:32, Ondřej Bílka wrote:
>> On Mon, Apr 28, 2014 at 01:56:37PM +0200, Petr Spacek wrote:
>>> Hello list,
>>>
>>> IETF mailing list dedicated to DNS-DANE hosted a lengthy discussion
>>> [0] about DNSSEC support in stub-resolvers.
>>>
>>> The questions are mostly:
>>> - How can we enable applications to use DNSSEC easily *and securely*?
>>> - How can we make DNSSEC related configuration system-wide? (I.e.
>>> the intent is to *avoid* adding application-specific switches to all
>>> applications dealing with DNS.)
>>>
>>>
>>> Configuration
>>> =============
>>> Basic assumption is that only administrator knows if recursive
>>> resolver and communication channel are trusted for DNSSEC validation
>>> or not.
>>> (E.g. Unbound vs. old dnsmasq ; IPSec vs. plain IP considerations.)
>>>
>>> This trust must be expressed somehow.
>>>
>>> If we consider machines using DHCP(d), it seems that we need to have
>>> per-resolver configuration.
>>>
>>> dhcpclient will mess with /etc/resolv.conf as usual, so global
>>> switch like "resolver-trusted=true" could be dangerous. Imagine a
>>> case where admin installed local resolver, turned it on and then
>>> moved to another network. Dhcpclient rewrote nameserver lines in
>>> /etc/resolv.conf. In that case the system is vulnerable!
>>>
>>>
>>> This reasoning leads to the question:
>>> How can we handle per-resolver options?
>>>
>>> Examples (in no particular order; all names are random):
>>>
>>> 1) Extend nameserver line in /etc/resolv.conf
>>> nameserver 127.0.0.1 trusted=true
>>> nameserver 192.0.2.1 # default is trusted=false
>>> I'm afraid that this will not work. I expect many programs parsing
>>> /etc/resolv.conf and expecting the "classical" format ...
>>>
>>>
>>> 2) Put per-resolver configuration to a separate (optional!) file
>>> E.g. /etc/resolv.ext (propose your own name)
>>> nameserver 127.0.0.1 trusted=true
>>> It seems a bit weird but maybe it is the cleanest option we have...
>>>
>>>
>>> 3) Extend option syntax in /etc/resolv.conf
>>> options trusted:127.0.0.1
>>> I have no idea how in/compatible this change can be.
>>>
>>>
>>> 4) Add a new verb to /etc/resolv.conf
>>> trusted-nameservers 127.0.0.1 192.0.2.1 2001:DB8::1234
>>>
>>>
>>> Which option do you like? Propose your own!
>>>
>> That is still vulnerable with determined attacker that would on
>> different network supply his resolver with same address and do MITM, so
>
> Yes, you are right. This example wasn't the best one... Note that nothing
> prevents you from modifying "trusted" list as you move between networks.
>
> I should be more explicit about expectations behind the proposal. The
> intention is to make it flexible enough to accommodate all possible use cases.
>
> The most important part is *adding an ability* to distrust recursive resolver.
> Nowadays every resolver is trusted and there is no option to distrust it.
>
> The expectation is that most common cases will be:
> - local validating resolver + configuration "trusted:127.0.0.1"
> or
> - no local validating resolver + configuration without any "trusted" statement
>
> My expectation is that "foreign" IP addresses will be used only in specialized
> cases. E.g.:
> - VM configured with IP address of it's hypervisor, i.e. case with two kernels
> communicating inside single physical machine
> or
> - Container (e.g. Docker) configured with IP of it's "host" (is it called
> hypervisor?), i.e. communication happens inside single kernel
>
>> you need some fingerprint verification.
>>
>> I would force using a trusted channel that could do authentification.
> I don't think that glibc is the right place to add dependency on
> SSH/SSL/IPSec/TSIG-CGA/any other particular "secure transport" technology.
>
> Also, this doesn't allow you to handle cases where admin is sure that plain IP
> transport is secure (i.e. VM/container). Consider use case with one physical
> machine running hundreds of containers with Apache inside...
>
> Reconfiguration can be handled by external tool/daemon. The daemon can detect
> presence of trusted channel and reconfigure the list of trusted resolvers as
> needed.
>
> I hope this explains the intent. Have a nice day!