[dns-operations] Massive DNS poisoning attacks in Brazil

[Paul Wouters]

On Wed, 3 Oct 2012, Andrew Sullivan wrote:

>> If the application gets a TLSA record, it must have passed DNSSEC
>> validation
>
> I see.  So your model is that the application asks for a TLSA record,
> and if it gets one then it can infer that the record also passed
> validation?  Hrm.  That's an interesting answer, and it hadn't
> occurred to me before that the application could rely on such an
> inference.  How can the application be sure the resolver is
> DNSSEC-aware?

You are right that is a little complicated. There are a few options,

- Trust the OS (not a very good option)
- Trust the AD bit (marginally better)
- Require localhost or specified (VPN protected) validators
   (i.e. like unbound+dnssec-trigger)

but the best option for now seems to be:

- Trust the OS for providing a root key
- Use whatever resolver the OS has configured, but do validation within
   the application (i.e. libunbound, lwres, libval)


In all scenarios, ignore TLSA records that are not protected by DNSSEC.

And hopefully one day, the validation can be moved out of the
applications and into glibc.

Augment these with obtaining dnssec chains via different transports,
feedomg these into the local resolver, which will validate the data
before adding it to the cache. These could be blobs on some standard
url (http://www.example.com/.dnssec.obj) that the owner of example.com
could tailor to their requirements (eg add the required lookups for
their advertisement provides, etc etc)

It would be great if we could also do more aggressive pre-fetching of
data too, so we could leave our house with preloaded DNS data for our
most commonly used lookups. Although the TTL=0 people think otherwise.

Paul