►
From YouTube: IETF99-TUTORIAL-DNSPRIV-20170716-1230
Description
DNS Privacy
This talk discusses the various ways DNS queries are exposed to leakage and surveillance, what has been designed and implemented, and where we are going next.
DNS is one of the oldest pieces of protocol "Infrastructure" used in the Internet, and the most widely used. Confidentiality or privacy of users' DNS queries and responses was not included in its design. TheDNS PRIVate Exchange was created to design a mechanism to add a layer of confidentiality to DNS queries, without adversely impacting the existing DNS protocol or the user base.
Slides from the presentation:
https://datatracker.ietf.org/meeting/99/materials/slides-99-edu-sessh-dns-privacy-tutorial-00
DNSPRIV TUTORIAL at IETF99
2017/07/16 1230
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
So
to
start,
what
I'm
going
to
do
today
is
go
through
an
overview
of
why
DNS
privacy
is
important,
and
why
previously
on
the
Internet
in
general
is
important.
I
want
to
chart
the
huge
amount
of
progress.
That's
been
made
in
last
three
to
four
years
in
this
area
for
DNS
and
I
want
to
give
you
a
snapshot
of
where
we
are
now
and
what's
coming
up
in
this
area.
A
So
these
first
few
slides
are
ones
that
I
gratuitously
borrowed
from
Daniel
Kahn
Gilmore,
who
presented
this
with
me
in
Seoul
last
time,
but
wasn't
able
to
come
today.
So
I
will
try
and
channel
dkg
as
I
present.
This
one
of
the
arguments
wanted
to
make.
First
is:
why
does
privacy
on
the
internet
matter
at
all,
and
the
answer
is
that
it
can
be
used.
Surveillance
can
be
used
as
a
tool
for
social
control
in
ways
that
aren't
immediately
obvious.
Now.
A
That
means
processing
that
data
is
completely
feasible.
One
of
the
counter
arguments
about
worrying
about
surveillance
is
well
I'm.
A
law-abiding
citizen
I,
don't
do
anything
wrong,
I'm,
not
worried
about
being
surveilled
I'm,
really
not,
but
there's
been
some
really
interesting
research
to
show
that
just
the
fact
that
you
think
you're
being
surveilled
actually
changes
your
behavior.
A
So
the
experiments
involved
of
getting
pee
people
who
thought
that
behavior
wouldn't
change
and
valence
asking
them
questions,
some
of
which
their
answers
were
in
the
majority,
some
of
which
their
answers
were
in
the
minority
and
doing
it
into
two
sets
of
conditions.
One
way
you
told
them
they
were
being
spelled
and
one
way
you
told
them
they
weren't.
What
happened
was
that
bottom
line
you
can
see
for
the
answers
where
they
were
in
the
minority,
the
ones
that
thought
they're
under
surveillance
changed
their
answers.
A
So
what
we're
seeing
is
a
direct
if
unconscious
effect
of
the
act
of
mass
surveillance
of
people
in
the
bigger
picture.
We
know
the
whole
of
the
Internet
is
not
watertight.
It
leaks
information
through
a
variety
of
mechanisms.
It
can
be
traffic
analysis.
It
can
be
timing,
two
of
the
most
important
ways
it
leaks
today
are
through
the
DNS
which
I'll
talk
about
here,
but
also
through
the
fact
that
the
s
and
I
in
the
TLS
handshake
goes
in
the
clear.
A
So
one
set
of
arguments
that's
been
circling
around
for
quite
a
while
is
well
there's
no
point
in
securing
the
DNS.
If
the
s
and
I
is
still
going
to
go
clear
text,
but
one
thing
I
do
want
to
mention
is
that
all
the
work
that's
been
done
to
move
towards
private
DNS
and
last
three
to
four
years
is
now
changed
in
the
discussion
in
the
TLS
working
group
about
how
important
it
actually
is
to
encrypt
SNI.
A
And
although
it's
a
really
tough
intractable
problem
in
the
last
six
months,
there
has
been
a
big
move
towards
it,
even
though
it's
not
part
of
the
base
TLS
1.3
spec,
there
are
staff
efforts
to
now
try
to
do
that.
So
what
I'll
talk
about
today
and
what
I'll
focus
on
is
DNS,
but
what
we
need
to
be
doing
is
having
a
concerted
effort
to
fix
all
these
leaks
out
of
this
boat
in
order
to
make
the
internet
a
safer
place.
A
So
a
positive
history
of
privacy
considerations
in
the
IETF
work
actually
started
on
this
back
in
march
2011,
when
the
IAB
worked
on
a
document
about
privacy
considerations,
internet
protocols
now
you're
all
probably
familiar
with
when
you
read
Narsee,
there's
a
section
at
the
end.
That
says
security
considerations
and
that's
been
there
for
a
long
time.
The
goal
of
this
document
was
to
create
a
foundation
for
adding
a
privacy
considerations
section
at
the
end
of
every
document,
to
show
that
the
development
of
that
protocol
had
taken
privacy
and
into
account
now
being
the
ITF.
A
It
took
a
couple
years
to
get
it
to
be
an
RFC
and
the
month
before
this
document
was
published.
A
chap
you
may
have
heard
and
heard
of
called
Edward
Snowden
revealed
what
the
NSA
had
actually
been
up
to
in
terms
of
mass
surveillance.
So
it
was
an
interesting
timing,
because
what
was
in
some
ways
a
rather
theoretical
document,
suddenly
became
incredibly
real
and
incredibly
pertinent,
and
in
fact
you
probably
know
that,
in
response
to
Snowden
revelations,
the
ITF
came
back.
A
The
second
document,
with
a
title
that
pervasive
monitoring,
is
an
attack
stating
that
that
attack
is
on
both
organizations
and
Internet
users
as
individuals.
That
document
went
one
step
further
and
what
it
actually
said
is
from
this
point
on
and
pervasive
monitoring
needs
to
be
mitigated
in
the
design
of
new
protocols.
So
this
is
a
change
of
stance
from
the
ITF
and
recognizing
that
this
really
was
an
issue
and
that
moving
forward
all
protocols
had
to
have
this
as
part
of
their
design.
A
So
back
when
this
was
all
happening
around
2013
I
want
to
give
you
a
snapshot
of
the
state
of
Dennis
previously
at
that
time,
and
that
really
to
do
that
properly,
you
actually
need
to
go
back
even
further
back
to
when
Dennis
was
originally
developed.
The
aura
sees
four
dienes
were
published
30
years
ago.
So
if
you
go
mentally
back
in
your
time
machine,
you
know
your
DeLorean,
your
TARDIS,
your
whatever
you
want
and
think
about
what
people
imagine
the
internet
was
going
to
be
30
years
ago.
A
They
had
absolutely
no
idea
of
what
it
would
become
today,
so
the
design
goes
involved
in
the
original
Dennis
specs
were
primarily
availability,
redundancy
and
speed,
and
those
are
the
key
things
that
mattered
additionally,
DNS
in
privacy
terms
is
something
that's
called
an
enabler:
it's
not
a
service
in
itself.
It
enables
you
to
access
other
services,
so
it's
kind
of
frozen
neglected
in
this
sphere
because
it
wasn't
seen
as
a
direct
service.
A
So,
as
you
well
know,
the
standards
for
DNS
originally
said
use
UDP
and
they
use
TCP
only
as
a
fallback
mechanism
when
responses
were
large.
So
as
a
result
for
the
past
30
years,
all
DNS
queries
have
gone
clear
text
over
the
wire,
so
this
became
very
evident
how
easy
we
were
making
it
for
organizations
to
do
mass
surveillance
because
they
didn't
have
to
go
and
talk
to
operators.
All
they
had
to
do
was
sniff
the
wire
and
they
could
see
everything
that
was
going
on
now.
A
Additionally,
one
of
the
things
about
the
DNS
is
that
there's
been
a
long-held
perception
that
the
DNS
is
public
public
data,
in
that
it
doesn't
hold
anything
personal.
It's
not
sensitive,
and
so
there
are
lots
of
questions
about.
Why
would
we
bother
to
encrypt
it
it
just
it
doesn't
fit
into
that
sphere
and
I'll
come
back
to
that
later.
A
A
So
this
was
done
because
it's
slightly
simplified
the
devant,
the
design,
but
it's
quite
some
simple
symptomatic
of
the
way
the
DNS
just
didn't
put
previously,
first
in
any
of
its
design
considerations,
so
things
got
a
lot
worse
a
few
years
ago
with
the
addition
of
something
called
eating
a
zero
into
the
DNS
protocol.
Now
this
was
actually
a
much-needed
extension,
because
inside
DNS
queries
and
responses,
you
really
only
had
DNS
data.
A
This
was
an
extension
mechanism
which
allowed
a
flexible
data
to
be
added
onto
the
end
of
a
Dennis
packet
to
do
really
important
things
like
signaling
the
MTU
path,
to
figure
out
when
you
needed
to
fall
back
to
TCP
or
signaling
server
capabilities,
something
that's
really
rather
lacking
in
the
DNS.
However,
because
this
was
so
flexible,
it
meant
that
it
could
also
be
used
to
do
other
things,
for
example,
embed
information
about
end
users
into
that
DNS
query.
There
are
two
examples
of
how
this
has
been
used.
A
Both
of
them
were
done
from
the
viewpoint
of
somebody,
an
operator
wanting
to
provide
better
service
to
their
end
customers,
and
this
provided
a
really
natural
way
to
do
it.
At
the
time,
the
problem
was
really
with
the
the
implementation.
So
two
examples
of
this
is
one
is
how
some
ISPs
chose
to
implement
a
parental
filtering,
and
another
mechanism
is
the
way
CD
ends
do
geolocation.
A
So
in
the
first
case,
the
parental
filtering.
What
happens
is
you
want
to
set
up
some
rules
and
you
want
some
DNS
queries
to
be
blocked
now?
What
you
might
think
is
that
your
ISP,
who
gave
you
your
home
router,
would
put
the
logic
in
the
home
router
and
then
everything
is
encapsulated
within
your
home
network
turns
out
not
everybody
implemented
in
that
way.
In
fact,
quite
a
lot
of
people
didn't
what
they
did
was
they
put
all
the
logic
in
the
recursive
server,
which
meant
to
make
this
work.
A
They
had
to
embed
in
every
single
DNS
query
going
from
your
home
rooted
a
recursive,
some
piece
of
identifying
information
about
who
was
doing
that
query.
Now,
if
you
are
lucky,
they
used
some
sort
of
hash
of
an
identifier,
so
it
obscured
you
specifically,
but
it
allowed
identification
of
multiple
individuals
behind
a
single
Rooter.
A
If
you
are
unlucky,
they
did
something
like
put
the
MAC
address
as
the
machine
that
was
doing
the
lookup
in
there
with
some
other
information,
the
worst
cases
I've
seen,
are
usernames
being
propped
in
this
little
extension
and
remember,
this
is
going
clear
text
over
the
wire,
and
this
was
all
done
with
non-standard
extensions.
So
this
is
where
a
noble
piece
of
protocol
design
allowed
for
a
misguided
use
of
part
of
the
protocol.
A
In
the
CDN
case,
this
is
between
the
recursive
and
the
authoritative.
So
it's
not
revealing
as
much
information,
but
the
idea
here
was
that,
if
an
authoritative
that
was
going
to
save
you
content
knew
something
about
the
geolocation
of
the
user.
That
originated
the
query.
Then
the
answer
could
be
customized
so
that
it
directed
that
user
to
the
nearest
geographically
located
server.
So
they
got
the
fastest
service.
They
could
I
mean
nobody
likes
their
cat
videos
buffering
right.
So
this
is
a
great
idea.
A
It's
wonderful
get
go
to
the
server
down
the
road,
not
the
one
on
the
other
side
of
the
world.
So
again,
it
seems
a
natural
fit
to
tag
a
subnet
client
subnet
into
the
e
dns
zero.
But
again
this
is
just
compounding
the
problem
of
data
leakage
up
on
that
recursive
to
authoritative
lag.
So
when
you
use
the
dns
from
home,
you
might
think
your
queries.
It
really
rather
anonymized,
but
the
reality
is
you're
behind
in
that
and
you
don't
have
anonymity.
There
are
many
cases
where
individuals
are
being
fingerprinted.
A
Similarly,
even
right
up
to
the
authoritative
service
and
the
DNS
information
about
our
activity
is
being
leaked
so
and
remember,
what's
going
over
that
link?
It's
information
about.
You
know
where
you
go.
What
sites
you
go
to
what
you
do
when
you've
got
bored
all
sorts
of
personal
information
is
going
clear-text,
think
about
it.
Pretty
much!
Every
activity
on
the
internet
starts
with
a
DNS
lookup,
so
it
really
isn't
just
for
names.
A
Try
it
fire
up,
TCP
dump
and
wash
are
looking
at
port
53
and
just
watch
how
much
traffic
goes
out
of
your
machine
as
you
just
surf
around
and
send
email,
because
every
time
you
send
an
email,
you
need
to
get
an
MX
record.
So
that
reveals
the
domains,
email
domains
of
the
people
that
you're
emailing
every
time
you
go
to
a
service,
you
do
an
SOP
lookups.
This
reveals
the
variety
of
services
you
use
open.
A
Pgp
key
is
a
nice
standard
where
you
can
secure
email
with
Dane,
but
that
reveals
the
entire
email
address
of
the
contact
you
want
to
email,
and
the
problem
here
is:
this
is
only
going
to
get
worse.
People
are
putting
more
and
more
in
the
DNS,
we're
not
in
any
sort
of
scheme
where
we're
trimming
what
goes
in
the
DNS
it's
it's.
Some
advantages
have
been
seen
in
lots
of
places.
A
So
that's
really
the
picture
we're
talking
about
what
goes
over
the
wire
there's
an
entirely
separate
concern
about
what
happens
when
it
hits
the
unser
VORs.
Of
course.
So
most
people
here
use
an
ISP
and
you
have
to
ask
yourself
who
has
access
to
the
data
that
your
ISP
has?
Is
it
strictly
the
ISP?
Is
it
the
government
of
your
country?
Is
it
security
services?
Who
else
is
it
also?
Who
does
your
ISP
share
your
data
with
and
under
what
terms
and
conditions?
A
A
Of
course,
all
these
concerns
change,
as
you
move
from
your
home,
where
you're
using
your
ISP
to
your
work,
where
you're
in
an
enterprise
situation
to
a
coffee
shop,
to
a
hotel
and
in
everyone
all
considers
all
the
privacy
considerations
change,
and
that
known
not
only
applies
to
the
recursive
but
as
I
says
also
up
to
the
authoritative,
because
the
data
leakage
goes
that
far
along
the
path
so
what's
happening
in
the
DNS.
Is
we're
leaking
metadata?
A
A
The
whole
range
of
things
that
create
a
fingerprint
of
a
human
being
on
the
Internet
so
what's
been
shown
is
that,
just
by
looking
at
DNS
queries
you
can
fingerprint
injured
vigils
and
you
can
read
n
tafolla
as
they
move
across
networks,
because
the
DNS
queries
are
so
characteristic
that
you
can
figure
out
who
it
is
that's
moving
around.
On
top
of
this,
there
was
some
other
interesting
research
that
said:
okay,
that's
all
well
and
good.
Let's
encrypt
recursive
disturb
it
turns
out.
A
Dns
traffic
is
so
characteristic
in
terms
of
its
timing
and
size
that
even
less
alone
isn't
enough,
and
if
you
have
an
observer,
who
has
enough
visibility
downstream
of
recursive
to
see
encrypted
traffic
and
upstream,
to
see
the
clear
text
traffic
going
to
an
authoritative,
you
can
still
correlate
the
activity
and
you
can
still
identify
individuals
within
those
traffic
patterns.
So
we
need
to
do
more
than
just
simply
encrypt
and,
as
I
mentioned,
operators
can
also
see
your
queries
and
log
them.
So
if
you
were
thinking
your
DNS
behavior
really
didn't
reveal
anything
about
you.
A
Well
then,
Toto
were
really
not
in
Kansas
anymore.
There's
lots
going
on
here
and
it's
really
really
really
underreported
think
about
the
last
time
you
read
a
magazine
article
talking
about
how
to
secure
yourself
on
the
internet
that
mentioned
DNS.
They
talk
about
encrypting,
a
phone
encrypting,
your
disk,
using
HTTP.
If
you
can
going
to
tour
all
these
things,
but
I
haven't
seen
one
article
yet
that
puts
DNS
within
that
overall
perspective.
A
A
Okay,
so
just
to
start
the
story
by
going
back
to
2013
and
talk
about
what
were
the
privacy
options
at
that
time.
Well,
there
were
no
standards
for
how
to
do
dns
previously
at
that
time,
at
all,
there
are
a
few
protocols
have
been
developed
and
deployed,
but
some
of
them
come
to
the
ITF
installed.
Some
of
them
haven't
even
gotten
here.
The
main
ones
were
DNS
curve,
which
is
really
designed
for
the
recursive
to
authoritative
communication
and
deana
script,
which
was
stub
to
recursive
and
Dena
script
is
still
around.
A
Today
there
are
implementations
it
recent
got
picked
up
by
the
Yandex
browser,
so
it
is
around.
But
one
thing
to
remember
is
these:
were
developed
really
as
anti-spoofing
and
anti-ddos
devices
they
weren't
designed
with
per
se
as
the
primary
design
goal
here,
and
you
kind
of
get
privacy
as
a
by-product
from
these
things
and
the
unbound
recursive
server
also
implemented
DNS
over
TLS
in
2014.
So
that's
been
around
a
while,
but
again
this
was
just
sort
of
a
side
effect.
A
A
That's
where
the
IETF
came
in
and
the
deep
rival
working
group,
so
deep
rive
was
formed
in
2014
and
clearly
you
can
see
it
had
a
really
big
job
in
front
of
it.
So
the
first
thing
it
did
was
trying
to
narrow
down
its
Charter,
and
the
original
decision
was
that
it
should
focus
just
on
that
stub
to
a
cursor
step,
and
you
might
say
well
why
not
have
multiple
avenues
of
protocol
development
and
the
answer
was:
let's
not
try
and
boil
the
ocean.
This
is
a
really
tough
thing
to
solve.
A
The
stub
to
recursive
is
where
most
of
the
information
is
revealed.
So
let's
target
that
first
and
then,
let's
use
what
we
learned
doing
that
to
move
on
to
the
recursive
to
authoritative,
there's
also
some
differences
in
trying
to
solve
those
problems,
primarily
in
terms
of
authentication.
So
as
an
end
user,
somebody
with
the
stub
resolver
on
their
machines,
you
tend
to
have
a
relationship
with
a
few
recursive
result
with,
so
it
could
be
tens.
A
You
know
between
work
and
everywhere
you
move,
but
in
most
of
those
environments
you
actively
choose
to
use
that
recursive
in
a
coffee
shop.
You
you
actually
choose
to
join
the
network
with
all
its
faults,
the
situation
for
recursive
resolver,
it's
quite
different.
It
has
to
go
to
whatever
authoritative
it
needs
to
to
resolve
that
query,
so
it
essentially
has
no
control
to
the
set
of
up
streams
that
it
has
to
talk
to,
and
that
makes
creating
an
authentication
mechanism
much
much
harder
than
it
does
in
the
stubs
recursive
case.
A
A
Is
it
tackles
that
question
of
the
alleged
public
nature
of
the
DNS
and
what
it
says
is
it's
correct
to
say
that
the
data
in
the
DNS
is
public,
but
individuals,
transactions
in
the
DNS
are
not
and
should
not
be
public,
and
the
analogy
it
uses
here
is
well.
The
content
of
the
websites
for
alcoholics
Anonymous
is
public.
It's
a
public
website.
The
fact
that
you
as
an
individual,
visited
that
website
is
not
public
data
and
it
shouldn't
be
the
next
question
the
working
group
had
to
answer.
A
Having
tried
to
scope
out
the
problem
was
there
was
agreement
to
encrypt
the
stub
to
recursive?
How
do
we
do
it?
The
working
group
spent
quite
a
lot
of
time
churning
over
a
variety
of
options,
not
just
these
ones.
Here
they
looked
initially.
It
starts
here
last
because
that
could
be
done
on
port
53
for
various
reasons.
A
So
the
discussion
went
a
bit
back
and
forth
and
decision
was:
let's
not
go
down
this
to
protocol
route
again,
let's
just
start
with
tear
less
and
get
that
right
and
and
choose
a
single
protocol.
So
what
emerge
from
the
working
group
was
that
DNS
over
TLS
became
a
standard
and
DTLS
became
standard
with
experimental
category.
A
So
choosing
your
encryption
protocol
is
one
part
of
the
process.
There's
another
to-do
list.
If
you're
gonna
fill
out
this
picture
one
is
you
actually
have
to
actually
get
the
new
port
you
wanted,
the
other
one.
Is
you
have
to
address
the
fact
that
historically
and
TCP,
implementations
in
DNS
servers
absolutely
sucked
because
they
were
only
used
as
this
once
in
a
while
fallback
mechanism?
No
attention
was
really
paid
to
doing
them
properly
and
if
you're
going
to
move
a
step
further
and
use
tear
less,
then
you
have
to
address
that.
A
There's
also
a
new
problem
for
DNS
in
terms
of
authentication,
which
is
bootstrapping.
Of
course,
when
you
go
to
a
website,
you
know
the
name
of
the
site
you're
going
to
with
DNS.
When
you
go
to
your
cursive
server,
you
typically
only
have
the
IP
address
of
it,
so
that
doesn't
give
you
a
natural
mechanism
to
do
authentication.
So
we
have
to
find
some
solutions
to
that
and,
as
I
mentioned
before,
we
still
have
to
deal
with
traffic
analysis.
A
A
A
The
connection
went
straight
back
to
UDP,
so
using
that
kind
of
implementation
was
just
unfeasible,
there
was
a
really
poor
perception
of
DNA
of
TLS
as
well
so
TCP,
because
all
the
performance
tools
that
were
used
were
based
around
this
one-shot
mechanism,
so
they
made
TCP
inherently
look
or
you
know
at
least
an
order
of
magnitude.
Worse
than
UDP
DNS
servers
had
really
really
basic
capabilities.
They
often
were
hard-coded
hard-coded
to
only
have
20
connections
and
have
like
a
one-minute
fixed
timeout,
and
that
was
it
no
other
defense
mechanisms
in
there.
B
A
Yeah,
that's
true
so
and
I
mean
in
general.
The
server
operators
didn't
want
to
do
TCP,
so
they
wouldn't
tuned
for
it.
They
have
no,
they
treated
it
as
a
second-class
transport.
I
think
it's
fair
to
say
so.
To
fix
this
part
that
really
had
to
revisit
the
specs.
So
the
first
thing
we
had
to
recognize
is
that
the
DNS
people
are
not
the
first
people
to
try
and
do
TLS.
There's
a
bunch
of
people
out
they've
been
doing
it
for
ages,
so
we
should
just
piggyback
on
what
they've
done.
A
So
latency
is
an
enormous
concern
in
DNS,
so
connections
set
up.
We
needed
to
be
optimizing.
What
we
did
waving
all
the
available
techniques,
so
we
needed
to
be
using
TCP
fast,
open.
We
needed
to
be
using
TLS
session
resumption
and,
of
course,
we
started
rubbing
our
hands
when
TLS
1.3
started
coming
over
the
horizon,
because
of
course
that
was
targeting
things
like
0,
RT,
T
and
1
RT
T
resumption.
So
that
looks
good.
A
We
also
had
to
directly
tackle
the
DNS
standards,
so
there
was
an
RFC
in
2010,
which
was
actually
the
first
time
it
was
mandatory
to
implement
TCP
for
DNS.
Before
that
it'd
been
sort
of
fuzzy
option.
That
RFC
was
based
in
2016
and
in
that
it
basically
said:
don't
do
one
shot
TCP.
If
you're
gonna
do
TCP,
do
it
properly
open
a
connection
pipeline?
Your
queries
over
it
as
a
server.
When
you
receive
it,
you
should
process
all
your
queries
concurrently
and
then
you
can
send
them
back
in
whatever
order.
A
A
We
also
developed
a
signaling
mechanism
so
that
clients
could
signal
to
servers
that
they
wanted
to
keep
connections
open
and
because
that
was
completely
absent
from
from
DNS
signaling
and,
of
course,
as
I
mentioned
for
this
loads,
that
we
can
learn
HTTP
world
in
terms
of
just
generally
improving
what
servers
did
here.
So
this
is,
for
example,
one
of
the
simple
things
that
got
fixed
in
that
spec,
which
is
that
traditionally
service
when
they
were
listening
on
TCP,
they
picks
a
query
of
the
connection
resolved.
A
It
sent
it
back
and
only
then
did
they
look
for
the
next
one
and,
of
course
resolving
that
query
could
take
a
long
time
if
they
didn't
have
any
passing
cash.
So
the
simple
fix
was
to
tell
service.
No,
you
need
to
be
doing
this
more
intelligently.
Pick
pick
the
queries
up
and
process
them
concurrently
and
that's
going
to
take
a
whole
RTT
off
the
clients
time
and
the
goal
here
was
actually
to
work
towards
trying
to
get
performance
on
a
par
with
UDP
by
combining
all
these
changes
to
the
protocol
and
persistent
connections.
A
So
to
move
on
to
this
question
of
authentication.
Clearly,
we
can't
go
from
where
we
are
in
a
single
leap
to
everybody's
using
UDP.
Today,
everybody's
going
to
use
authenticated
TLS
tomorrow,
that's
just
not
going
to
happen.
So
what
the
draft
that's
currently
going
through
deeper
I've
suggests
is
being
able
to
do
authentication
in
two
ways
and
they're
called
usage
profiles,
so
one
is
called
strict,
which
is,
you
must
have
both
an
encrypted
and
authenticated
connection
to
your
server
or
you
just
don't
do
dns.
A
So
this
is
the
sort
of
purist
approach,
but
it's
also
the
protectionist
approach.
If
you
are
somewhere
where
monitoring
for
DNS
queries
could
imperil
you,
then
you
want
to
have
you
want
to
be
able
to
have
a
level
of
security
that
they're
just
not
going
to
be
monitored?
So
strict
is
where
you
would
go
there
and
we
hope
that
this
will
become
the
default
longer
term
as
we
move
towards
it,
though,
we
need
a
pragmatic
solution
and
that's
called
opportunistic.
So
in
opportunistic.
A
The
other
problem
is
that
you
need
additional
information
if
you're
going
to
authenticate
your
Dennis
server,
because
typically
a
client
only
has
an
IP
address.
So
the
current
draft
proposes
two
ways
to
do
this.
You
can
either
configure
an
authentication
name
into
your
client,
which
in
some
ways
is
easier
because
it
can
be
human
readable,
fairly,
easy
to
check.
A
The
other
mechanism
is
to
use
an
SP
care
pen
set
so
again
we're
borrowing
from
what's
already
been
done
in
HTTP,
so
that
can
be
a
little
harder
because
it's
not
human
readable,
but
it
can
be
a
little
more
flexible
in
some
ways
to
allow
for
key
rollover.
But
of
course
you
might
be
said
again,
these
are
the
DNS
folks.
These
are
the
folks
who
dreamt
up
this
dang
thing
and
keep
telling
us
all
of
us
to
stay
in
for
authentication
so
shouldn't.
We,
the
desk
people,
really
be
drinking
our
own
champagne
here.
A
Well,
the
draft
does
also
go
through
the
details
of
how
to
do
authentication
via
Dane.
You
still
need
an
authentication
domain
name
configured
into
your
client
to
start
that,
but
once
you
have
it,
you
can
do
Dane
to
get
the
queries.
In
fact,
all
this
work
prompted
a
new
solution
for
T
less
in
terms
of
Dane
called
the
TLS
T
in
a
sec
chain.
Extension
and
I'll
just
walk
you
through
that.
So
this
is
how
a
traditionally
do
Dane
as
a
DNS
client.
A
So
you
would
have
some
configuration
information
that
told
you
where
your
cursor
was
and
what
its
authentication
name
was.
As
a
client
is
add
in
a
sec,
validating
client,
you
would
go
off
and
opportunistically
because
that's
all
you
have
available
at
this
bootstrap
time
do
lookups
ordain
records.
Then
you
get
the
Dane
records
back
and
you're
ready
to
make
the
connection
you
do
a
traditional
TLS
connection,
getting
the
certificate
or
key
information
from
the
server
validator
against
the
Dane
records
and
you're
good
to
go.
A
The
new
proposal,
that's
still
going
through
at
the
TLS
working
group,
is
based
on
this
on
the
recognition
that
hang
on
this
thing,
I'm
talking
to
you
and
I'm
trying
to
authenticate
it's
a
DNS
server.
It
knows
about
Dane
so
rather
than
me
going
getting
the
records
is
a
query
I'll,
let
it
do
the
work.
So
you
start
from
the
same
position
in
terms
of
configuration.
However,
this
time
it's
the
server
that
makes
sure
it
has
its
own
Dane
records.
What
that
means
is
with
the
new
extension.
A
The
client
can
signal
in
the
client
hello,
that
it
is
capable
of
validating
day
that
receives
in
the
TLS
handshake,
knowing
that
the
server
can
send
back
all
the
dane
records
necessary.
That's
the
entire
chain
for
the
client
as
Adina
SEC
validating
client
to
do
the
work
during
the
TLS
handshake
decide
that
it
can
all
Center
Kate
and
again
it's
good
to
go
to
in
a
service.
A
A
A
Our
queries
I'm
not
going
to
go
into
this
in
too
much
detail,
but
this
basically
took
number
four
under
to
do
list
and
I
quite
like
this,
because
what
would
what
happened
here
was
that
EDS
zero
option
that
was
being
used
in
some
cases
to
expose
user
data
has
kind
of
been
taken
back
from
the
dark
side
and
we're
actually
using
it
to
put
up
adding
in
exactly
that
location.
So
we
can
obfuscate
the
sizes
of
DNS
traffic.
A
We
have
a
experimental
RFC
for
how
to
do
DNS,
David
DTLS,
and
we
have
a
draft
describing
all
these
authentication
mechanisms
which
is
in
is
G
last
call
at
the
moment.
So,
looking
back
for
three
years,
that's
not
by
going
for
a
working
group.
Okay,
we
haven't
solved
all
the
problems,
but
we've
come
a
long
way
and
what
the
working
group
now
is
looking
towards
is
tackling
that
recursive
to
authoritative
step.
A
There
is
an
expired
ID
that
proposed
a
few
options
that
is
probably
going
to
be
revived
and
a
slightly
different
form.
Narrowing
down
the
set
of
options
to
look
at
the
working
group
is
probably
going
to
consider
reach
our
Turing
and
also
one
of
the
things
they
want
to
use
to
feed
into.
That
is.
Data
on
what's
happened
today
on
recursive
to
stub
link
in
terms
of
implementation
and
deployment
of
detail
s,
and
so
there's
still
a
bunch
of
work
to
do
but
we're
getting
there.
A
A
If
somebody
wants
to
block
your
dns
you
encrypted
dns,
they
can
just
block
poor
8:53,
whereas
if
you're
using
Dennis
type
of
HTTP,
there
are
mechanisms,
waking
them
run
over
443
and
something
would
have
to
block
that
port
and
all
your
HTTP
access
to
defeat
you
getting
encrypted
DNS
and
a
good
four
years
ago,
rather
under
the
radar
and
with
a
proprietary
implementation,
Google
published
a
DNS
over
HTTP
API.
If
you
have
the
slides
as
a
link
to
the
service
there,
you
can
go
and
look
at
it.
There's
a
nice
little
gooey.
A
You
can
play
with
it.
It
was
targeted
at
applications
that
wanted
to
do
very
lightweight,
DNS
lookups,
and
so
it's
interesting.
It's
different
it
to
my
knowledge.
It
never
progressed
through
the
standard
side.
What
did
progress
through
the
standard,
size
and
and
actually
there's
been
a
lot
of
flux
in
the
drafts
here
quite
a
while
ago,
those
proposal
to
do
DNS
over
HTTP
in
Y
format-
and
this
is
essentially
a
tunneling
mechanism,
so
you're
not
changing
anything
about
HTTP
you're,
just
embedding
wire
format
DNS
in
it.
This
draft
is
still
active.
A
So
what
this
essentially
means
you're
doing
is
mixing
DNS
queries
and
HTTP
queries
on
one
connection.
So
again,
this
gives
you
the
ability
to
do
a
couple
of
things:
hydrogenous
queries,
but
also
to
get
your
DNS
answers
from
the
server
that
you're
currently
connected
to,
and
this
has
a
lot
of
interesting
propositions
and
so
having
a
look
at
that
and
going
to
the
working
group
as
well
is
worth
considering
something
that's
happened
recently,
but
it's
really
in
a
very,
very
embryonic
State.
It's
talking
about
doing
DNS
over
quick.
A
How
many
folks
in
the
room
are
familiar
with
quick.
Most
of
you,
I
think.
Yes,
so
quick
set
developing
protocol,
it
came
from
Google
it's
being
used
in
the
wild
in
its
experimental
form.
The
things
that
make
it
attractive
for
doing
DNS
are
that,
even
though
it
runs
over
UDP,
it's
reliable.
It
has
all
those
mechanisms
built
in
it's
also
low
latency.
So
it
should
take
a
lot.
A
The
performance
boxes
for
DNS
the
things
that
it
also
gives
you
over
doing
plain
UDP
are
you
have
increased
source,
address
validation
over
doing
UDP,
which
is
very
important
in
DDoS
mitigation
14s,
and
it
also
doesn't
suffer
from
the
problem
of
hitting
an
MTU
limit
and
needing
a
fallback
to
a
second
transport.
So
this
can
be
a
standalone
solution
and,
of
course,
the
killer
feature
for
privacy.
Is
that
it's
encrypted?
A
Do
because
that's
the
question
so
I
make
sure
I
read
mine,
but
typically
it's
not
something
you
do
life's
too
sure
right,
except
with
changes
in
legislation,
for
example
the
rollback
of
net
neutrality
in
the
states
that
landscape
could
really
really
change
in
the
next
few
years.
It
could
become
normal
for
operators
to
sell
your
DNS
data,
so
there
needs
to
be
attention
paid
to
things
like
government
policy.
I
live
in
the
UK.
We
have
the
snoopers
charter
that
gives
my
government
access
to
my
browsing
data,
whatever
that
means
legally,
which
I
don't
know
so.
A
There's
government
policy
and
this
government
practice
that
we
need
to
be
considering
what
would
be
great
is
increased
transparency
from
providers.
What
I
would
like
to
see
is
that
you
get
privacy
by
default
and
you
can
opt
in
to
share
your
data
as
long
as
it
is
explained
correctly
what
you're
buying
into
there.
We
also
need
to
be
paying
attention
to
cases
what
operators
say
they
share
data.
It's
been
anonymized
to
be
sure
that
is
being
anonymized
correctly,
because
a
lot
of
that
is
done
in
and
rather
ad
hoc
fashion.
A
Today
and
a
lot
of
days
to
get
shared
for
things
like
research
through
databases
like
passive
dns
and
again,
we
need
to
be
ensuring
that
that's
done
in
conformance
with
proper
data
anonymity.
Now,
a
lot
of
this
work
is
probably
well
outside
the
scope
of
the
IETF
and
it's
not
really
technical
solutions
in
all
the
cases.
A
But
without
solutions
to
this
work
going
hand-in-hand
with
encryption
on
the
wire,
we
won't
have
the
full
picture
available
so
to
come
back
to
that
matrix
I
had
earlier
on
and
talk
about
which
parts
of
it
we
can
mitigate
with
the
work
we've
done
to
date.
Well,
we
can
encrypt
stuff
to
recursive
to
protect
against
passive
monitoring.
A
I'm
going
to
very
very
briefly
talk
about
service
discovery
because
it
is
DNS,
but
a
lot
of
people
don't
realize
it's
DNS,
so
service
discovery
is
a
mechanism.
That's
used
to
discover
services
and
very
often
it's
done
on
local
networks,
but
there's
nothing
that
limits
it
to
a
local
network
and
very
often
implementations
the
leak
information
on
a
global
scale
because
they
do
lookups
out
onto
the
network.
A
So
in
this
situation
one
device
advertises
a
service
that
allows
others
to
discover.
It
sounds
all
well
and
good,
but
what's
common
in
terms
of
doing
this
is
that
you
give
your
laptop
a
name
and
your
laptop
uses
that
name
when
it
advertises
your
services,
so
you
may
some
of
you
who
can
actually
look
on
the
network
right
now.
You
may
be
able
to
see
devices
on
the
network
that
are
sharing
in
this
way
and
figure
out.
You
know
it
could
be.
You
know
Bob's
phone
as
well.
A
A
It's
drill
down
into
the
details
of
which
services
advertised
with
which
parameters-
and
this
allows
fingerprinting
of
devices
and
this
research
that
has
shown
you
can
fingerprint
down
to
both
software
and
hardware
even
to
software
versions,
because
bugs
get
fixed
and
you
can
see.
Oh
they've
got
the
version
before
this
bug
got
fixed.
So
again,
this
allows
fingerprinting
of
individuals
and
re
identification
through
something
that
people
see
is
a
very,
very
benign
mechanism.
A
The
good
news
is
that
the
dns
SD
working
group
are
also
working
on
this
problem.
They've
recognized
it
it
it's
a
different
problem
to
solve.
They
have
some
drafts
recommending
this.
So,
if
you're
interested
coming
onto
that
working
group
later
this
week
so
now,
I
want
to
skip
on
to
we've
done
the
standards
work.
Where
are
we
with
implementation?
A
So
one
was
also
want
to
direct
you
to
is
the
DNS
procedure
org
website,
so
the
goal
here
is
organizations
interested
in
promoting
DNS
privacy
to
be
a
central
reference
point
for
where
we
are
in
the
evolution
of
this.
So
various
people
involved
in
this
say,
'cimmanon
are
involved
and
on
that
labs
are
contributing
a
lot
Salesforce.
There's
too
many
to
mention
here.
Lots
of
individuals
are
contributing
and
we're
getting
grants
from
a
range
of
organizations.
A
So
the
kind
of
things
that
we
want
to
do
here
is
is
be
a
first
stop
shop
for
what's
going
on
with
Dena's
privacy,
how
can
I
help?
How
can
I
protect
myself?
So
one
thing
we're
doing
is
key
is
trying
to
keep
track
of
the
state
of
the
implementations
in
the
major
open
source.
Dns
name
servers,
so
you
can
see
here
that
not
resolver
is
doing
really
well.
They
have
a
bunch
of
stuff
available
and
bound
is
really
close
behind
and
bind
has
chosen.
A
A
The
bind
have
actually
produced
a
article
in
the
knowledge
database
for
how
to
put
a
stun
on
in
front
of
bind,
and
this
can
work
really
well,
although
there
are
some
disadvantages
because,
of
course,
that
load
balancer
isn't
DNS
aware
it's
rather
blindly
passing
through
some
danis
options
that
would
normally
be
catered
for
by
the
DNS
server.
Additionally,
it
means
that
the
source
IP
address
of
the
query
doesn't
make
it
to
the
server.
So
some
of
the
features
in
the
DNS
server,
like
ACLs,
can't
work
effectively
because
they
don't
know
where
the
queries
are
from.
A
What
would
be
nice
is
if
we
got
tearless
support
in
DNS
dist
dearness
dist
is
a
DNS
load
balancer,
which
has
a
huge
range
of
features.
It's
a
really
nice
piece
of
software
and
a
lot
of
people
use
this
in
front
of
server
farms
to
distribute
queries,
and
there
is
a
feature
request
into
this,
and
I
have
heard
encouraging
noises
from
the
padding
this
folks
thing,
they're
working
on
it,
I
personally
think.
A
If
we
had
this,
it
would
be
a
game-changer
in
terms
of
running
servers,
because
people
would
feel
confident
about
using
it
and
it
seems
like
a
really
natural
solution
on
the
stub
size.
The
pictures
a
bit
more
mixed,
there's,
a
relatively
new
Dennis
library
will
get
DNS,
which
has
really
tried
to
become
fully
featured
in
terms
of
what
it
takes
to
do.
Good
DNS
over
TLS
and
I'll
talk
about
this
more
in
a
minute.
A
A
So
in
that
picture,
the
summary
of
where
we
are
in
terms
of
implementation
status
are
that
there's
better
TCP
handling
dealer
servers,
there's
been
a
very
encouraging
uptake
of
queue:
name
minimization.
There
are
several
implementations
of
Denisova
TLS
and
what
we
haven't
seen
yet
is
any
implementations
of
DNS
over
TLS
I'm,
not
really
sure
why?
But
the
interest
has
really
been
focused
on
TLS
and,
as
I
mentioned,
that
our
implementations
out
there
doing
a
form
of
DNS
over
HTTP
to
move
on
to
where
deployment
is,
and
we
have
today
experimental
servers
that
are
available.
A
We
don't
have
any
large-scale
deployments.
I
am
aware
of
two
or
three
organizations
who
are
planning
to
do
that
in
the
next
year,
or
so.
So
it's
on
the
way.
But
at
the
moment
we
have
a
set
of
12
experimental
servers
that
use
a
mix
of
software
that
information
about
all
these
servers
can
be
found
on
the
DNS
that
DNS
privacy
or
website
oops.
That
didn't
work
very
well.
That
block
shouldn't
be.
A
My
animation
clearly
failed
that
so,
if
you
want
to
see
the
status
of
those
servers,
you
can
go
to
this
stage
and
see
it,
and
it
also
tries
to
tell
you
some
of
the
capabilities,
for
example,
whether
they're
doing
keno
minimization,
whether
they
prevent
present
through
some
mechanism,
authentication
credentials
that
you
can
use
to
do
strict
privacy.
Things
like
that.
The
thing
I
did
want
to
announce
with
my
last-minute
addition
to
my
slide
was
that
for
the
first
time
at
this
ITF,
the
network
operations
team
are
running.
A
Two
DNS
server,
TLS
enabled
servers
through
the
ITF
network.
So
if
you
do
want
to
start
using
this
and
playing
with
it,
then
we
have
local
servers
to
do
that
and
I
believe
the
information
for
that
is
on
the
meeting
network
page
and
if
it's
not
come,
find
me
or
email
me
and
I
can
I
can
share
that
with
you.
A
That
was
just
a
minor
minor
freeze,
okay
right,
so
that's
the
story
on
the
server
side.
What's
the
story
on
the
client
side,
as
I
mentioned,
the
best
place
we
can
recommend
you
to
go
today
is
to
use
stubby
stubby's
an
application
that
works
as
a
previous
enabling
resolver
on
a
local
machine.
It's
based
on
the
get
dns
library
and
it's
it's
really
a
wrapper
around
running,
get
dns
library
as
a
daemon.
There's
a
user
guide
available
to
help
you
get
up
and
running
with
it.
A
It
came
out
in
the
that
the
best
place
you
shouldn't
take
anything
less
than
the
1.1
release
of
get
dns.
If
you
want
stubby
and
it
runs
as
a
daemon
locally
picks
up
any
queries
that
go
to
localhost.
So
by
reconfiguring
your
system
resolvers
to
same
queries
to
localhost,
they
will
all
get
picked
up
by
stubby
and
proxied
out
over
TLS
and
it
comes
with
a
default
configuration
which
uses
a
subset
of
the
servers.
The
experimental
service
I
mentioned
earlier.
Oh
boy,
okay,
my
laptop
doesn't
want
to
play.
A
So
I'm
gonna
n-
let's
hope
we
can
make
it
there.
So
stubby
is
currently
in
a
prototype
stage,
we're
kind
of
saying
it's
from
fans,
technical
users,
it's
not
for
everybody.
Yet
it
does
support
all
the
features
we
talked
about
in
terms
of
choosing
between
strict
and
opportunistic
and
choosing
between
a
name
or
pin
and
authentication
a
word
of
warning.
We
are
actively
working
on
evolving
stubby
and
some
of
this
work
happened
at
the
hackathon
this
weekend,
we're
going
to
separate
stubby
s
at
the
moment.
A
It's
basically
a
tool
that
comes
with
the
getting
us
library
when
you
install
it
we're
separating
it
out
to
be
its
own
standalone
application,
we're
rewriting
the
documentation,
redoing
all
the
packaging
except
Russ.
So
if
you
go
and
look
at
information
related
to
stubby,
it
probably
will
evolve
in
the
next
few
weeks
as
we
we
do
all
that
work,
we're
also
working
on.
We
have
a
homebrew
tap
at
the
moment,
which
should
be
a
formula.
A
Hopefully,
next
week
we
have
docker
images
and
we
are
in
the
early
stages
of
thinking
about
what
a
GUI
on
this
would
look
like,
because
if
you
want
events
accessible
to
non-technical
users,
you
have
to
think
about
that.
So
we
have
a
GUI
that
I'm
happy
to
demo
to
anybody
who's
interested.
Given
my
flakiness
of
my
laptop
I,
don't
know
to
our
live
demo
right
now.
Basically,
it's
a
little
control
panel
that
lets
you
run
stubby
as
a
service
gives
you
a
button
that
flicks
your
system
resolvers.
A
So,
as
I
said
this
week
at
the
hackathon,
there
was
work
on
stubby.
There
was
also
some
work
done
by
folks
in
the
room,
starting
an
implementation
of
how
to
do
the
Dane
method
of
authentication
and
that
included
doing
it
using
the
TLS
extension
and
there's
also
some
really
good
work.
Starting
support
within
Android
to
do
an
opportunistic
form
of
DNS
over
TLS
and
I'm
really
excited
about
that.
A
So
I
want
to
thank
the
guys
who
who
did
the
work,
because
I
think
that
that's
a
really
important
step
in
making
this
more
broadly
available,
but
it
does
bring
an
interesting
question,
which
is
how
do
we
make
this
usable?
So
the
thing
is
dinners
privacy
is
going
to
be
a
completely
new
paradigm
for
end
users.
Think
about
how
much
people
struggle
just
with
HTTP
to
you
know
not
going
to
insecure
websites
and
think
about
all
the
effort
that's
been
put
into
getting
the
icon
just
right.
There's
server
certificate
warning
messages
right.
A
Dns
security
as
well,
is
going
to
be
a
real
challenge
in
terms
of
communication,
and
another
challenge
to
add
on
to
that
is
that
message
is
probably
going
to
be
coming
from
DNS
folks
who
really
aren't
used
to
dealing
with
end
users,
we're
used
to
having
DNS
under
the
hood
and
just
work
so
I
think
that
will
be
really
interesting
dynamic
as
those
two
worlds
meet
to
make
the
succeed.
What's
come
out
of
the
HTTPS
world.
Is
this
concept
of
not
just
that?
A
Well,
but
all
the
studies
into
things
like
trying
to
make
email
encryption
easy
a
whole
variety
of
different
places.
Is
you
have
to
have
something
called
usable
security
which
it
means
that
a
really
nice
good?
You
isn't
good
enough,
because
users,
don't
if
they
don't
understand
what
they're
doing
they
can
still
make
huge
mistakes
even
with
the
best
of
intentions,
and
even
if
they
do
know
what
they're
doing
they
can
still
make
mistakes.
So
you
have
to
basically
do
everything
you
can
to
protect
users
from
themselves
and
enable
them
to
get
the
privacy
they
want.
A
So,
to
summarise,
these
are
what
I
think
the
key
challenges
short
term.
So
one
is
awareness
both
among
technical
and
non-technical
folks.
The
second
is,
clients
is
getting
usable
clients
and
getting
DNS
over
TLS
support
integrated
into
operating
systems,
usable
clients
for
non-technical
users.
We
are
still
held
back
by
not
having
some
walls,
wide-scale
deployment
of
servers
and
but
I
think
that
is
coming
and
as
I
will
keep
banging
on
about.
A
So
to
summarize,
dinners
privacy
is
a
real
problem
and
it's
one
that
most
people
aren't
aware
of
and
I
think
you
hear
many
of
the
discussions.
Many
of
the
political
clashes
between
the
human
right
to
privacy
be
needing
to
being
protected
against
government's
desire
to
wanting
to
have
a
back
door
into
encryption
and
Dinis.
It's
not
alone,
but
I
think
it's
becoming
increasingly
caught
up
in
that
discussion
and
it's
a
very
large
solution
space
and
it's
not
going
to
happen
overnight.
It's
going
to
be
years
before
we
get
there,
but
we
have
made
progress.
A
You
can
do
Dinis
privacy
today
and
that
situation
is
improving
because
I
really
think
over
the
next
year
or
so
we
will
see
a
lot
more
dinis
privacy
services
emerging.
So
with
that
I
think
I
am
out
of
time
all
those
I
hope
this
time
for
a
few
questions.
So
I'll.
Thank
you
for
your
time
today
and
take
any
questions
from
the
floor.
D
A
D
A
A
D
A
So
and
it's
when
you
talk
about
doing
it
over
HTTP
I
find
interesting,
because
it
is
shifting
that
model
to
saying
that
you
get
your,
you
can
get
your
DNS
from
a
variety
of
places
that
there's
an
argument
that
says
you're
you
you
may
want
to
restrict
doing
that
to
sites
you
have
already
authenticated
with
HTTPS,
in
which
case
now
you
have
some
context,
but
the
details
of
that
aren't
clear.
Yet
quite.
D
It
comes
back
to
your
usable
security.
I
could
see
it
actually
making
things
worse
because
you
know
I
get
a
phishing,
email
and
I
hover
over
it
and
it's
easy
to
spot,
because
the
DNS
is
wrong
now
in
future,
the
DNS
will
look
right
to
me
because
it
was
everything
about
it
looks
right.
Is
it's
all
because
I
started
on
the
website
somewhere
that
I
thought
was
correct?
Yes,.
B
So
speaking
of
things
we
bang
on
about
that
works,
actually
a
segue
into
my
personal
peeve
is
this
term
DNS
over
HTTP,
because
it
means
different
things
to
different
people.
You
presented
kind
of
a
DNS
world
view
of
it.
The
web
browser
people
have
a
very
different
view
of
what
it
means
and
those
views
are
strongly
opposed
to
each
other.
B
As
far
as
the
involvement
in
DNS
servers
and
invalidation
and
generating
in
what
the
data
represents
and
unfortunately,
I
haven't
myself
come
up
with
better
nomenclature
about
it
and
until
we
have
better
nomenclature
to
reflect
the
two
different
views
of
what
the
term
even
means
you
just
have
to
be
excruciatingly
ly
clear,
and
in
this
particular
case
it
wasn't
it
crossed
that
fuzzy
boundary
of
well,
which
are
we
just
talking
about
encapsulating
the
DNS
protocol
through
the
HTTP
transport.
Or
are
we
talking
about
how
a
web
server
delivers?
Address
information
ya.
E
E
E
B
B
A
Just
repeat
that
to
Mike,
so
was
that
probably
the
biggest
thing
that
mr.
gates,
in
that
circumstance,
is
using
cue
name
minimization,
so
that
the
full
query
doesn't
go
to
the
onion
servers,
so
reducing
data
liquid
leakage
in
that
fashion.
But
of
course
we're
only
talking
today
about
a
solution
that
works
stub
to
recursive,
not
recursive
to
authoritative.
So
the
cue
name
really
is
the
only
investigation
you
have
on
that
path.
There's
been.
A
What
might
be
helpful
is
there's
been
some
interesting
work
on
the
fact
that
tor
is
actually
leaking
information
because
it
does
clear-text
dns
after
some
of
its
exit
nodes,
which
they've
realized,
is
a
data
leakage
and
then
are
interested
in
using
D
instead
of
TLS
for
their
dns
resolution,
because
they
haven't
really
recognised
it
as
a
an
attack
path,
but
they
have
more
recently
recognized
that
so
is
that
helpful?
Okay.