►
From YouTube: IETF 110: Technology Deep Dive on DNS, Part 2
Description
This session will be held 17:00-19:00 UTC on 4 March 2021 and will cover, in detail, the operational realities and technical nuances of the Domain Name System, a central building block for today’s Internet.
E
C
B
B
D
D
D
Yes,
while
we're
waiting
for
people
to
join,
I
will
just
note
that
this
is
the
second
part
in
the
technology
deep
dives
in
the
dns.
The
first
part
happened
at
ietf
108
and
the
video
is
online
on
youtube
and,
I
believe,
is
also
linked
to
from
the
ietf
website
somewhere.
I
realized
that
was
not
the
most
useful
update
ever,
but
if
you
look
around,
you
should
be
able
to
find
it
otherwise
email
me
or
I
will
try
and
remember
to
put
a
update
somewhere.
B
D
B
Time
is,
of
the
essence,
look
welcome
everybody
and
for
those
in
the
asia
pacific
area,
particularly
those
in
japan.
I
feel
your
pain
here
on
the
east
coast
of
australia.
It
is
you
know,
a
civilized
4
a.m
in
parts
further
west
from
me,
it's
not
it's
worse.
For
the
next
hour
and
a
half
we're
going
to
be
talking,
dns
it's
when
too
much
dns
is
barely
enough,
and
this
is
the
second
part
of
these
deep
dive
sessions.
B
Looking
at
some
of
the
sort
of
security
issues
that
come
up
with
the
way
in
which
we
use
names
which
wes
is
going
to
cover
and
cover
some
of
the
more
prevalent
myths,
fantasies
and
misconceptions
that
that
sit
within
the
dns
and
and
see
what
else
we
can
uncover.
So
we
have
90
minutes,
which
is
a
comfortable
amount
of
time.
B
Up
and
don't
forget,
I
haven't
had
coffee
yet
so
with
that
said,
let's
start
the
usual.
Read
this
carefully
note
it!
Well,
you
have
two
seconds
done,
let's
start
by
thinking
about
what
a
name
is
and
wasn't
it
shakespeare,
romeo
and
juliet,
what's
in
a
name,
a
rose
by
any
other,
something
or
rather
my
memory
is
now
gone
a
name.
B
We
use
it
as
as
kind
of
a
human-based
token,
an
alias
for
what
we
would
call
an
address.
An
address
is
something
an
endpoint
destination
that
an
ip
network
uses
to
relay
a
packet,
and
so
all
we're
doing
with
the
name
in
this
kind
of
destination
based
packet.
Forwarding
network
is
providing
an
alias
for
an
ip
address.
B
Now
we're
not
talking
about
why
you
wanted
to
send
a
packet
there.
It's
just
the
name
of
an
ip
address,
the
name
of
a
host,
in
fact,
to
be
perfectly
frank,
the
name
of
an
interface
on
a
host,
and
it's
up
to
something
else.
The
transport
protocol
port
address
normally
to
effectively
select
what
the
services
that
you're
trying
to
get
to
on
that
host
the
name
itself.
B
Well,
I
actually
said
the
name
of
the
platform,
not
the
particular
service,
but,
to
be
brutally
honest,
that's
not
quite
correct.
It's
the
name
of
the
ip
address
of
the
interface
of
the
platform,
not
the
name
of
the
service,
but
in
any
case
it's
not
a
service
name,
and
the
intention
was
this
is
human
use.
This
is
about
things
that
you
and
I
use
as
people
talking.
You
know
a
natural
language.
B
It
wasn't
an
artifact
of
the
network
when
the
packet,
the
ip
packet
heads
to
its
destination,
the
ip
part
of
the
packet,
never
mind.
Transport
and
application
does
not
have
any
use
of
a
name.
All
that
you
find
there
is
those
v4
32
bits,
v6,
128-bit,
source
and
destination
ip
addresses.
There
are
no
names
there.
We
are
not
routing
names
in
this
architecture,
so
they
were
intended
at
least,
and
I'm
going
back
about
40
or
50
years.
B
It
was
so
much
more
useful
if
the
same
host
had
the
same
name
irrespective
of
the
protocol.
So
if
you're
going
to
use
uucp
or
unit
mail,
you
know
that
kind
of
issue.
If
you're
going
to
use
ip
mount,
if
you're
going
to
use
any
other
form
of
protocol
family,
it's
very
useful.
If
the
name
is
constant,
I'm
going
to
go
to
the
host
called
fred
almost
irrespective
of
what
protocol
I'm
going
to
use
so
to
make
that
work.
B
You
actually
had
to
have
these
host
names
specified
as
the
lowest
common
denominator
across
all
of
these
protocol,
specific
in
application,
specific
limitations
and
so
host
names
took
a
much
smaller
character
repertoire
than
actually
is
possible
inside
dns
labels,
which
joao
is
going
to
explore
in
incredible
detail
later
on
and
just
to
illustrate
this.
I've
actually
jumped
joe
house
name
into
unicode
to
sort
of
point
out
that,
even
in
our
human
use,
what
we
think
is
a
character
repertoire
varies
language
by
language.
B
So
there's
some
very
subtle
distinctions
going
on
here
around
the
names
of
hosts
and
the
names
of
labels
and
the
rules
for
hosts
are,
of
course
much
more
constrained,
and
the
answer
is
why
it's
nothing
to
do
with
the
dns
per
se.
The
dns
in
that
area,
quite
frankly,
doesn't
care
and
doesn't
make
that
distinction
in
and
of
itself
it's
more
about
mapping,
protocols
and
names
into
applications.
B
B
B
B
Host.Text
is
client-centric,
so
you
could
have
a
host
dot
text
that
calls
the
ip
address.
You
know
one
two,
three
four
fred
and
I
could
call
it
jeff
and
joao
could
call
it
bob
and
no
one
would
care,
because,
while
we're
referring
to
the
different
hosts
with
different
the
same
host
with
different
names,
the
dns
doesn't
sorry
that
the
host
didn't
care
and
actually
your
applications
didn't
care.
B
However,
when
we
turned
into
a
distributed
database,
all
of
a
sudden,
the
name
became
unique
because
we're
all
sharing
one
database.
We
don't
have
different
hosts.txt
per
se,
we're
all
working
in
one
database,
but
the
database
itself
was
distributed.
It
wasn't
just
oh
host.txt
exists
on
a
server
over
there.
B
So
we
added
two
more
records
into
this
distributed
database.
We
had
the
my
name
to
ip
address.
Mapping
originally
called
an
a
record
a
for
address.
We
also
had
sewer
records
start
of
authority.
That
was,
if
you
will,
all
the
names
in
this
bundle
that
are
related,
have
the
common
set
of
properties.
These
are
the
properties,
the
zone,
administration,
contact,
expiry,
timers
time
to
live
and
so
on.
If
it's
not
specified
use
this
value
and
the
names
that
I
don't
know
about,
which
are
child
names
in
a
hierarchical
system.
B
B
It's
an
alias.
The
dub
dub
dumb
for
giving
a
name
that
you
subsequently
go
to
port
80
on,
and
so
you
can
distinguish
that
from
ftp.exam
mx.example.com
and
blah
blah
blah,
where
you're
actually
putting
the
service
name
on
the
left
hand
side
as
part
of
the
query
name.
So
this
allows
you
to
specify
a
set
of
hosts
different
hosts
that
supported
the
services
that
had
a
common
name
and
all
of
a
sudden
you're.
B
So
all
of
a
sudden
I've
got
greater
capacity.
I've
got
service
disambiguation,
but
why
don't
I
make
the
dns
work
harder?
Well,
obviously,
why
not?
Because
I
can
so
why
don't?
I
include
the
name
in
the
protocol
exchange
itself.
Hi
host,
I
want
I've,
got
a
transaction
for
www.example.com,
says
the
application
now,
the
first
one
to
do.
That
was
actually
electronic
mail,
because
one
of
the
early
needs
was
to
provide
mail
when
the
host
was
down.
B
So
we
had
secondary
mx
servers
that
basically
provided
a
mail
service
for
a
host
that
wasn't
there
because
don't
forget
in
the
days
before
gmail,
if
anyone's,
still
old
and
anyone's
still
old
enough
to
remember
that
in
the
news
before
gmail,
a
lot
of
us
ran
our
own
mail
hosts
their
own
send
mail,
and
maybe
we
were
on
dial-up.
Remember
that
and
so
all
of
a
sudden,
when
you
weren't
there,
you
didn't
want
to
back
the
mail
up
at
the
center.
B
So
they're
abstractions
weren't
they
they
allowed
orchestration
of
multiple
servers.
Now
some
of
these,
we
loaded
through
the
dns
itself,
so
the
common
service
name,
which
is
no
longer
a
host
name,
then
had
a
variety
of
attributes
through
different
resource
records.
Ns
records,
mx
records
and
such,
but
then
we
thought
well.
B
Actually
what
I'd
like
to
do
is
move
the
service
for
a
host
to
a
different
name,
and
we
invented
the
alias
record,
the
canonical
name
record
or
the
cname
record,
whereas
most
of
these
service
names
are
implicit,
the
a
and
quad
a
records
which
give
you
ip
addresses
simply
says.
The
service
delivery
host
is
mapped
against
this
service
name.
B
So
this
allows
us
to
sort
of
think
about
what
a
name
is
now
it
started
off
by
effectively
taking
the
idea
of
the
name
of
a
host,
a
computer,
the
interface
of
that
computer
and
actually
abstracting
that
to
a
university,
visible
service.
Point
identifier:
it's
the
name
of
a
service,
not
a
host,
but
we've
also
used
a
whole
bunch
of
other
names.
B
There
are
a
whole
set,
probably
outnumbering
human
names.
These
days
of
transient
labels,
dynamically
generated
names
of
various
forms
and
sorts
where
it's
just
a
temporal
name.
Here's
a
token.
Here's
a
machine
over
there
that
for
the
next
10
15
micro
seconds,
might
well
serve
as
a
point
of
rendezvous
with
what
you're
trying
to
do
ns
records.
B
And
I
suppose
the
observation
is
that
every
time
we've
looked
at
this
and
we've
looked
at
this
a
lot
of
times,
we
propose
a
new
generic
mechanism
that
can
be
used
with
any
application.
Wonderful,
but
each
time
we
invent
this,
one
application
uses
that
and
we
move
on
so
every
application
uses
a
unique,
quite
specific,
but
generic
dns
solution
as
to
how
to
do
this.
B
So
when
we
map
names
to
services,
we
can
place
the
information
in
the
value
part
of
this
key
value
store,
and
you
know
the
service.
The
svc
record
is
a
classic
example
of
trying
to
place
rendezvous
information
in
the
right
hand,
side
of
the
dns
in
the
resolution
side
or
we
can
play
with
the
left
hand,
side
the
query
name
and
we
can
use
the
dns
to
go.
B
So
the
first
time
we
found
one
of
these,
I'm
not
sure
what
was
in
the
head
of
the
folk
who
designed
it,
but
in
the
people
who
came
subsequently,
this
was
the
texas
chainsaw
massacre
of
text
records
the
universal
thing,
because
text
records
is
just
that
it's
text,
it's
ascii
strings.
I
can
put
anything
there.
I
can
hash
anything
there.
B
B
The
problem
is,
of
course,
that
if
everyone
used
text
records,
then
excuse
me,
you
have
to
make
sex
records
which
are
the
union
of
all
these
applications
and
disambiguating,
which
text
record
is
meant
for
which
application
can
be
an
enormous
problem.
But
you
know
if
the
thought
is
no
matter
what
you
want
to
do,
you
can
do
it
in
the
dns.
B
B
Now
there
were
some
various
attempts
to
do
this
and
and
the
first
time
we
sort
of
did
this
in
a
structured
way.
We
thought
we
would
actually
give
a
name
to
a
structure
of
a
text
record,
and
this
was
the
sender
policy
framework
for
mail.
We
call
them
spf
records
in
truth,
they're
just
text
records
with
a
particular
structure,
and
you
see
this
attempt
to
be
generic.
I'm
sorry
to
be
specific
in
a
generic
solution.
So
the
first
part
of
this
you
actually
have
the
vehicles,
spf
1
and
then
a
bunch
of
fields
and
values.
B
Earlier
than
that,
though,
and
as
an
example
of
doing
it,
probably
a
little
bit
better.
Was
the
mx
record.
Where
here
the
information
you
want
to
give
is
actually
structured
by
the
name
of
the
resource
record.
So,
instead
of
just
querying
for
a
text
record,
you
actually
query
for
a
particular
structure:
record
mx
and
yes,
there
are
names
on
the
right
hand,
side,
but
the
way
they
disambiguated
and
stopped
looping
was
that
the
names
on
the
right
hand
side
are
not
mx
records
themselves.
B
B
B
No,
it's
actually
aliases
for
the
entire
sub
tree,
so
anything
below
a
d
name.
On
the
left
hand,
side
isn't
reachable
nothing
there,
but
the
on
the
left
hand
side
on
the
right
bit.
Sorry
on
below.
On
the
right
hand,
side,
I'm
still
tired.
The
d
name
exposes
the
entire
sub
tree
in
a
c
name.
That's
it
both
on
the
left
and
the
right
hand
side.
There
is
nothing.
B
They
exist
alone.
They
can't
be
at
the
apex,
there's
nothing
below
it.
They
are
terminal
names.
I
suppose
that's
the
distinction
between
a
c
name
and
a
d
name.
A
d
name
is
an
alias
higher
up
in
the
tree
or
potentially
so
a
c
name
is.
It
is
an
alias
for
terminal
labels.
There
is
nothing
below
them,
even
so
names.
B
On
the
right
hand,
side
are
a
problem,
and
certainly
here
are
some
some
simple
examples
to
basically
illustrate
the
fact
that
dog
and
cat
can
be
seen
am
to
each
other,
and
the
only
way
of
stopping
this
is
for
the
resolver
to
say.
Look
enough
is
enough.
Stop
stop
giving
me
a
hard
time,
because,
while
it
might
be
easy
to
detect
a
loop
of
two,
it's
incredibly
challenging
to
detect
a
loop
of
a
hundred
say,
and
there
are
two
problems
with
these
kinds
of
loops.
B
But
you
know
we
can
do
more
and
it's
hard
to
say
whether
the
nafta
was
just
fashionable
or
a
demonic
invention
of
incredible
evilness,
but
it
was
certainly
cute
what
happens
if
we
take
a
text
value
and
throw
it
into
a
regular
expression,
parser
and
inside
the
dns
actually
put
that
regular
expression
and
I've
taken
this
example
from
the
documentation.
But
let
me
assure
you
these
are
regular
expressions
and
there
is
more
than
enough
rope
more
than
enough
rope
to
do
anything
you
want.
B
The
challenge
is
to
do
the
towers
of
hanoi
in
napta
records.
Go
forth,
it's
hard
to
sort
of
talk
about
this
in
much
detail.
But
what
it's
saying
is:
if
you
look
up
a
nafta,
you
get
a
priority
and
you
get
effectively
an
application
directive,
and
then
you
get
this
weird
thing.
If
you're
saying
take
the
application
string,
you
thought
you
were
looking
for
and
substitute
the
following.
B
So
here's
one
that
was
borrowed
for
that
early
attempt
to
borrow
telephone
numbers
into
the
dns
enum,
which
we
thought
at
the
time
was
incredibly
clever
and
the
generic
solution
we
had
was
take
a
reverse
telephone
number,
plus.
Seven
one:
seven,
oh
five,
five
five
one,
two
one
two
and
translate
it
using
only
the
dns
into
a
sip
call
to
an
alias
called
information
from
the
server
tele2
in
sweden.
B
Okay,
I
wonder
if
anyone
used
it,
maybe
they
did
at
the
time.
I
think
it's
fallen
largely
into
disuse.
It
really
did
get
and
push
the
dns
an
awfully
long
way
so
generically
what's
going
on.
Well,
you
can
put
loops
in
the
dns
in
all
kinds
of
places
in
all
kinds
of
ways
you
can
actually
put
loops
outside
of
the
dns
database
structure
and
put
it
in
the
name
referencing
structure.
B
So
in
essence,
what
we're
doing
at
this
particular
point
is
doing
forwarder
clauses-
hey,
I
can't
do
anything,
go
and
speak
to
x
and
x,
says
I
can't
do
anything.
Here's
a
forward
statement
go
and
speak
to
y
and
y
says
I
can't
do
anything,
go
and
speak
to
x
and
all
of
a
sudden,
you
have
loops
inside
the
forwarding
chains
of
trying
to
resolve,
but
the
more
common
form
of
loop
is
actually
in
in
the
dns
data
itself,
and
you
can
certainly
do
ns
record
loops
quite
easily.
B
Normally
the
parent
zone
contains
the
glue
records
of
the
name
servers.
But
what,
if
you
don't
the
name
server
from
my
domain,
is
dog.com
go
figure
and
in
dog
it
says:
well,
that's
cool,
but
the
name
server
for
my
name
is
cat,
but
I'm
not
going
to
tell
you
it's
address
and
cat
says:
hey.
The
name
server
for
my
name
is
over
in
dog,
all
of
a
sudden.
You've
got
loops
inside
the
ns
structure
and
again,
if
not
handled
sensibly
by
the
resolver,
you
can
follow
that
loop
forever
and
so
some
ways.
B
B
And
so
it's
a
subtle
form
of
alias
where
it's
not
the
name
that
is
aliased.
The
service
is
aliased,
so
I
can
take
example.com
and
I
can
alias
my
sip
service
to
someone
in
theory.
I
could
alias
my
http
service
to
someone
else.
I
could
use
my
dane
service
to
someone
and
I
could
alias
the
name
to
a
whole
bunch
of
other
names
simply
by
service
protocol
and
port
while
having
the
common
name.
B
Simply
as
you
will
the
guiding
point
so
the
right
hand
side
host
now
is
the
canonical
name,
but
unlike
a
c
name
or
a
d
name,
no
matter
what
you're
trying
to
do
look
there.
This
is,
if
you're,
trying
to
use
sip
on
tcp.
Look
there
if
you're
trying
to
do
anything
else.
I
don't
know
I'm
not
the
record
to
talk
about
everything
else.
So
it's
quite
a
specific
record.
B
But
oddly
enough,
every
generic
solution
is
never
generic
enough
and
when
we
looked
at
c
names
and
we
couldn't
do
an
alias
at
the
root
because
the
apex-
sorry
because
you
can't
alias
at
the
apex
folk
wanted
to
do
that.
But
I
want
to
do
this,
so
we
experimented
around
with
various
permutations
of
what
I
would
call
a
name,
and
a
name
was
an
alias
that
included
aliasing
at
the
apex.
B
There
were
alternatives
for
service
records,
alt
servers
and
then,
when
we
looked
at
encrypted
snr,
we
wanted
to
put
the
keys
somewhere,
and
these
are
all
attributes
of
a
rendezvous
trying
to
get
to
somewhere,
and
so
what?
If
we
try
and
make
this
generic
and
take
all
of
these
things
and
put
it
in
a
generic
service
form,
which
became
service
b
and
service
b,
looks
a
little
bit
like
a
structured
text
record
again.
B
Just
this
port
in
this
protocol
and
somewhere
else
now
has
a
whole
bunch
of
attributes
that
talk
about
the
application
level
protocol
name,
the
port
name,
the
keys
name,
the
this
name.
So
all
of
a
sudden
you
can
say
that
flu.foo
colon
api
example.com
and
this
port
8443
is
alias
to
use
an
application
level
protocol
called
bar
and
service
endpoints
offered
on
this
host,
using
this
port,
etc.
B
B
B
I
want
to
use
https
to
go
to
this
service
name.
This
is
my
immediate
intention
into
the
dns
telling
you
exactly
what
those
service
rendezvous
mechanisms
should
be,
what
protocols
to
use
what
ports
to
use,
what
attributes
you're
going
to
use
at
the
application
level
in
order
to
make
that
connection
work.
Why
do
we
do
this
because
it's
faster
because
all
of
a
sudden,
I'm
getting
rid
of
that?
First?
Look:
I'm
getting
rid
of
redirection
to
the
application
level
by
pushing
stuff
into
the
dns.
B
The
theory
goes,
and
it's
not
always
true-
that
the
dns
can
give
you
that
rendezvous
information
much
much
faster,
but
in
some
ways
this
is
not
the
best
of
things,
and
this
is
my
lead,
I
think,
into
where
wes
is
going
to
be.
I've
used
more
than
enough
time,
I'm
four
minutes
over
dns
is
not
secure
and
anything
that
is
promiscuous
and
to
dns
is
promiscuous,
no
matter
how
we
try
is
not
completely
private.
B
Some
information
is
always
going
to
have
to
be
public,
because
this
is
public
rendezvous
and
to
what
extent,
if
now
we're
saying
I
just
want
not
just
the
the
ip
address
of
a
host,
but
I
intend
to
connect
to
pharmdafa.org
or
some
other
evil
name.
But
more
than
that,
I
intend
to
use
this
protocol
and
this
port.
I
intend
to
do
the
following,
and
the
dns
goes.
A
All
right,
thank
you,
jeff,
yes,
so
the
dns
is
not
secure.
The
dns
was
not
secure
would
be
the
other
way
to
possibly
do
it.
Let
me
share
my
slides,
and
so
I'm
going
to
talk
for
the
next
half
an
hour
about
dns
security
and
I'm
wes
hardiker
from
the
information
sciences
institute,
and
this
is
the
30
minute
overview
of
dns
security.
However,
first
I
want
to
touch
on
something
I
did
last
time.
A
The
very
last
thing
always
has
the
most
mistakes,
because
it
gets
the
last
review
at
least
review,
so
it
actually
occurred
with
this
top
record
down
here,
where
I
had
said
at
the
time
that
host1.example.commx
matched
the
wildcard,
it
does
not,
it
actually
should
not
match
and
it
should
return
no
error,
but
the
text
up
above
we
actually
should
have
called
this
out
as
well.
It
matches
any
label
that
doesn't
already
exist,
but
that
label
did
exist
down
here.
A
We're
going
to
start
by
looking
at
sort
of
the
attack
surfaces.
Where
can
dns
be
attacked
and,
like
you
know,
most
other
protocols
that
started
in
the
internet
they
weren't
secure
in
the
beginning,
because
everybody
believed
that
the
network
should
be
trusted.
That's
certainly
no
longer
the
case,
I'm
stealing
a
slide
from
russ
mundy.
Who
has
talked
about
this
at
icann
meetings,
a
number
of
other
places
to
talk
about
how
the
dns
actually
is
put
together
from
a
registration
point
of
view.
A
A
The
important
thing
to
note
that
most
of
what
I'm
going
to
be
talking
about
today
is
over,
on
the
right
hand,
side.
I
have
one
next
slide
on
the
registration
area,
but
we're
not
going
to
touch
that
too
much
we're
going
to
talk
a
lot
more
about
the
right-hand
side.
The
important
thing
to
note,
of
course,
is
that
evil
people
can
do
stuff
to
pretty
much
anywhere
in
the
entire
tree.
So
do
be
aware
of
that.
A
So
if
we
talk
about
the
registration
side,
there
are
sources
of
you
know,
insecurity
all
throughout
the
dns,
and
the
question
you
know
you
should
ask
is:
what
is
the
best
way
I
could
get
data
into
the
dns
itself
right.
If
you
really
want
to
populate
the
dns
tree
with
bad
information,
you
should
actually
do
it
during
the
publication
side-
and
there
are,
you
know,
well-known
mechanisms
for
doing
so,
a
lot
of
which
include
social
engineering
on
the
publication
side
on
both
registry
and
the
registrar,
and
then
you
can
also
attack
the
zone
itself.
A
None
of
the
security
protocols,
I'm
about
to
talk
about
help
at
all.
If
you
don't
have
your
source
of
your
data,
you
know
secured
in
the
first
place,
so
somebody
can
take
over
where
your
data
is
coming
from.
Then
the
dns
securities
mechanisms
are
not
going
to
help
you
at
all
on
the
publication
and
consumption
side.
A
A
So
what
is
cash
poisoning
so
remember
that
resolvers
actually
cache
information
for
a
a
period
of
time
that
is
subject
to
the
data
itself,
a
maximum
period
of
time.
And
what
happens
is
your
laptop
may
query
the
resolver
and
the
resolver
is
going
to?
Maybe
it
has
the
root
and
comcast,
and
it's
going
to
send
its
query
immediately
to
www.example.com
note
that
www.example.com
or
the
example.com,
authoritative
server
is
probably
really
far
away.
A
So
if
the
resolver
is
getting
an
answer,
first
from
somebody
really
nearby
that
is
giving
it
a
false
answer,
then
the
resolver
may
believe
that
answer.
So
in
this
case
you
know
the
resolver
answers,
but
it's
before
the
authoritative
server
could
possibly
have
answered,
and
so
the
the
thing
about
dns
is
that
the
first
answer
wins
period.
So
you
may
get
more
multiple
answers.
The
ietf
has
long
talked
about.
A
Not
only
does
it
give
you
information
about
the
question
you
asked
about
at
the
top,
but
at
the
bottom,
in
the
additional
section,
there's
also
other
records
and
in
early
resolvers
would
actually
just
trust
anything
that
was
there.
So
you
could
include
records
that
were
totally
unrelated
to
the
question
and
the
resolver
would
cache
it
and
keep
it.
The
other
thing
that
happens
is
in
protocol
attacks.
You
can
actually
sometimes
just
flood
the
dns
resolver
with
response
packets
and
hope
that
they
accept
them.
If
you're.
A
Actually,
you
know
on
the
wire,
if
you're
a
man
in
the
middle
attack
or
a
person
in
the
middle
of
attack,
then
you
can
actually
possibly
see
the
values.
Otherwise
you
end
up
having
to
guess
you
know
the
ap
address
the
protocol
values
the
names
the
source
addresses,
and
things
like
that.
Maybe
you
can
see
some
of
them.
A
You
can
pick
popular
names
to
try
and
flood
the
most,
and
actually
that
was
a
very
valid
form
of
attack
and
it
actually
did
work
and
the
best
part
about
it
from
a
hacker's
point
of
view
is
that
the
answer
is
cashed
for
the
ttl
chosen
by
the
attacker.
Remember,
the
the
the
attacker
is
actually
returning
the
entire
dns
record.
That
includes
the
time
to
live
value
and
how
long
something
should
be
cashed
for
so
it's
very
common
to
see
very
large
ttl
values
in
cash
poisoning
attacks.
A
So
how
do
we
combat
this?
Well,
the
early
mechanisms
were,
let's
just
ignore,
non-authoritative
answers
right.
So
if
you
don't
you
don't
accept
data
from
questions
you
didn't
ask
and
there's
some
changing
and
stuff
that
has
to
be
taken
into
account
too.
But
generally
you
shouldn't
accept
stuff,
that's
below
not
not,
authoritative,
for
the,
where
you
asked
and
note
that
parents
do
have
to
supply
glue,
address
records
for
in
zone
child
name
servers.
I
did
talk
about
that
in
part
one.
A
You
should
go
watch
that,
if
you're
interested
more
in
about
that
subject,
but
resolvers
should
also
check
that
the
ip
address
and
the
udp
source
port
is
correct
and
that
the
dns
id
field
is
correct
and
senders
should
make
it
really
hard
for
these
to
guess
so
that
that
flooding
takes.
You
know
a
whole
lot
of
random
attempts
and
not
just
being
able
to
predict
the
next
value
that
might
be
sent.
A
So
you
should
randomize
your
source
port
number
and
you
should
randomize
the
id
field
in
the
dns,
and
that
gives
you
about
32
bits
of
randomness,
but
that's
still
not
cryptographically
strong
and
it
doesn't
work
for
onpath
attackers
either
that
can
see
and
copy
the
requests
in
the
first
place.
So
the
real
question
is,
you
know:
can
we
fix
it,
and
I
hope
I
got
at
least
that
song
stuck
in
a
number
of
people's
heads?
A
F
A
Two
different
forms
of
protection
so
object:
security
is
done
by
dnsec
in
the
dns
and
it
adds
cryptographic
signatures
and
all
the
records
it's
signed
at
or
near
the
data's
origin.
And
then,
once
it's
been
signed,
it
really
doesn't
matter
how
you
get
there.
It's
verifiable
in
the
middle
of
all
the
transactions,
it's
very
fireball
at
the
end,
but
it
only
provides
integrity
production.
It
does
not
provide
any
privacy
detection.
Those
records
are
queried
all
over
the
dns
tree
and
various
parties
can
see
it
path.
A
Security,
on
the
other
hand,
which
has
become
a
very
hot
topic
lately
for
dns
over
tls
and
dns
over
https,
for
example,
and
possibly
even
dnf's
over
quick
at
some
point
tunnels.
The
ansel's
answers
between
two
points,
and
it
does
this
with
both
integrity,
protection
and
encryption,
but
it
offers
you
know,
point-to-point
protection
only
so
it
verifies
who
you
got
it
from,
but
not
actually
what
it
is.
So
it
doesn't
it's
not
able
to
verify
that
the
data
on
the
other
end
is
actually
correct.
A
So
what
is
going
on
here?
Well,
they
have
two
very
different:
complementary
properties,
object
and
path
security,
so,
which
are
you
going
to
pick?
You
have
to
pick
one
or
the
other
right?
No,
you
actually
don't
object
and
pass
security.
Work
very
well
together
and
you'll
find
that
many
endpoints
of
of
path-based
approaches,
like
public
resolvers,
are
actually
doing
dns
sect
validation
so
that
they
can
prove
that
the
object
they
tried
to
validate
was
secure
before
tunneling
it
over
to
you.
So
there's
nothing
wrong
with
putting
a
locked
box
in
a
tunnel.
A
So
a
brief
recap
of
dns
security
technologies
that
exist
to
date.
The
object
security
like
I've
been
talking
about
is
dnsec
and
it
is,
you
know,
records
that
were
assigned
by
the
authoritative
source
or
somewhere
near
it,
and
it's
talked
about
in
a
number
of
rfcs,
including
43,
is
the
most
recent
one
that
is
at
least
a
current
standard.
A
F
A
A
Hence
the
large
rfc
number,
but
it's
actually
one
of
the
older
ways
to
do
dns,
secured
dns
using
shared
keys
and
dns
curve
was
another
technology
that
was
proposed
at
one
point,
which
is
another
point-to-point,
encryption
authentication
mechanism
using
elliptic
curve
and
that's
still
used
and
deployed
in
a
few
places
around
on
the
internet
as
well.
But
it's
not
standardized
within
the
ietf.
A
So
the
thing
to
note
about
all
of
this
is
that
there
are
various
areas
of
all
of
these
transactions
that
need
to
be
secured
right,
so
the
path-based
mechanisms
like
doe
dot
and
dodt,
and
any
of
the
other
ones
authenticates
and
encrypts
the
user
to
the
resolver's
protocol
traffic
is
on
the
left
hand.
Side
of
that
dnsec,
on
the
other
hand,
is
really
designed
to
to
prove
that
the
right
hand,
data
set,
has
not
been
modified
anywhere
from
the
root.
All
the
way
down
to
the
answers
you
actually
need
now.
A
Can
these
protocols
be
used
in
the
opposite?
You
know:
can
you
do
pass
security
on
the
right?
Yes,
but
it's
not
being
done.
Can
you
dmd
in
a
sec
on
the
left?
Yes,
it's
not
being
done
as
much.
There
are
some
instances
of
dnsec
occurring
on
the
left-hand
side,
but
not
as
much
it
can
be
used
in
both
places,
but
it
typically
isn't
so
again.
A
This
is
the
reason
that
they
pair
really
well
so
the
nice
thing
about
dnssec
is
that
it
secures
records,
no
matter
where
they
are
right.
So
if
there
was
a
record
that
was
created
in
example.com
and
it
propagates
up
to
you
know
various
dns
resolvers
in
isps
or
even
in
cloud
infrastructure,
and
if
you
get
all
the
way
to
your
home
router
and
then
possibly
all
the
way,
even
into
your
local
infrastructure.
A
If
you're,
especially
for
running
mail
servers,
it's
much
more
common
to
run
something
very
local,
and
then
it
doesn't
really
matter
right.
That
locked
box
is
verifiable,
no
matter
where
it
came
from,
including
over
a
swallow.
You
know
carrying
a
coconut
and
possibly
a
locked
box
of
dns
information
as
well
or
the
atf
rfc
on
communicating
over
avian
carrier.
A
So
how
does
it
work?
The
dns
sec
is
a
hierarchical
signing
mechanism
where
there's
public
private
key
pairs
created
at
various
points
along
the
tree.
The
resolver
typically
only
has
the
one
key,
possibly
a
couple
of
keys,
just
to
be
their
trust,
anchor
of
where
that
they
accept
stuff
from
that
is
signed,
and
they
do
this
by
checking
all
of
the
records
from
the
chaining
on
down.
So
the
root
zone
signs
with
its
dns
key,
the
the
ds
record
of
com.
A
So
you
can
put
other
records
like
all
the
text
records
that
jeff
just
talked
about,
for
example,
are
all
equally
as
well
validatable,
so
the
resolver
in
the
end
after
it
is
said
hey
all
of
this
is
great
client.
Here
you
go.
Here's
the
answer,
and
I'm
going
to
set
the
ad
bit.
80
is
equal
to
1
means
that
I
checked
it.
It
is
secure.
Dnsec
has
validated
the
whole
tree
you're
good
to
go,
except
that
this
message
typically
isn't
sent
securely.
A
So
remember
that
the
resolver
talking
to
the
end
system
is
typically
not
secure,
which
is
why
some
path
security
actually
makes
a
great
thing
to
pair
with
object
security
so
going
to
back
to
the
high
level
overview
object.
Security
provides
end-to-end
integrity,
production,
it
works
everywhere.
It
is
a
distributed
trust
model
with
minimal
configuration.
Typically,
you
only
have
one
trust
anchor,
but
it
doesn't
provide
any
privacy
protection
whatsoever
and
it
typically
is
not
deployed
all
the
way
to
the
end
user,
which
is
typically
referred
to
as
the
last
mile
problem.
A
Path.
Security,
on
the
other
hand,
provides
privacy,
protection
and
point-to-point
integrity,
protection,
which
is
fantastic,
but
it
doesn't
verify
that
the
data
actually
came
from
the
original
origin.
It
only
verifies
that
that
hop
that
you're
communicating
over
and
for
so
true
security.
It
also
requires
that
every
link
be
protected
and
trusted
right.
So
if
data
is
being
transferred
between
three
or
four
entities
on
the
on
the
internet,
you'd
better
be
able
to
trust
them
all
and
you're,
actually
not
the
one.
A
Typically
querying
them
so,
but
it
does
very
much
solve
the
last
mile
problem
and
solve
some
privacy
issues
as
well
so
path,
security
and
obscurity
are
really
stronger
when
used
together.
Object
security
protects
the
data,
object,
security
ties
the
data
to
its
source
path.
Security.
You
know,
fixes
that
last
mile
problem
all
the
way
to
the
end
user
and
it
provides
encryption
protecting
clients
from
on
paths
eavesdropping.
A
So
we're
going
to
switch
a
little
bit
now
into
other
ways
that
the
dns
has
security
issues,
and
you
know
some
solutions
around
them,
because
the
dns,
you
know
is
primarily
a
spoofable
udp
protocol
based
design
in
order
to
keep
things
low.
Although
tcp
is
used
as
well,
most
dns
responses
are
larger
than
their
request
and
thus
it's
a
great
source
of
reflection
attacks.
So
if
the
entire
world
is
sending
a
whole
bunch
of
resolvers,
you
know
udp
packets
that
are
spoofed
containing
the
source
address
of
the
victim.
A
Well,
all
of
those
responses
are
going
to
end
up
at
the
victim.
Unfortunately,
and
so
this
was
a
bigger
problem
back
in
the
day,
but
it's
still
a
problem
today
and
one
of
the
reasons
that
it
is
we'll
get
to
actually
the
solution
to
that
in
a
minute.
Let
me
talk
about
the
other
side
of
the
ddos
targets
so
because
nearly
all
internet
communication
actually
starts
with
dns
lookups.
A
A
ddos
attack
so
to
battle.
Oh
I'm
missing
an
l
there
to
battle
aggressive
clients.
One
thing
that
has
been
done.
A
lot
lately
is
deploying
something
called
response
rate
limiting
and
it
really
is
saying:
hey,
client
you've
asked
a
whole
lot
of
the
questions
you
know
in
in
the
past
10
minutes
and
in
fact,
they've
really
all
been
the
same
question.
A
I'm
not
going
to
answer
you
anymore.
I'm
going
to
punish
you
and
I'm
going
to
give
you
only
partial
answers
or
no
answers,
but
I'm
going
to
set
the
truncation
bit,
which
means
that
you
should
come
back
over
tcp
please
or
implement
dns
cookies,
either
one
of
those
as
a
solution,
and
that
proves
that
you
have
end-to-end
communication
and
so
udp
spoofing
no
longer
works.
A
This
helps
prevent
overwhelmed,
udp
spoofing
requests
and
is
very
commonly
deployed
these
days
in
multiple
implementations
of
dns,
authoritative
servers,
it's
interestingly,
not
standardized.
Yet
so
there's
actually
some
variations
in
how
it's
actually
deployed
and
configured,
but
it's
very
widely
implemented
and
very
widely
deployed.
At
this
point
to
battle
dns
outages,
you
should
optimize
your
caches
because
there's
been
a
number
of
research.
A
Recent
research
studies
that
have
shown
that,
if
you
are
on
a
network-
and
you
don't
want
to
be
affected
by
dos
attacks,
there's
a
few
things
that
you
can
do-
one
latest
rfc
is
been
published,
called
serv
stale.
That
basically
says
if
you
fail
to
get
an
answer
to
a
question
that
you've
asked
it's:
okay
to
use
an
old
one,
at
least
for
a
while.
A
So
that's
you
know,
helps
protect
your
local
infrastructure
from
outages
and
then,
if
you
can
also
run
a
copy
of
the
root
zone
on
your
local
resolver,
which
is
rfc,
86
8606
and
I
have
a
local
root
project
at
isi
that
actually
allows
you
to
mirror
and
simply
mirror
a
whole
bunch
of
other
zones
as
well.
There's
also
insect
aggressive
caching.
This
is
actually
highly
beneficial
to
prevent
validating
resolvers
from
asking
questions
that
they
know
that
there
isn't.
A
Now.
The
one
thing
to
note
is:
I
gave
you
a
short
overview
about
all
of
the
potential
security
topics
at
a
very
high
level.
Each
one
of
the
topics
that
I
covered,
including
dough,
including
dnfsec,
including
pass
security
and
everything,
could
take
an
entire
30-minute
segment
on
its
own
to
dive
deeply
into
it.
So
we
didn't,
we
didn't
go
into
everything,
that's
related
to
dns
security,
but
we,
these
are
potential
topics
for
future
talks.
A
If
people
want
to
hear
about
them
or
you
can
look
up,
look
them
up
on
on
the
internet
for
other
sources
of
people
that
have
talked
about
them,
but
you
know
for
just
to
pick
a
couple
of
example
ones.
You
can
have
multiple
sources
of
trust
anchors,
for
example.
So
I
talked
about
the
root
of
the
dns
sec
key
having
its
the
dnsec
having
it.
You
know
a
single
trust
anchor
at
the
root,
but
there
are
enterprises
that
actually
also
have
a
trust
anchor
for
their
local
enterprise.
A
Nsec3
is
a
pr
is
a
slightly
more
privacy
protecting
on
the
zone
owner's
side
of
way
to
prove
that
something
doesn't
exist.
There's
many
ways
of
doing
bootstrap
security,
that's
becoming
more
and
more
popular,
like
dane
pgp
keys,
ssh
fingerprints
and
things
like
that,
all
of
a
sudden
become
much
much
more
secure
when
you're
actually
signing
them
with
the
nsx.
A
I
didn't
talk
about
how
dnsec
you
can
actually
know
when
you're
falling
into
an
insecure
zone,
for
example,
so
dnsec
actually
does
a
great
job
of
knowing
letting
you
know
that
you
are
in
the
secure
portion
of
the
dns
versus
the
insecure
portion
of
the
dns
anyway,
there's
a
bunch
of
other
topics,
I'm
not
going
to
talk
about.
I
talked
a
little
bit
about
q
name
minimization
last
time,
there's
algorithms,
strengths
and
rollovers,
which
are
actually
really
being
talked
about
right
now.
How
do
you
deal
with
cryptographic
changeovers
when
algorithms
will
get
get
weeks?
A
Jeff
talked
about
query
loops
earlier
then,
there's
even
unauthoritative
servers.
The
servers
that
you
know
answer
for
incorrectly.
Do
you
know
helps
fix
that
at
least,
and
then
you
know
one
of
the
biggest
ones
out.
There
is,
I'm
sure,
you've
all
been
in
a
hotel
or
been
in
a
coffee
shop
that
you
have
dns
intercepting
middle
boxes.
A
Second
particular
about
white
lies
and
black
lives,
which
I
won't
go
into
as
well
as
minimal
signing
and
there's
many
new
things
in
working
group
states
that
are
that
are
not
included
in
these
slides
yet,
except
for
a
couple
like
oblivious
dns
over
https
that
are
still
being
worked
on.
So
with
that,
I'm
going
to
turn
it
over
to
joao.
Who
is
going
to
talk
about
myths
in
the
dns
and
some
wonderful
misconceptions
and
give
you
new
answers
right,
joao.
A
C
Okay,
good
and
all
that's
left
is
selecting
the
slides,
okay,
so
this
last
this
last
part
this
last
half
hour.
So
is
a
a
collection
of
loose
ends,
but
that
people
come
up
with
frequently
so
we
decided-
maybe
it's
a
good
idea
to
look,
do
a
quick
review
of
common
misconceptions
about
the
dns
or
things
people
think
work
one
way,
but
actually
work
a
different
way.
So,
let's
go
also,
as
I
see
that
a
lot
of
the
people
actually
watching
this
live
are
dns.
C
Experts
feel
free
to
add
a
complement
or
correct
at
the
end.
In
case,
I
got
something
wrong,
so
one
of
the
usual
things
you
see
even
at
the
idf
is
that
when
people
want
to
have
a
solution
for
a
problem
of
disseminating
information
in
a
way,
that's
helpful
siri
that
is
accessible
to
everyone
in
the
internet
and
this
distribution
is
propagating
history.
The
way
it's
often
the
case
that
they
look
to
the
dns
as
the
solution
to
other
problems.
C
So
if
you
ask
for
a
text
record
at
the
given
name,
you,
the
dns
server
is
obliged
to
give
you
all
of
them,
even
if
you
don't
want
it.
So
if
you
are
the
first
one
that
uses
a
given
text
recorder
to
solve
your
problem-
you're-
probably
okay
with
it,
but
some
people-
other
people
will
see
that
and
will
try
to
use
the
same
and
then,
after
a
little
while
you
won't
be
the
only
one
using
that
and
then
the
problem
comes
and
to
illustrate
these
I'm
just
using
this
example.
C
C
If
you
query
for
the
text
records
at
that
name,
you
necessarily
get
all
of
them
and
then
you
have
to
start
parsing
the
ones
that
you
want
from
the
ones
that
you
don't
want
to
select
and
proceed
and,
as
you
see
there
are
the
most
diverse
uses
made
being
made
of
these
records.
So
okay,
so
if
that's
not
the
best
way,
what
is
the
best
way?
Well,
we,
the
current
thinking,
is
that
you
should
just
get
another
type.
The
our
type
code
space
is
big.
C
We
are
not
filling
it
up
at
any
rate
that
will
put
in
danger
the
exhaustion
of
that
space.
So
just
go
ahead
and
try
to
get
one.
It
is
not
hard.
There
has
been
a
myth
that
is
going
to
be
hard,
because
this
would
mean
you
have
to
write
rfc
go
through
the
motion
of
the
working
group
back
and
forth
comments
and
so
on,
and
it
takes
very
long
time
and
then
it
has
to
be
implemented.
Well.
C
So
that's
definitely
the
best
way
of
getting
things
done
for
your
application.
Sometimes
people
also
get
confused
about
separating
the
name
spaces
and
one
way
of
doing
that
would
be,
for
instance,
inventing
your
own
top
level
domain
or
buying
it.
Either
of
those
options
is
not
good,
they
are
hard,
they
are
expensive,
they
are
pointless
and
they
cause
more
problem
than
it's
worth.
C
Well,
I
just
jumped
ahead
of
myself.
I
will
say
that
so
don't
get
a
ldld.
If
you
get
a
proper
internet
one,
you
have
to
go
through
the
whole
icon
process
and
it's
expensive.
It's
very
hard.
It
involves
layers.
It
takes
a
long
time
longer
than
you
might
even
imagine.
It
was
possible
and-
and
it's
probably
also
not
the
solution
to
your
problems,
so
not
a
good
idea.
C
If
you
make
up
your
own
tld,
which
people
have
been
known
to
do
in
the
past,
then
the
problems
are
of
the
sort.
You
don't
have
the
approval
process
to
take
care
of,
but
most
likely
down
the
road.
At
some
point,
you'll
have
clashes
in
namespace
because
if
you
mix
your
own
newly
created
namespace
with
the
internet's
shared
namespace
at
some
point,
things
are
going
to
get
hairy.
There
will
be
clashes.
C
There
will
be,
in
definition
of
which
namespace
you
have
to
address,
to
get
the
information
you
want,
and
it's
generally
not
a
good
idea.
A
network
is
only
good
as
its
cohesion
as
the
participation
of
everyone.
If
you
split
the
naming
space
of
the
internet,
you
are
actually
splitting
the
internet
and
then
you
have
instead
of
one
big
network.
You
have
two
smaller
networks
and
each
of
them
has
less
value
now
jeff
alluded
to
these
and
whether
names
are
for
humans
or
not.
What
is
the
purpose
of
names?
C
Well,
in
the
beginning,
everyone
was
kind
of
happy
with
ascii,
with
just
identifying
machines
and
phones,
as
jeff
described.
Things
got
more
complicated
with
time
and
obviously
one
of
the
things
that
humans
want
is
to
speak
their
own
language
and
write
in
their
own
language
and
that
wasn't
possible.
In
the
dns
there
were
attempts
at
trying
to
define
dns
labels
that
would
be
able
to
encode.
C
Unicode
characters
but
it
didn't
quite
work
out.
Actually,
in
fact,
the
problem
is
not
with
the
dns
itself.
The
nes
itself
would
be
happy
with
any
sort
of
a
stream
of
8b
values
that
it
was
given,
but
the
implementations
and
the
applications
that
make
use
of
dns
started
interpreting
things
in
a
way
that
implied
the
use
of
ascii.
C
C
C
C
I
dare
you
to
click
on
any
of
them,
see
where
you
go,
and
that
would
illustrate
the
problem.
We
are
talking
about.
There's
a
website
to
generate
the
names
with
homoglyphs
and
characters
that
be
in
the
screen
to
be
something
else
to
see.
This
is
the
same
as
the
ones
you
want
to
represent,
but
actually
represent
it
differently,
and
this
is
a
sort
of
problem
which
relates
to
west's
problems
on
security.
C
C
Each
label
can
have
up
to
63
bytes
and
altogether,
a
name
made
of
several
labels
can
have
up
to
355
bytes.
It's
almost
like.
They
wrote
this
in
pascal,
but
applications
do
place
restrictions.
Some
of
them
are
applications
or
common
uses
that
were
already
inherited
by
the
dns
because
they
were
exist
in
existence
before
the
dns
came
into
place,
and
one
of
those
was
the
host
name
restriction
that
jeff
also
mentioned.
C
C
It
was
altered
because,
in
the
beginning
you
weren't
allowed
to
have
domain
names
that
started
with
or
the
main
labels
that
were
started
with
a
number,
and
there
used
to
be
this
famous
company
called
freecom
that
had
a
problem
with
that.
So
we
changed
the
rules
still,
for
instance
today,
and
this
illustrates
the
principle
that
you
should
be
liberal
with
what
it
said.
C
C
For
instance,
in
that
example.several.example.com,
it's
not
clear
to
anyone
just
by
looking
at
it,
where
the
actual
dot
is
where
the
label
begins,
where
the
label
ends,
and
that
poses
problems,
and
it's
it's
kind
of
a
hard
problem
to
solve.
To
be
honest,
so
a
lot
of
these
problems
from
the
fact
that
people
are
more
and
more
thinking
about
the
dns
as
if
it
was
a
search
engine
and
by
god
it
is
not
a
search
engine.
C
C
If
it's
used
in
a
query,
it
might
be
a
wildcard
not
exactly
a
traditional
label.
However,
it's
only
a
wild
card
if
it's
a
play
only
if
it
appears
by
itself,
it's
the
only
character
in
that
level
and
it's
the
leftmost
label
in
any
other
place
or
combination,
it
stops
being
a
wild
card.
So
don't
think
about
parallel,
regular
expressions,
that's
not
what
this
is
about.
It's
just
a
one
instance
of
a
wild
card
and
it
only
works
as
such
when
it
appears
in
in
the
star
currencies.
C
You
cannot
combine
a
star
to
mean
all
the
names
beginning
with
a
if
it
is
stored
in
a
zone.
It's
it's.
It
can
be
just
the
characteristics
just
like
if
it
appears
anywhere
else
in
the
in
the
query
and
asterisk
again
is
is
a
valid
name
in
the
domain
name,
because
the
dns
doesn't
place
the
restrictions
in
the
names
it
can
store.
C
There
is
also
a
distinction
that
people
fall
for
in
this
in
this
when
using
dns
wildcards,
because
often
you
use
the
dns
to
lead
to
websites
and
websites
are
secured
with
certificates
that
allow
wildcards
a
leftmost
label
in
dns
can
match
any
number
of
labels
down
deep
into
the
tree
to
its
left,
but
the
certificate
as
to
be
used
in
x509
certificate
we
use
on
a
website
only
allows
one
level
of
depth,
which
is
a
good
thing.
But
you
have
to
keep
in
mind
that
difference.
C
You
cannot
just
expect
to
get
a
wildcard
certificate
for
all
all
the
names
in
a
tree
and
a
sub
tree
under
a
given
name.
So
just
one
limited
one
level
so
to
illustrate
how
the
dns
wildcards
exist.
I've
created
an
example
zone
under
example.com
with
those
four
text
records
and
there's
a
bunch
of
queries
that
are
issued
towards
that
name,
and
it
will
be
the
exercise
for
the
reader
to
figure
out.
C
What
is
the
response
that
you
would
you'd
get
so
here
is
the
solution
just
to
pervert
it,
and
the
first
one
of
course
matches
exactly
the
second
one
see
those
examples
you
see
doesn't
exist
in
there,
there's
no
label.
That
name
doesn't
exist
in
the
zone
above
so
it
gets
matched
by
the
wildcard,
the
first
record
in
the
zone,
so
those
asking
for
the
wildcard
itself.
You
get
the
result
pack.
C
However,
if
you
ask
for
a
dotstar.example.com,
you
don't
no
longer
get
the
the
wildcard
response.
You
get
that
exact
match
because
it
exists,
and
you
can
see
that
the
wildcat
is
not
the
one
matching,
because
if
you
turn
a
star
to
b
star
which
does
not
exist
in
the
zone
above
and
is
not
matched
by
the
wild
card
as
defined
before
you
get
an
x
domain.
C
C
C
It
can
have
a
given
a
response
code,
r
code,
three,
for
instance,
which
means
nx
domain,
which
translates
to
that
domain
name.
You
asked
me
about,
doesn't
exist,
nor
does
anything
below
it.
It's
the
end
of
the
tree,
there's
nothing
here
or
is
there
that?
Nor
does
the
tree
continue
in
that
direction,
so
try
something
else.
C
There's
a
response
type
that
people
in
the
u.s
call
no
data,
which
is
actually
a
little
bit
ambiguous,
because
it's
not
defined
with
that
name
anywhere.
It's
the
combination
of
the
fact
that
you
get
a
response
with
our
code,
zero,
which
means
there
wasn't
an
error,
and
yet
there
is
no
data
in
the
answer
section.
C
So
if
there
is
no
error,
how
come
I
asked
the
question?
I
got
still
got
no
data
what's
going
on
here.
Well,
it
can
be
both
the
two
things.
One
is
that
you
ask
for
a
type
of
data
that
I
don't
have
infrared
information
for,
if
you
ask
me
for
the
idea
of
ipv4
address
for
a
name,
but
they
only
have
an
ipv6
address,
for
instance.
Well,
I
cannot
have
I
give
you
an
answer
with
data,
but
that
doesn't
mean
the
name
doesn't
exist
and
there
is
any
deposit
type
of
information
there.
C
C
C
C
What
the
cname
stands
for
is
a
canonical
name.
You
ask
for
a
name
and
that
response
to
that
tells
you
that
the
name
you
asked
for
is
actually
this
other
name
over
there
and
because
you
cannot
be
here
and
there
at
the
same
time,
because
what
you
are
telling
in
a
response
is
that
I'm
not
the
name
you
wanted,
you
go
look
somewhere
else.
C
That's
a
source
of
the
cname,
because
that
would
immediately
introduce
two
sources
of
truth
into
the
system
and
you
won't
be
able
to
really
know
which
one
was
the
correct
one
as
a
consequence
of
that
zones
apex,
which
is
where
the
start
of
authority
for
the
name
is
as
well
as
the
name
servers
for
that
zone
are
defined,
cannot
have
a
c
name,
because
it
would
imply
that
there
is
more
information
at
the
same
level
as
a
c
name,
and
that
again
creates
trouble.
It's
not
allowed
by
the
current
definition
of
the
dns.
C
However,
that
doesn't
prevent
people
from
saying
and
thanks
to
the
how
liberal
the
internet
is
in
what
things
it's
willing
to
accept.
Some
people
actually
abuse
this
mechanism
and
mostly
get
away
with
it.
The
itf
is
not
defining
a
proper
way
of
dealing
with
this
use
case,
so
if
this
is
a
good,
successful
worldwide
distributed
database,
surely
all
the
servers
that
authority
for
a
given
a
given
set
of
data
will
have
the
same
information?
C
C
C
C
Usually
there
is,
however,
the
fact
that,
as
was
mentioned
earlier,
there
are
recursive
servers
that
cache
information
and
that
information
is
cached
for
a
given
amount
of
time
if
the
source
of
the
data
changes
that
data
in
the
meantime
that
recursive
server
that
caching
server
will
contain
steel
data
for
the
duration
of
the
ttl.
So
that's
one
way
where
things
can
be
a
little
bit
of
sync,
it's
again
self-correcting
with
time.
C
People
will
answer
differently,
even
with
different
ip
addresses
for
a
given
name,
depending
on
where
you
are
and
how
you
reach
them,
either
by
looking
at
your
ip
address
and
saying.
Okay,
if
your
ipr
is
according
to
my
local
databases
from
north
america,
so
I
will
give
you
an
address
for
you
for
you
to
connect
to
that's
located
in
north
america.
Why
is
a
your
user
that
is
asking
from
europe
will
probably
get
an
ip
address
that
points
to
server
in
europe?
That's
fancy
using
it's
transparent.
C
We
chose
to
publish
an
informational
irc
in
how
to
make
these
a
little
better,
which
was
an
attempt
called
edns,
client
subnet,
which
is
some
sort
of
signaling
of
where
the
client
that's
behind
me
is
located
so
that
I
I'm
asking
he
in
the
client's
behalf.
Give
me
information.
That's
pertinent
to
the
client
in
exchange
you
get
told
by
you
got
filled
information
about
where
the
user
is,
and
this
can
be
exceedingly
granular,
so
you
might
be
exposing
exactly
who
the
user
is.
C
They
are
mostly
not
really
flag
days
as
they
we
people
tend
to
think
about
flag
days,
but
they
are
dates
somewhere.
People
agree
that
they'll
change
the
behaviors
in
their
implementations
or
on
operations
in
operations,
it's
nearly
impossible
to
actually
have
a
a
flag
day,
that's
effective,
so
it's
mainly
a
communications
tool.
C
These
days,
the
dns
is
implemented
in
millions,
probably
of
hosts
around
the
world,
and
even
if
you
only
look
at
servers,
you
see
it's
unwise
and
realistic
to
expect
that
the
whole
deploy
base
would
switch
in
a
given
day,
just
because
you
asked
them
to
that's,
not
how
things
work
anymore.
So
it's
more
more
than
anything,
a
communication
day
to
make
people
aware
of
changes
that
are
desired
and
agreed
to
in
the
dns,
but
they
don't
come
into
effect
as
a
usual
flag.
They
would
a
little
bit
of
a
myth.
C
Is
that
ctes,
the
routers,
the
things
that
you
have
at
the
edge
of
your
home
network
office
network
enterprise
network
work?
Well,
as
the
interest
resolver
well
misconceptions
here,
there
are
several
one
of
them.
The
most
typical
is
that
cpes
are
actually
not
running,
usually
resolvers.
They
are
running
forwarders.
What
is
a
forward
there
is
something
piece
of
software,
has
a
small
little
cache
locally
trying
to
help
you
to
get
further
and
for
future
answers
quicker,
but
it
actually
just
furthers
your
forwards.
C
Your
question
to
a
proper
recursive
resolver
that
does
all
the
heavy
lifting
on
your
behalf.
So
that's
the
first
one
and
then
there
have
been
ideas
of
or
opinions
or
recommendations
of
whether
it's
good
or
bad,
to
have
a
local
recursive
resolver
in
your
cp.
If
you
are
allowed
to
or
or
if
you
are
inclined
to
tinkle
in
one-
and
there
are
both
good
things
and
bad
things
about
these
I'll
skip
this,
because
I'm
going
to
run
off
the
time.
But
the
slide
is
there
for
reference,
not
me.
C
So
it
is
true
that
if
you
make
any
operation
that
you
were
not
doing
before,
it
will
take
additional
time
to
do
that.
Operation.
That's
true
here
and
anywhere
else
you
do,
but
actually
the
dns
has
a
feature
that
might
reverse
these.
In
some
cases,
when
the
nssec
was
defined,
it
was
decided
that
not
only
would
it
sign
that
a
piece
of
information
that
exists
will
be
attested
to
by
a
signature.
C
The
next
secure
nsec
record,
which
says
in
between
two
existing
names
in
this
interval
between
you
names
that
I
know
exist
in
the
zone.
There
is
nothing
so
f,
and
you
can
sign
that,
because
now
the
absence
of
information
has
become
information
that
exists
and
it
can
be
signed.
Now,
if
you
were
to
ask
a
name
server
for
something
that
doesn't
exist
and
it
falls
in
one
of
these
gaps
that
has
been
documented
and
proved
proven
to
to
to
exist.
C
You
can
use
that
previous
answer
as
a
as
a
as
a
way
to
shortcut
the
lookup
and
say
well.
This
domain
doesn't
exist
either
because
it
falls
in
the
gap
identified
by
this
nsx
record,
which
I
have
proof
of
being
true,
so
it
can
become.
It
can
accelerate
dns
lookups
for
the
domains
that
do
not
exist
also
because
the
lookups
for
names
do
not
that
do
not
exist
actually
take
longer
than
any
other
lookup
in
the
dns,
because
the
dns
will
always
try
very
hard
to
find
the
information
you
were
asking
about.
C
C
That
may
happen
is
that
needle
boxes
well,
they
are
not
always
up
to
date
or
are
not
implemented
by
people
that
knew
what
they're
doing
at
the
time
they
did
it
and
dns
being
qualities
at
the
at
the
root
of
everything
you
usually
do
on.
The
internet
is
always
seemed
like
the
neglected
child
of
all
the
protocols
you
wanted
to
go
to
your
website.
C
You
wanted
to
fetch
a
file
you
wanted
to
send
the
mail
you
wanted
to
know
about
the
time
while
the
ns
second
level
dns
enables
all
those
applications
it
stays.
It
does
so
in
the
background.
So
most
people
are
not
aware
of
it
and
it
just
also
happens
to
be
a
very
stable
protocol
and
operation,
so
it
kind
of
fades
in
the
background
and
most
people
don't
think
about
it,
and
then
stuff
happens,
as
I
mentioned
before.
C
If
you
use
tcp,
if,
when
you
use
tcp,
the
only
thing
you
have
to
keep
in
mind
is
that
the
protocol
and
the
state
that
is
kept
in
the
servers
that
serve
tcp
is
a
little
bit
different
than
the
usage
of
eub.
But
the
myth
that
this
cannot
be
used
is
easily
defeated
by.
If
you
look
at
any
standard,
a
big
web
farm
that
always
uses
tcp.
C
C
This
might
not
be
all
there
is
about
that
name
in
the
dns,
for
instance,
if
you
ask
a
caching
server
that
has
some
records
regarding
that
name,
because
it
was
asked
about
an
a
record,
an
ms
record
relating
to
that
name
earlier
on,
and
you
ask
it
give
me
anything
you
have,
it
will
give
you
all
that
it
has
in
its
cache.
It
doesn't
mean
that
it
will
give
you
everything
that
the
authoritative
server
have
on
that.
C
So
you
have
to
be
careful,
particularly
because
this
is
a
debugging
query,
that
if
you
you
know
what
you
are
debugging
and
that
information
you
are
getting
might
be
partial,
and
I
think
that
is
the
last
of
the
myths
we
wanted
to
address
in
this
thing,
because
he
had
30
minutes
to
go
on
it
and
now
it's
time
for
questions,
comments,
insults.
If
you
must-
and
I
hope
my
co-chairs
co-speakers
will
still
be
around
and
able
to
join
me
around.
C
A
A
D
C
Well,
I
like
it,
I
use
it
when
I
need
to
debug,
but
I
know
what
I'm
going,
what
I
should
be
expecting
from
it
for
the
general
public.
Perhaps
it
is
misleading,
so
some
people
are
already
choosing
to
not
implement
implemented
there.
It's
one
of
the
valid
response
codes
that
you
can
get
from
the
dns
and
it's
a
it's
a
valid
choice.
So
by
all
means
go
ahead
and
do
it
you
don't
have
to
implement
things.
You
don't
like
to
be
dns
compliant.
I
wouldn't
deprecate
it.
B
C
Exists,
you
can
use
it
directly
at
the
recursive
server
to
find
out
if
the
recursive
server
is
dropping
certain
records
on
the
floor
because
it
doesn't
like
them.
If
you
know
that
the
record
is
in
the
zone
and
you
ask
ask
the
recursive
server
for
it,
you
get
back
no
answer.
You
can
try
to
trigger
this
and
see
whether,
where
the
name
is
disappearing
in
the
in
the
resolution
process,
you
can
you
can
see
if
it
only
got
partial
information
which
might
be
a
pointer
to
a
misconfiguration
somewhere.
C
It
is
useful,
it's
not
a
solval
thing,
but
it
has
its
use
cases,
but
it's
a
debugging
tool.
It's
not
something
you
should
use
as
I'll
shortcut
my
lookup
time,
because
I
want
to
have
both
the
app
e4
and
ipv6
addresses.
So
please
give
me
any
that's
not
the
way
it's
meant
to
use
and
you
might
be
surprised
by
the
answers
you
get
or
not.
A
F
A
So
that
that
has
been
so
widely
discussed
and
when
you
get
something
as
entrenched
as
the
dns,
you
know
the
thought
of
doing
dns
version.
2
is
the
phrase
that
has
been
kicked
around
for
20
years
as
well.
You
know,
should
it
ever
be
replaced
and
reconsidered
with
something
new.
You
get
huge
issues
with
trying
to
you
know
to
update
that
much
infrastructure.
I
think
it
is.
It
is
scaled,
amazingly.
Well,
I
think
that
if
we
were
going
to
redesign
it
today,
you
know
we
would
certainly
change
some
things.
A
There
are
you
know
one
of
the
biggest
desires
that
people
have
right
now
is.
Can
I-
and
I
talked
about
this
last
time-
can
we
put
more
than
one
question
in
a
packet
and
you
can't
and
and
the
the
the
issues
around
that
are
you
know
that
the
resolver
would
have
to
wait
for
multiple
answers
and
try
and
figure
out
how
to
answer
all
the
questions
and
what
happens
when
you
have
multiple
errors
and
all
those
types
of
problems
exist,
which
is
why
you
shouldn't
put
more
than
one
question
in
a
packet.
A
Even
though
there's
a
myth
that
you
that
you
can
that
the
reality
is
you
can't
because
no
implementation
to
support
it
for
good
reasons?
That
being
said,
I
think
if
we
were
redesigning
it
today,
the
fact
that
so
many
things
are
being
asked
for
you
know.
Jeff
talked
about
the
https
record
and
we're
talking
about
the
a
record
and
the
quad
a
record,
and
you
know
I
mean
how
many
different
things
can
you
query
for
you
actually
want
answers
for
all
at
once.
C
Well,
I
think
it
has
been
quite
well.
I
mean
it
has
been
extended
beyond
whatever
you
want
to
imagine
with
crutches,
even
but
it's
still
fulfilling
a
lot
of
the
purpose
it
was
meant
to
fill,
defining
an
entirely
new
protocol
to
replace
dns
is
going
to
be
extremely
hard,
because
why
would
anyone
put
things
in
a
protocol
that
is
mostly
volume
information
at
the
beginning?
C
If
I
wanted
to
be
provocative,
I
would
say
that
actually
we
have
sort
of
an
opportunity
to
do
a
new,
dns
dns
new
generation
by
abusing
perhaps
this
thing
called
dough,
because
it
allows
a
lot
of
flexibility
and
extension
there,
while
still
retaining
backwards
compatibility
if
he
wants
to,
but
that's
a
discussion
to
have
amongst
all
of
the
idf.
I
guess.
B
B
But
then
you
stress
out
the
transport
protocol
problem
and
the
issue
is
that
a
whole
lot
of
folk,
particularly
clients,
lie
like
crazy.
In
the
dns
sure
I
can
handle
4096
octet
udp,
fragmented
back
at
trains
wrong,
send
them
one
of
those,
and
it
goes
what
happened
you
know,
and
so
this
whole
area
of
the
sort
of
mutated
transport
in
the
dns,
where
udp
is
prime
tcp
is
backup,
has
worked
badly.
B
B
Now
we
point
to
the
web
and
say
it
is
possible
to
create
totally
massive
http
based
service
infrastructure
and
that's
true
totally
true,
but
we
built
a
massive
udp-based
system
with
tcp
is
the
exception
and
there
is
an
awful
lot
of
money
required
to
actually
make
the
dns
work
over
tcp
in
all
cases,
because
throughputs
and
servers
etc.
Don't
actually
work
now
put
that
to
one
point
one
side
and
then
let's
look
at
the
dns
resolution
economy
who
pays
to
get
dns
answers
provided?
B
Well,
it's
not
me,
I'm
just
the
user,
and
so
when
you
say
we
have
to
forklift
the
entire
dns
resolution
infrastructure
up
to
cope
with
tcp,
because
that's
not
where
we
started.
You
immediately
open
up
this
massive
economic
issue.
Well,
who's
going
to
pay!
For
that.
You
know.
I
want
my
dns
to
be
free.
That's
what
it
is
all
about.
B
B
You
can
trust
it
and,
quite
frankly,
if
we
actually
made
the
responses
even
bigger
and
I'm
referring
to
dns
sect
chaining,
which
I
think
is
brilliant,
you
actually
can
make
validation
work
in
a
single
round
trip
time.
This
is
fantastic,
but
you're
carrying
a
large.
You
know
carry
a
load
of
information
sitting
inside
these
sessions.
Will
the
network
handle
it
yeah
sure
this
is
tiny
stuff?
B
Will
the
dns
infrastructure
handle
it?
Well,
we
built
that
for
udp,
so
we're
trying
to
put
21st
century
payloads
into
20th
century
infrastructure
and
that's
where
we're
kind
of
the
cracks
are
really
showing
robert
and
I
think
the
answers
are
as
much
economic
as
they
are
practical,
we're
just
not
quite
sure
how
to
get
there.
F
B
A
B
Well,
this
again
was
this
issue
about
pushing
pushing
the
dns
into
content,
distribution
networks,
and
it
was
sort
of
seen
as
why
do
I
have
to
push
the
entire
elephant.
You
know
out
to
the
front
edge
of
all
parts
of
my
network
when
all
you're
asking
for
is
a
query
relating
to
a
toenail.
You
know,
I
really
don't
want
to
push
the
rest
of
this
craft
onward
and
outward
I'll
just
push
basically
cache-based
answers
and
just
a
fragment
of
the
dns.
If
everyone
asks
for
a
quad,
a
that's
all
I'll
serve
at
the
edge.
B
Oh
you
ask
for
any.
If
I
want
to
be
quick
I'll,
just
say,
here's
an
answer:
the
name
exists.
The
rest
of
the
stuff
is
not
immediately
available
to
the
front
end
shim
that
answers
dns.
It's
back
in
some
database
that,
quite
frankly,
I
don't
have
the
time
to
look
up,
and
I
can
see
that
as
the
way
we
try
and
make
the
dns
go
faster,
because
you
know
the
other
pressure.
That's
on
the
dns
is
it's
too
slow
and
no
matter
what
we
do.
B
Someone
somewhere,
I
predict,
will
always
say
it's
too
slow
and
you
know
it's
almost
the
impossible
target,
but
that's
that's.
I
think
the
other
reason
why
any,
which
requires,
if
you're,
going
to
go
instead
of
any
all,
give
me
everything
you
know
the
answer
is
well.
This
might
take
a
while
and
we're
just
not
patient
enough.
A
C
B
A
Then
well,
I've
been
I've
been
pushing
for
for
pushes.
You
know
using
dns
signed
data
for
forever
right.
So
the
whole
thing
that
I
had
the
whole
slide
on.
You
know
don't
accept
stuff
from
authoritative,
and
you
know,
authoritative,
name
servers
for
which
you
didn't
ask
questions,
that's
moot
in
the
case
of
dns
sec
right,
you
can.
You
can
actually
return
other
data,
and
so
there's
been
discussions
of.
Should
we
start
accepting
stuff.
If
you
know
that
if,
if
you're
talking
to
some
name
server,
that
actually
knows
what
you
want.
A
C
A
Know
if
you
get
this
gigantic
response
back,
you
know
ideally
over
tcp
and
it
contains
an
entire
zone's
data
right.
Here's
here's
the
resolver,
believes
that
it
it
has
the
top
100
domain
seen
by
this
isp
for
the
past
hour,
I'm
going
to
give
it
to
you
all
so
that
you
can
be.
Oh
look,
it's
a
negative
millisecond
answer,
but
it
should
be
verifiable.
C
A
That
being
said,
there's
a
lot
of
people
that
don't
think
that
your
personal
phone
laptop
whatever
needs
to
do
dns
tech
validation
on
it,
because
you're,
your
resolver,
is
doing
it.
My
personal
belief
and
I've
both
won
and
lost
this
battle
in
multiple
places
is
that
if
you
are
using
the
dns
sec
signed
data
to
store
critical
data,
that
you
are
bootstrapping
security
off
of
right
and
dane,
is
a
good
example
of
that
pgp
keys
are
a
good
example
of
that
ssh
fingerprints
are
a
good
example
of
that.
A
I
don't
trust
my
resolvers
a
d
bit
equal
to
one
in
order
to
ensure
that
I
am
accepting
that
data
and
it's
valid,
so
my
belief
is
there's
no
reason
why
we
can't
do
validation
on
individual
devices.
They're,
certainly
fast
enough.
These
days,
that's
not
a
problem,
and
it
allows
you
greater
respect
with
respect
to
being
able
to
bootstrap
security
related
data
that
is
already
encoded
in
the
dns.
B
Well,
I
do
remember,
and
it's
an
ongoing
debate
about
dane:
why
haven't
we
got
pkix
keys
sitting
inside
the
dns
and
getting
rid
of
the
twisted
and
potentially
corrupted
version
of
all
of
those
cas
in
in
the
web?
Pki
and
the
response
from
the
browser
folk
has
been.
You
know
when
I
talked
about
time.
It
really
is
an
issue
and
that,
while
dane,
can
feasibly
do
this
one
of
the
issues
not
all
of
them,
but
one
of
the
issues
is
that
doubt
the
incline
level
performing
validation.
B
There's
nowhere
near
that
intensive
activity
level
that
loads
the
case
efficiently,
you're,
not
combining
strengths
from
other
players,
you're
back
on
your
own
again,
and
because
of
that,
the
time
penalty
is
well.
I
think
for
most
users
would
agree
the
time
penalty
is
excessive
and
various
efforts
have
been
made
to
try
and
get
around
that
and
the
most
successful
I've
seen
is
dns
sect
chaining,
where
you
push
the
burden
of
work
back
onto
the
zone
publisher,
who,
as
well
as
publishing
this,
is
my
rr
records.
This
is
a
signature.
B
They
actually
publish
a
combined
record,
a
dns
set
chain
record,
which
is
the
answers
to
all
the
validation
questions
you
ever
were
going
to
ask
about
me
and
again,
because
it's
dns
sec,
that's
okay,
because
you
don't
have
to
believe
it.
You
can
use
the
answers
to
validate.
What's
going
on
now.
That
means
huge
answers.
B
That
means
pushing
huge
answers
in
tcp
out
into
stubs
and
while
that
link
between
recursives
and
authoritatives
is
relatively
robust
and
handles
large
packets
and
tcp
adequately,
I
wouldn't
say
well
but
adequately.
The
real
problem
is
out
there
in
stub
land,
where
the
amount
of
cheap
crap
that
people
buy.
You
know
there's
an
awful
lot
numbering
in
the
billions.
It's
not
even
clear
how
easily
tcp
gets
out
there
or
fragmented
udp.
So,
while
it's
really
good
to
say,
clients
in
mobile
phones
should
do
validation
and
we
think
we
can
do
that.
The
implication
is
wow.
B
We
need
to
push
large
dns
responses
out
to
these
things.
Gee,
that's
an
issue.
So
that's
why
this
becomes
a
vexed
problem
that
a
good
dnsx
system
should
go
all
the
way
to
the
edge.
We
really
don't
understand
how
logistically
that
can
be
done
within
the
bounds
of
current
infrastructure.
So
that's
kind
of
the.
A
B
Certainly,
as
we've
observed
in
the
analysis,
around
initiatives
like
oblivious
dns,
the
combination
of
who
you
are,
and
the
name
you're
querying
for-
is
extraordinarily
valuable.
It
exposes
what
people
are
doing
absolutely
and
so
in
that
respect,
this
is
a
problem,
because,
when
you
think
about
the
dns,
the
query
never
has
the
query
err.
B
The
query
er
is
the
source
ip
address
of
the
packet.
So
when
I
query
for
pottery.net,
I
go
through
a
recursive
resolver.
The
recursive
resolver
knows
about
me,
but
if
it's
not
in
the
case
at
that
point,
the
recursive
resolver
goes
to
the
authority.
If
the
authority
there
has
no
idea,
jeff
is
asking
all
it
knows,
is
the
recursive
is
asking
on
behalf
of
I
don't
know
now.
Edna
zero
says
no,
no
jeff's
asking
it's
jeff
and
you
go
oh,
but
we've
obscured
it.
This
is
a
slash
24
subnet.
B
On
the
other
side,
the
issue
of
content
distribution
networks,
we've
seen
already
with
the
service
record
that
realistically
folk
don't
want
to
spend
the
time
customizing
the
response
and
steering
you
to
the
closest
entry
point
in
their
cdn
through
the
application
to
cut
the
time
and
throw
the
problem
to
someone
else,
put
it
in
the
dns
to
give
the
right
answer.
I
need
an
idea
of
the
end
user's
location.
B
The
problem
is
addresses
the
location
and
identity
and
to
say
I
just
wanted
to
know
where
you
are.
I
didn't
want
to
know
who
you
are
our
ip
address
infrastructure
says
no,
no,
no,
no
can't
do
that
as
soon
as
you
get
to
know
that
address,
even
at
a
prefix
level,
it's
pretty
clear
who
you
are
and
disambiguating
that
is
nigh
on
impossible
in
the
current
ip
address
infrastructure.
B
B
I
think
in
today's
world
right
now
with
this,
I
agree
with
the
caveats
on
the
rfc
and
there
were
a
lot
and
the
caveats,
as
I
recall
basically
said,
we're
going
to
publish
this,
because
interoperability
is
good,
we're
not
publishing
it,
because
it's
the
best
way
of
doing
this,
we
don't
know
what
the
best
way
is,
but
we
think
this
leaks
like
a
sieve,
and
I
agree
with
that
analysis.
It
leaks
like
a
shiv.
There
really
should
be
a
better
way
of
doing
this,
but
we
don't
know
what
it
is.
B
The
answer
is
we're
ratting
on
no
one
and
we're
making
sure
that
no
one,
not
even
recursive
resolvers,
are
privy
to
the
profiling
of
what
users
do,
and
you
know
we
get
as
much
security
as
we're
prepared
to
wait
for
and
we're
prepared
to
pay
for
and
as
long
as
the
assumption
is,
the
user
is
incredibly
impatient
and
waits
for
nothing.
Security
is
sitting
there
going.
Oh,
my
god,
how
do
we
do
this
yet
still
provide
an
incredibly
fast
sort
of
responsiveness
and
feel-
and
I
don't
understand
how
to
resolve
that.
A
A
You
cannot
optimize
for
all
three
at
once
and
things
like
ecs
and
don't
do
validation,
because
I
need
to
show
the
webpage
faster
is
an
indication
that
it
matters.
You
know
more
to
to
get
speed
over
those
other
two
and
unfortunately,
users
don't
have
the
ability
to
actually
select
what
they
prefer
and
also
users.
Typically,
don't
have
the
the
understanding
to
be
able
to
select
what
they
would
prefer.
B
Although,
although
our
efforts
to
empower
users
have
always
been
in
some
ways,
thwarted
by
the
fact
that
almost
no
one
fiddles
with
the
buttons
and
increasingly
the
application
folk
have
become
impatient
with
that
and
are
now
arming
the
application
with
presets,
you
only
need
to
look
at
the
mozilla
firefox
decisions
about
their
use
of
dough
in
certain
markets
to
sort
of
sense.
This
level
of
impatience
that
saying
users
have
a
choice.
They
can
go
into
settings
and
do
xxx
is
kind
of
speaking
to
the
one
in
a
thousand
folk.
Who
might
do
that?
B
If
you
really
want
to
move
the
dial
for
everyone,
the
application
folk.
I
think
at
large
now
got
to
the
point
of
going.
I'm
not
waiting,
I'm
going
to
arm
the
application
with
the
necessary
behavior
patterns,
sure
you
can
reverse,
but
the
default
settings
the
decisions,
the
applications
making.
So
increasingly
these
days,
users
don't
get.
If
you
will
a
say
in
this,
because
there's
no
expectation
users
will
exercise
that
right
applications,
not
platforms,
but
applications
are
now
making
these
default
choices.
You
know
welcome
to
the
new
world,
that's
just
a.
C
Reflection
of
normal
user
behavior,
I
mean
you
only
care
about
security
with
something
bad
happens
to
you
and
in
the
meantime,
large
e-commerce
platforms
are
showing
have
data
that
a
few
milliseconds
of
delay
in
any
of
the
transactions
causes
a
measurable
loss
of
close
in
those
transactions.
Right,
so
I
mean
you
only
shout
for
the
police
when
you're
bugged.
A
A
All
right,
well,
it
looks
like
we
are
now
at
the
top
of
the
hour.
I
don't
know
if
warren
wants
to
come
back
in
and
close
us
out
or
not,
but
thank
you
for
everybody
that
listened
to
us
today
and
if,
if
we
spoke
too
quick
or
you
missed
something
it'll
be
on
youtube,
I'm
pretty
positive.
If
it's,
I
know
it's
already
been
broadcast
there,
whether
it's
archive
they're
in
the
same
place,
I'm
not
sure
but.
D
Yep,
thank
you,
everybody,
everyone
and
yes,
it
will
be
archived
and
will
be
will
be
on
youtube.
I
believe
that
greg
will
also
post
it
on
the
ietf
website
for
a
link
to
it,
so
people
can
find
it
there
and
thank
you
very
much
to
all
of
the
presenters.
I
know
it
was
a
huge
amount
of
work
getting
organized,
but
I
think
people
really
enjoyed
it
enjoy
not.