[dns-operations] summary of recent vulnerabilities in DNS security.

[Colm MacCárthaigh]

Unfortunately I can't share data, but I have looked at a lot of it. In
general, I've seen TTLs to be very stable. Most ECMP is flow-hashed these
days and so as long as the path is stable, the TTLs should be identical. If
there's some kind of transition mid-datagram, the the TTLs may legitimately
mismatch, but those events seem to be very rare.

netfilter would be fine, but it'd be nice to not incur any state cost
beyond what the UDP re-assembly engine is keeping already.


On Wed, Jan 15, 2014 at 11:11 AM, Hannes Frederic Sowa <
hannes at stressinduktion.org> wrote:

> On Wed, Jan 15, 2014 at 10:42:21AM -0800, Colm MacCárthaigh wrote:
> > On Wed, Jan 15, 2014 at 5:06 AM, Hannes Frederic Sowa <
> > hannes at stressinduktion.org> wrote:
> > >
> > > Would it be of interest to get the state of fragmentation on incoming
> > > datagrams by e.g. ancillary data on recvmsg so resolvers could check if
> > > the incoming packet was fragmented then drop and retry if it was below
> > > a certain size?
> > >
> >
> > Yes, I'd appreciate that capability at least. It would also be nice to be
> > able to reject re-assembled datagrams whose fragments had different IP
> TTL
> > values.
>
> IIRC this was already under discussion and at that time was not considered
> beneficial (I don't remember where).
>
> For inclusion to the core stack we would need some hard facts that
> different TTLs on fragments are very unlikely on the internet (which
> I doubt).
>
> A netfilter match should be doable nonetheless.
>
> Thanks,
>
>   Hannes
>
>


-- 
Colm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140115/60097cbf/attachment.html>