...because the merged changes had been pushed to insert queue and
inserted after drop_journal!!

Daniel Kahn Gillmor authored 7 years ago and Daniel Salzman committed 7 years ago

At NDSS 2017's DNS privacy workshop, I presented an empirical study of
DNS padding policies:

https://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017/dns-privacy-workshop-2017-programme#session3

The slide deck is here:
https://dns.cmrg.net/ndss2017-dprive-empirical-DNS-traffic-size.pdf

The resulting recommendation from the research is that a simple
padding policy is relatively cheap and still protective of metadata
when DNS traffic is encrypted:

 * queries should be padded to a multiple of 128 octets
 * responses should be padded to a multiple of 468 octets

Since future research could propose even better policies, and future
DNS traffic characteristics might evolve, I've implemented this
recommendation as a new function in libknot:
knot_edns_default_padding_size()

This changeset also modifies kdig to use this padding policy by
default when doing queries over TLS, and defines +padding (with no
argument) as a kdig option that forces t...

Libor Peltan authored 7 years ago and Daniel Salzman committed 7 years ago

instead of hard-changing msgID in packet wire, which breaks msgID for the response, we just
set the original msgID when computing the tsig hash to check against

Libor Peltan authored 8 years ago and Daniel Salzman committed 8 years ago

...to display either real Knot running version, numbers of workers, or configure options

Libor Peltan authored 8 years ago and Daniel Salzman committed 8 years ago

Previously, the too-long-check for synthetized cname was only regarding
number of labels, but not overall length.