[dns-operations] Massive DNS poisoning attacks in Brazil
marka at isc.org
Wed Oct 3 02:23:48 UTC 2012
In message <20121003011832.GC27102 at mx1.yitter.info>, Andrew Sullivan writes:
> On Tue, Oct 02, 2012 at 08:55:12PM -0400, Paul Wouters wrote:
> > The resolvers are broken for dnssec, other port 53 is blocked. You're
> > on TCP only. You will see many timeouts and failures and trust me you
> > will enable "insecure" within 5 minutes.
> Yep, I know. But my point (which I apparently stated so badly that it
> was impossible to understand) is that it _doesn't matter_ if you can
> get DNSSEC out at the edge, if the application can't tell.
Which is just a matter of adding a secure/insecure flag to struct
addrinfo which is defined to be extended. ai_flags is currently
undefined on return, but it could be used to return whether the
answer was secure or not. Application that care would check.
#define AI_SECURE <unused bit>
if (addrinfo->flags & AI_SECURE)
This is all about defining / extending APIs.
BIND 9 has shipped with a API for looking up arbitary rrsets for a
decade now, getrrsetbyname(), and it returns whether the rrset was
secure or not.
> > >know whether the DNSSEC validation worked before I start using the
> > >TLSA record.
> > Why? Are you going to ignore the TLSA record only when DNSSEC fails? In
> > which case, an attacker will just trigger that.
> No. Rather, if I'm going to consume the TLSA record, I need some sort
> of confidence that the record was obtained securely.
Code exists to do this.
> Andrew Sullivan
> ajs at anvilwalrusden.com
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations