►
From YouTube: IETF 101 Thursday Speaker: Rolling the DNS Root Key Based on Input from Many ICANN Communities
Description
The DNS root key rollover is an excellent example of how ICANN takes input from a variety of different communities when it makes policies and even operational plans. The decision to roll the root key five years after the first key was installed was based on a very rough consensus in the technical community, with some participants strongly arguing for different policies. The method for performing the rollover was similarly contentious. ICANN, by its nature, has many different communities who have a say in every major initiative that ICANN takes. These communities include Internet standards bodies, operators, and users, as well as governments, business, and various companies who are particularly interested in the domain name market.
Speaker: As the Chief Technology Officer of the Internet Corporation of Assigned Names and Numbers (ICANN), David Conrad is at the heart the organization's mission to help maintain the security, resiliency and stability of the Internet%s system of unique identifiers that ICANN helps coordinate. Prior to being named CTO, Conrad held several different positions at ICANN, including Vice President of Infrastructure & Technology and General Manager of the Internet Assigned Numbers Authority.
A
A
A
We
are
the
Ayanna
functions
operator
and
the
reason
that
we're
involved
in
this
is
because
rolling
the
KSK
for
the
root
zone
is
part
of
the
Ayanna
names
function
in
back
in
2010,
with
the
help
of
some
people
who
actually
sit
in
this
room,
hello,
Joe,
we
actually
rolled
the
key,
are
created
key
for
the
first
time
and
promised
the
community
that
after
five
years,
we
would
roll
the
key
and
we
proceeded
to
wait
a
little
longer
than
five
years.
You
know
say
after
five
years,
so
it
was
sort
of
after
five
years.
A
We
also
with
the
community
developed
the
KSK
rollover
plan.
We
actually
dragooned
a
bunch
of
the
community,
has
some
usual
suspects
from
the
DMS
technical
community
to
help
us
develop
the
KSK
rollover
plan
and
have
since
been
sort
of
executing
that
plan.
We
began
bowling
in
October
of
2016
because
of
the
way
we
do
things
with
the
route
KSK.
We
could
only
touch
it
on
quarter
boundaries,
so
every
quarter
we
would
do
something
new
and
just
before
we
were
about
to
use
the
new
KSK
and
anger,
we
decided
that
maybe
that
wasn't
the
best
idea.
A
I
canned
us
a
few
other
things
you
might
have
heard
about
the
new
gTLD
program,
which
I'm
sure
is
incredibly
popular.
Within
this
community
we
developed
heel,
D
policy.
We
accredit
are
those
friendly
folks,
the
registrar's
we
actually
create
new,
our
RI
ours,
although
I
don't
think
new
continents
have
been
discovered,
so
the
chances
that
a
new
rir
will
be
created
or
is
probably
relatively
small.
A
We
do
allocate
blocks
of
addresses
to
the
RA
ours
and,
in
the
case
of
addresses
that
are
being
used
for
protocol
purposes,
we
allocate
it
directly
to
the
IETF
we
administer
the
protocol
parameter.
Registries
are
almost
2,000
of
them.
Kim.
Is
that
right,
like
2,000
ish
protocol
parameter
registries,
yeah
they're,
the
IETF
creates
them
and
we
administer
them.
On
behalf
of
the
IETF,
we
attempt
to
herd
the
cats
known
as
the
root
server
operators
through
an
organization
called
RS
sac.
A
We
have
no
control
over
the
root
server
operators
except
the
one
we
operate
in,
sometimes
I
wonder
about
that.
But
we
do
facilitate
the
discussions
among
the
root
server
operators
to
try
to
help
coordinate
the
root
server
system
and
a
few
other
things
I'm,
actually
not
going
to
talk
about
any
of
that.
More
than
all
I've
just
said,
the
eye
counts.
Ecosystem
were
actually
sort
of
three
parts.
There
is
the
community
which
I'm
sure
you
will
be
excited
to
know.
You
are
considered
part
of
the
ICANN
community.
A
There
is
the
organization,
the
folks
actually
do
stuff
and
the
aboard
the
folks
that
actually
tell
us
in
the
organization
to
do
stuff
the
communities
so
they're
a
bunch
of
them
this
chart.
My
comms
team
tends
to
create
very
interesting
presentations
that
you
can't
read.
So
I
will
try
to
explain
this.
So
it's
basically
a
set
of
different
parts
of
the
community
that
include
businesses,
government
and
governmental
organizations,
academia,
internet
users.
We
actually
have-
and
we
attempt
to
provide
a
way
in
which
standard
everyday
internet
users
can
provide
input
into
ICANN
policies.
A
Civil
society
is
that
domain
name,
businesses,
technical
communities
as
well-
and
all
of
these
are
folks
that
we
asked
to
provide
input
into
pretty
much
everything
we
do.
These
communities
actually
shape.
I
can
policies.
We
try
to
the
organization,
actually
tries
to
describe
these
policies
to
all
parts
of
its
community
so
that
they
can
participate
in
developing
the
policies
and
modifying
them
and
beating
us
over
the
head
with
them.
A
Predictably,
this
can
result
in
some
entertaining
discussions.
If
you
enjoy
watching
sort
of
demolition
derbies,
the
DNS
SEC
work
that
I
can
has
been
on
is
almost
entirely
community
driven.
We
have
had
extensive
community
input
on
signing
the
route
developing
the
DNS
SEC
policy
statement,
the
DPS
that's
used
for
the
route
we
have.
These
things
called
the
trusted
community
representatives.
They
are
folks
who
ensure
that
the
key
ceremonies
that
we
perform
are
done
in
a
way
that
everyone
can
trust.
A
As
I
mentioned,
we
have
the
community
help
us
extensively
on
the
development
on
the
KSK
rollover
clam
and
what
is
this
technical
community?
Well,
it's
folks
who
participate
in
the
DNS
op
working
group
here
at
the
IETF
folks
who
participate
in
DNS
Oh
arc,
the
DNS
operations
and
Research
Center,
I,
believe
operation,
analysis
and
Research
Center.
A
There's
this
thing
called
the
DNS
SEC
deployment
mailing
list
that
has
been
in
operation
now
for,
like
a
decade
plus
has
a
bunch
of
usual
suspects
on
it.
The
various
DNS
SEC
related
work
shops
all
over
the
planet
and
icons,
technical
advisory
committees,
including
the
security
and
stability
Advisory
Committee
and
the
root
server
system.
Advisory
Committee.
A
We
also
have
gotten
input
from
the
government
advisory
committee
and
the
at-large
Advisory
Committee
that
last
one
had
being
the
one
that
tries
to
present
the
views
of
Internet
users
with
regards
to
DNS
fact,
most
of
the
input
we've
received
is
perhaps,
unsurprisingly,
coming
from
the
technical
community.
We
have
received
input
related
to
DNS
SEC
from
business
community,
sometimes
and
others,
but
by
far
the
majority
of
input
comes
from
people
who
actually
pretend
to
understand
what
it
is
they're
commenting
on.
A
So
how
did
we
get
to
where
we
are?
The
route
has
been
signed
since
2010.
If
you
remember
way
back
when
a
guy
named
Dan
Kaminsky
came
out
with
a
really
cool
way
of
being
able
to
poison
caches,
the
DNS
SEC
would
actually
prevent.
So
there
was
a
mad
rush,
and
after
a
bit
of
screaming
and
pulling
out
hair,
we
ended
up
coming
up
with
a
way
of
signing
the
root
zone.
A
We
were
able
to
sign
it
in
July
of
2010,
after
which
I
promptly
resigned
and
went
into
death
valley
for
a
couple
of
days,
because
what
else
would
one
do
when
someone
signs
the
route
things
went
along
reasonably
normally
and
in
2013
we
actually
started
the
process
of
developing
a
plan
to
roll
the
KSK,
the
trust
anchor
that
was
generated
when
we
signed
the
route.
A
slight
intermission
occur,
something
called
the
transition
of
the
IMF
functions,
which
sort
of
took
the
oxygen
out
of
pretty
much
everything
that
I
can
did
for
a
couple
of
years.
A
But
after
the
the
transition
was
finished
and
September
30th
of
2016,
we
sort
of
jumped
back
into
the
KSK
rollover
and
proceeded
to
develop
through
community
input
a
plan
and
started
the
roll
over
in
October
of
2016
in
February
of
2017.
We
actually
installed
the
newly
generated
KSK
in
both
of
the
key
management
fills
facilities.
That
I
can
operates,
one
on
the
east
coast
of
the
US,
the
other
on
the
west
coast
of
the
US
in
April
of
2017.
A
It's
interesting
document
was
published,
RFC
81
45,
which
has
described
a
way
in
which
resolvers
could
inform
the
route
of
what
keys
were
actually
configured
for
the
KSK.
That
would
become
interesting
later
on.
In
July
of
2017,
we
published
the
new
KSK
into
the
route
for
the
first
time
the
packets
got
bigger,
nothing
broke.
Surprisingly,
that's
some
folks
figured
that
when
we
grew
the
size
of
the
DMS
response
from
the
route
that
bad
things
would
happen
turns
out.
No
one
really
even
noticed.
As
far
as
we
know,
we
didn't
see
anyone
screaming
an
outrage.
A
A
Why
did
we
do
that?
Well,
I
mentioned
81
RFC
RFC
81
45
that
was
published
by
Dwayne
Wessels
back
in
April
people
started.
Implementing
it
buying
had
I'd
done
an
implementation
based
on
the
draft
and
unbound
implemented
in
April
in
May
dewayne
started.
Collecting
data
and
sort
of
something
interesting
happened.
Things
happen
the
way
they
should,
according
to
fifty
eleven
and
the
way
that
the
yeah
they
forgetting
the
word
when
we
transition
the
keys.
A
That's
not
the
right
word
but
that'll
work
for
me
now
and
we
noticed
that
the
things
were
going
along
as
they
probably
should
have,
except
that
little
space
there
at
the
end
where
the
red
line
is
above
the
blue
line
indicated
that
not
everybody
was
migrating
over
to
the
new
key.
It
meant
that
some
folks
still
had
only
the
old
key
configured
and
that
blue
line
is
actually
even
weirder.
A
That
means
that
people
were
pre
configuring,
the
new
key,
even
though
it
wasn't
in
use,
which
meant
that
their
resolvers
would
fail
everything,
because
the
new
K
wasn't
actually
being
signed.
But
you
know
it
happens.
It's
the
internet.
We
I'm
surprised
every
day
when
it
I
wake
up
and
it
still
works,
but
that
percentage
there
where
things
were
not
where
they
should
be,
where
it
was
above
zero
and
did
not
seem
to
be
going
down
made
us
a
little
nervous.
Of
course,
I
was
planning.
A
There
we
go
so
when
you're,
faced
with
an
unknown,
there's
sort
of
three
options
you
can
take
one
is
you
run
around
with
the
air
on
fire,
which
we
did
a
little
bit
of
to
stay
the
course
which
some
people
suggested.
We
do
and
three
try
to
figure
out
what
was
going
on
in
general,
running
around
with
your
hair
on
fire.
So
not
the
best
idea.
I've
tried
it.
A
Many
times
doesn't
seem
to
come
out
very
well
and
staying
the
course,
given
that
I
really
didn't
want
to
appear
on
CNN
and
time
and
that
sort
of
stuff
seemed
like
a
bad
idea.
So
we
decided
to
try
to
figure
out.
What's
going
on,
we
postpone
the
roll
over.
We
don't
aren't
that
we
didn't
sign
with
20
of
the
KSK
2017.
Yet
we
didn't
pull
it
out.
So
it's
still
there.
It's
still.
We
can
use
it
at
any
time.
A
Modulo
attest
that
I
happen
on
quarters,
but
we
decided
to
try
to
replicate
Dwayne's
results
and
we
did
so.
He
decided
to
further
replicate,
joins
and
I'll
try
to
figure
out
exactly
what
was
going
on,
and
we
wanted
to
try
to
understand
why
so
many
resolvers
at
at
that
time
was
between
four
and
eight
percent
of
the
resolvers
were
not
migrating
to
the
new
key
figured
we'd.
A
You
know,
informally,
consult
with
the
community,
develop
a
new
plan
to
allow
the
key
to
move
forward,
get
our
actual
approval
from
you
know,
sort
of
the
community
one
way
or
another,
because
in
the
previous
incarnation
we
had
sort
of
said
well.
We
agreed
to
roll
the
key
after
five
years
when
we
signed
in
2010
NTIA.
The
US
government
at
the
time
said
well.
That
means
that
you've
agreed
to
do
the
roll
over
after
five
years.
So
you
don't
need
any
additional
permission.
A
A
A
So
the
findings
that
we
got
back
from
our
from
our
friends
was
that
only
20%
of
the
IP
addresses
that
were
showing
up
in
these
80
145
announcements
could
be
tracked
down
and
60%
of
those
were
found
in
dynamic,
address
pools
which
doesn't
make
a
whole
lot
of
sense.
You
know
if
it's
a
resolver,
then
you
know
either
it's
serving
the
person
on
the
laptop
that
just
got
the
dynamic
address,
or
it's
something
else
going
on
that
it.
We
didn't
fully
understand
and
it
looked
like
about.
A
25%
of
the
addresses
were
forwarding
from
other
resolvers,
which
meant
that
there
was
a
layer
of
indirection
that
would
be
very
hard
for
us
to
peek
through
we
didn't
find
a
smoking
gun
single
cause.
We
did
run
identify
a
couple
of
bugs
and
a
couple
of
resolver
implementations,
and
as
a
result
of
that,
we
didn't
really
have
a
clear
path
forward.
A
Since
we
didn't
have
a
path
forward,
we
decide
you
know
to
do
what
I
can
the
organization
does
when
we're
confused,
we
go
and
ask
the
community
hopefully
get
someone
to
tell
us
what
to
do
so.
We
actually
did
an
informal
collection
of
input
using
a
mailing
list
that
had
been
set
up
when
we
first
started
discussing
doing
the
KSK
rollover
KSK
rollover
at
ICANN
org.
That
mailing
list
still
exists
if
you're
interested
in
these
sorts
of
things,
I
recommend
you
jump
on
it.
A
It's
pretty
low
volume
right
now,
but
hopefully
that'll
pick
up
when
we
come
closer
to
breaking
the
internet.
Again,
that's
a
joke.
We're
not
gonna
break
the
internet.
Results
of
the
discussion
on
that
informal
mailing
list
was
that
there's
no
real
way
to
measure
how
many
users
are
going
to
be
impacted
by
rolling
the
route
KSK.
The
information
we're
getting
is
sort
of
a
sample
of
resolvers
and
those
resolvers
are
actually
early
adopters,
because
the
only
code
that
has
the
8480
145
announcements
is
very
new
code.
A
It's
likely
that
better
measurements
will
come
along
in
the
future,
something
called
KSK
Sentinel,
which
is
wandering
its
way
through
the
DMS
process.
Right
now
does
look
like
it
could
provide
us
with
information,
that's
actually
from
the
end
users
perspective,
and
that
would
be
very
helpful,
but
that's
gonna
take
a
little
while
the
consensus
on
the
mailing
list
was
that
we
should
just
roll
the
key.
You
know
we.
A
We
acknowledge
that
some
resolvers
are
going
to
have
issues,
but
you
know
that's
what
happens
on
the
internet
stuff
breaks
and
then
you
just
adjust
and
move
on,
but
in
order
to
try
to
minimize
the
amount
of
stuff
that
breaks,
we're
going
to
aggressively
outreach
and
do
these
kinds
of
talks
and
go
into
even
other
places
to
talk
about.
You
know
how
the
KSK
role
is
going
to
happen
and
all
that
sort
of
thing
and
all
the
same
time
we'll
continue
to
collect
data
so
on
the
topic
of
collecting
data.
A
So
these
trust
anchor
reports
right
now
we
have
access
to
data
from
almost
all
of
the
root
servers
ABCDEF
I
j,
k,
l
and
m,
and
the
you
know
the
initial
analysis
that
we
had
done
came
from
BDNF.
The
initial
analysis
that
Dwayne
had
done
was
from
a
and
J,
but
all
of
the
the
statistics
were
more
or
less
sort
of
the
same
we're
using
some
software
that
Dwayne
has
actually
developed.
It's
actually
really
nice,
and
you
know
that
gives
you
an
idea
of
sort
of
what
we're
looking
at
in
terms
of
the
data.
A
But
what
are
we
actually
seeing?
Well,
so
this
is
from
September
and
you'll
notice
that
there
was
a
bit
of
a
spike
and
that
spike
seems
to
have
studied
around
20
ish
percent
I'm
a
little
higher
than
that.
The
black
line
is
the
percentage.
The
red
and
green
lines
are
the
numbers.
If
you
look
on
the
what
is
that?
That's
just
flexi
as
a
joyful
thing
on
the
left
side
of
the
scale-
and
you
know
so.
A
You
know
it
went
up
from
about
4
to
8
percent
upwards
of
20
plus
percent,
which
is
also
a
bit
disturbing,
because
that's
the
wrong
way.
This
should
be
going
to
should
be
going
down,
not
up
why
the
jumpin
in
January
our
best
hypothesis,
is
that
there
was
a
completely
unrelated
security
fix
that
went
into
a
DNS
server
implementation
that
caused
people
to
update
their
DNS
server
invitation
and
that
resulted
in
more
80
145
announcements
because
its
default
on
and
that
resolver
and
the
same
with
bind.
A
A
You
know
that
may
be
one
reason:
we're
seeing
all
these
2010
only
type
things,
but
you
know
we
don't
really
know
another
interesting
bit
of
data,
so
these
are
the
unique
IPS
added
per
day
the
odd
bit
about
this
as
the
number
sort
of
stabilizes
you
know
more
or
less
plus,
four
five
plus
or
minus
five
of
ten
percent,
but
that
doesn't
make
a
whole
lot
of
sense.
Right
I
mean
you
know.
A
These
are
resolvers
that
people
are
sort
of
adding
you
know
when
they
go
and
update
software
and
something
like
that,
but
they're
sort
of
stabilizing
in
the
14.
What
is
it
14
15k
per
day
of
new
IP
addresses,
and
that
is
odd,
because
it's
consistent,
it's
not
you
know
it's
not
going
up
and
down
enough
it's
not
going
up.
It's
been
anyhow,
so
another
thing
we
don't
fully
understand
cumulative
IP
addresses
over
time
and
that
you
know
that
line
there.
The
Green
Line,
you
know,
sort
of
in
a
very
nice.
Even
growth
is
weird
it.
A
A
We
recently
enough
about
a
third
of
those
are
reporting
only
KSK
2010.
Why
don't
know
we
could
be
forwarders
could
be?
You
know,
VMs,
as
we
mentioned
there
were
a
couple.
You
know
relatively
speaking,
1500
that
went
from
one
cascade
2010
only
to
2010
plus
2017,
which
is
the
right
thing
to
happen,
but
it's
actually
not
a
whole
lot.
It's
only
1500
out
of
seven
hundred
and
thirty
thousand.
So
that's
also
disturbing.
A
A
Okay,
so
these
are
folks
who
are
announcing
only
the
2010
KSK,
which
means
that
when
we
roll
the
key
these
folks,
these
resolutions
are
going
to
start
failing,
and
these
are
you
know
in
many
cases
these
are
customers
of
ISPs
right.
So
you
know
we
have
Comcast
there
at
9,000,
unique
IP
addresses
this
isn't
Comcast
itself,
you
know
Comcast,
you
know
they're
operated
by
some
really
intelligent
folks
and
do
a
really
good
job.
It's
folks
behind
Comcast,
you
know
people
you
have
business
clients,
presumably
or
something
yeah.
You
know.
A
B
Dan
York:
do
you
want
questions
now
or
do
you
want
to
wait
or
take
enou?
Well
so
I
just
curious
about
that.
The
the
14,000
you're
seeing
14,000
new
resolvers
reporting
data
every
day,
yep?
Are
you
seeing
a
corresponding
drop
off
from
you
know
the
like?
Do
you
see
some
that
are
no
longer
reporting
things,
or
is
this
just
cumulative
you're,
adding.
B
C
C
A
Okay,
yes,
that
that
is
a
known
aspect.
I,
don't
say
flaw,
but
an
aspect
of
81
45
that
there
is
no
mechanism
by
which
we
can
assure
these
aren't
spoofed,
and
it
could
be
very
well
be
some
four
hundred
and
pound
person
and
their
bet
basement.
Sending
80
145
queries
for
the
route
just
to
screw
with
us.
That
would
really
depress
me,
though
so
what's
happening
next,
we're
gonna
continue
to
try
to
figure
out
what's
going
on,
but
we
do
have
very
limited
data.
This
has
been
a
real
challenge
for
this
exercise.
You
know.
A
You
know
they're
not
a
lot
of
good
communication
channels
into
this
community,
because
they're
resolver
operators
and
anyone
and
everyone
can
run
a
resolver
I
use,
draw
it
on
we're
on
one
on
my
laptop
and
if
you
know
some
weirdo
called
me
up
and
said
you
know,
what's
your
trust,
anchor
I'd
probably
get
very
nervous.
So
this
is.
This
has
been
a
on
going
challenge,
but
we
are
you
know.
What
else
can
we
do?
We're
gonna
get
continued
to
try
to
figure
out.
A
What's
going
on,
we're
gonna
continue
to
revise
the
the
plant
forward,
based
on
input
that
we
receive
from
the
community
and
given
what
data
that
we
have,
we
are
going
to
ask
for
formal
advice
from
icons,
advisory
committees.
It's
part
of
the
I
can
process,
the
advisory
committees
represent
parts
of
the
community
and
they
will
provide
us
with
formal
they'll,
actually
provide
the
board
with
formal
advice
and
those
include
the
security,
stability,
Advisory
Committee
and
the
route
service
system,
Advisory
Committee,
and
then
we
are
going
to
request
formal
approval
from
icons
board
to
move
forward.
A
A
We
do
have
some
quite
technical
folks
on
ICANN
board,
but
we
also
have
non-technical
folks
and
ultimately,
it
will
be
icons
board
that
will
be
making
the
decision,
because
this
you
know
obviously
can
have
impact
on
both
the
internet
as
a
whole
and
I
can
as
an
organization,
and
they
have
a
fiduciary
responsibility
to
the
organization.
So
they
get
to
take
the
bullet
on
this
community
assistance.
A
And
you
know
we're
hoping
to
get
those
folks
to
work
with
their
customers
and
their
participants
to
update
the
systems
that
support
the
the
KSK
2017
and
try
to
tell
us.
You
know
why
things
are
happening.
The
way
they
are
because,
honestly,
it's
a
bit
confusing
we're
trying
to
figure
out
how
we
can
make
this.
This
list
of
IP
addresses
more
available,
but
it
gets
really
kind
of
bogged
down
and
you
know
whether
or
not
IP
addresses
are
PII
and
gdpr
and
lawyers
and
the
stuff
that
just
causes
my
eyes
to
cross
moving
forward.
A
A
As
part
of
the
informal
discussions
we
weren't
able
to
identify
any
measurable
by
criteria
by
which
we
would
say
yes
or
no,
so
we're
just
gonna
say
yes,
because
that's
what
we
do
we're
going
to
continue
doing
an
extensive
outreach.
You
know
as
much
as
we
can.
We
will
continue
to
publish
more
observations.
You
know
as
much
data
as
we
can
get,
and
you
know
if
people
have
ideas
on
how
to
interpret
that
data
or
other
ways
in
which
we
can
obtain
data.
We're
looking
forward
to
hearing
from
you.
A
Most
importantly,
we
have
a
public
comment
going
on
part
of
the
ICANN
process
is
that
we
write
up
stuff
and
then
we
throw
it
to
the
community
for
a
actual
public
comment
period,
sort
of
somewhat
equivalent
to
a
last
call
within
the
ITF
and
say
you
know,
please
tell
us
what
you
think
provide
that
input,
so
we
are
in
the
process
of
that
public
comment
period.
It
ends
on
April,
2nd
and
I
strongly
strongly
request
a
beg,
I'm
begging
here
to
please
provide
input.
A
A
Presumably
sometime
around
there
a
sec
we'll
be
able
to
pry
the
input
back.
We
will
publish
a
final
plan
and
the
the
message
that
the
roll
is
contingent
on
that
final
plan.
You
know
the
board,
we
will
tell
the
board.
You
know
this
is
the
input
from
the
community
and
currently
the
plan
is
that
we
will
request
the
board
permission
to
roll
the
key
on
October
11th
and
then
on.
October
11th
I
will
be
on
vacation.
A
Implications
well
so
in
on
October
11th
of
2018,
assuming
the
plan
doesn't
get
modified.
We
know
we
know
100%
certainty,
that
some
resolvers
are
going
to
break
yeah
I
mean
that
the
data
is
very
clear.
Resolvers
are
going
to
only
that.
Only
have
our
KSK
2010
when
they
trying
to
validate
stuff
that
signed
with
KSK
2017
are
not
going
to
work.
Even
I
know
that
currently,
that
number
is
between
20
and
30%,
but
we
don't
know
what
that
means,
because
we
don't
know
how
many
users
are
buying
those
resolvers.
A
We
believe
and
I
think
the
technical
community
believes
that
the
vast
majority
of
users
who
are
being
subjected
to
DNS
SEC
validation,
are
behind
very
large
resolvers,
like
Google's,
Public,
DNS
or
Comcast,
or
quad,
nine
or
those
folks,
and
we
have
no
fears
about
things.
These
folks
are
professionally
operated,
they're
not
going
to
screw
up
the
KSK
role.
We
believe,
but
that's
just
a
belief.
A
We
don't
actually
have
concrete
data
to
prove
that
at
this
stage,
just
as
an
aside
to
the
ietf
as
you're
developing
protocols
that
have
impact
on
say,
critical
infrastructure
and
be
really
good
to
have
measurement
points
within
those
protocols,
so
that,
when
you're
in
a
point
where
you're
actually
going
to
be
mucking
with
a
critical
infrastructure,
you
can
actually
measure
things.
So
just
as
a
future
aside.
That
would
actually
be
something
that
would
be
nice
to
think
about.
A
Instead
of
how
we've
done
it
with
the
NSF,
which
is
add
it
later
really
I,
don't
need
that
now,
I
keep
getting
these
announcements
on
my
computer.
It's
a
final
decision
by
ICANN
board
will
be
non-technical
because
we
don't
have
the
data
to
give
the
board
to
make
a
technical
decision,
and
if
it
was,
if
we
did
have
the
data-
and
they
wouldn't
need
to
make
the
decision,
because
the
technical
data
would
say
what
we
should
do.
So
the
board
will
be
doing
a
risk
benefit
analysis
on
limited
data.
A
A
Yes,
they're
all
in
this
room,
I
think
so
it
would
be
useful
to
have
more
input.
You
know
and
if
you're
repeating
stuff,
that
other
people
have
said
in
the
public
and
that's
fine,
that's
helpful
that
you
know
shows
that
there's
more
people
than
just
the
usual
suspects
who
believe
the
KSK
world
should
continue.
If
you
think
maybe
it's
continue.
That's
really
useful
information
as
well.
I
do
know
that
some
folks
are
going
to
come
out
against
the
KSK
role.
That's
fine!
We
just
need
that
input
and
that
again
is
the
URL.
A
D
A
E
A
A
F
I
use
a
manual
and
we
we
caught
them
in
two
ways.
One
is
the
unique
number
of
addresses
per
day.
So
basically,
we
literally
look
at
the
as
the
query
lock
were
dreamed
since
drange
to
since
all
this
data.
To
that
query,
log
contains
all
the
unique
which
are
contains
all
the
addresses.
We
basically
counted
the
unique
addresses
per
day
quickly
and
we
community.
We
accumulate
overall
letters
so
and
the
second.
The
second
thing
is
we
do.
We
also
do
the
accumulated
part
where
we
have
a
day.
E
G
Thank
you
very
much
for
this
Jason
ITF
diversity
and
height
issues.
Thank
you
for
that.
One
possible
community
David
that
don't
know
if
I
can
speed
anything
about
reach
to
the
operating
system,
vendors
and
the
Linux
distro
people,
because
I
suspect
that
some
of
these
trust
anchors
are
being
embedded.
So
it's
unlikely
we're
going
to
see
this
I
think
saying.
G
The
commercial
distribution
is
from
Oracle
and
HP
and
stuff
like
that,
but
maybe
some
some,
some
substantial
traction
there
with
the
Linux
folks,
just
embedding
something
hard
wording
into
whatever
they
distribute,
with
with
the
code
base
for
a
resolving
name,
server
and
also
the
next
follow
of
that
is
also
CPE
vendors
because
of
the
most
of
what
the
stuff
they're
probably
embedding.
Maybe
that
is
just
cutting
pasting.
G
A
We
have
we
actually
very
early
on.
We
made
contact
with
the
guy
who
maintains
DNS
mask,
which
is
actually
the
most
commonly.
As
far
as
we
can
tell
embedded
DNS
related
thingy,
that's
put
into
CPE
he'd
indicated
he
said,
he's
never
gonna
support
50
11,
but
he
does
have
sort
of
a
separate
daemon
that
sits
there
and
goes
and
polls
to
see.
If
the
root
ksk
has
changed
from
the
I
on
a
web
site
and
then
pulls
it
down.
A
Works
right,
so
at
this
stage
the
CPE
have
some
confidence
in
most
very
few,
as
far
as
I
know
actually
enabled
in
a
sec.
So
you
know,
obviously,
if
you're
not
doing
the
D
in
a
sec.
All
of
this
talk
is
completely
meaningless
to
you.
With
regards
to
operating
system
vendors,
we
have
been
in
contact
with
a
number
of
Linux
distribution.
Folks
in
Red
Hat,
for
example,
we
probably
door
was
actually
on
the
community
team
that
was
doing
this
yeah
and
he's
sitting
right
over
there
and
it
by
and
large
they've
been
supportive.
A
G
H
Paul
Hoffman,
co-author
of
81
45
81
45,
says,
don't
send
the
data
if
you're
not
doing
validation.
Now
we
don't
actually
know
that
they're
doing
validation,
but
we
know
that
there
was
a
chunk
of
code
that
was
hard
to
implement
that
if
they
were
doing
that,
they
shouldn't
have
done
it
if
they
weren't
validating.
G
H
So
yeah
so
you're
correct.
We
don't
know
that
it
in.
We
did
actually
do
a
fair
amount
of
research
on
the
open
source
software
and
we
didn't
see
any
that
would
send
the
80
145
data
if
it
was
not
validating.
But
that
doesn't
mean
there
isn't
a
funny
configuration
because
we
did
find
some
funny
configurations
that
were
politely
not
called
bugs,
but
they
were
bugs
before,
and
so
there
could
be
something
like
that.
That's
not
what
we're
sort
of
assuming
now
gonna
have
to
close.
I
It's
like
twenty
years
ago,
when
you
must
old,
a
machine
in
a
state
they're
at
the
same
address
for
a
long
period
of
time,
which
is
also
kind
of
a
basic
assumption
to
5011.
But
in
fact
the
architectures
changed.
There's
before
run
out.
That's
carrier
gate
great
map,
there's
an
old
workloads,
there's
there's
all
kinds
of
overloading
of
addresses
and
services
that
there's
no
way
to
see
past
this
data
and
find
out.
I
I
J
A
J
A
J
We
have
taken
account
the
privacy,
extensions
and
so
the
the
second
second
observation
is
regarding
this.
Those
IP
addresses
that
we
have
investigated
if
they
are
validating
or
not.
We
we
we
look
at
for
those
same
IP
address
his
overs
asking
for
dns
keys
or
des
records,
or
how
we
did
that
the
investigation
I
mean
it's
basically
for
Poe.
He
said.
J
A
Yeah,
that
is
one
of
the
the
interesting
aspects
of
this
is
we're
getting
indications.
That
cannot
be
true
right.
So
clearly
the
data
as
I
said
the
more
we
look
into
that
data,
the
more
we
realize
that
that
data
isn't
actually
telling
us
anything,
that's
helpful,
and
that
is
the
sort
of
the
consensus
of
the
sort
of
the
expert
opinion
that
led
us
to
say:
okay,
we're
just
gonna
roll,
the
key
on
18
on
11
October
2018,
regardless
of
what
the
80
145
data
says,
and
so.
B
Thanks
Dave
for
coming
out
and
giving
providing
this
level
of
information
and
doing
this
kind
of
thing,
I
think
that's
really
important
there
I
I
guess:
I'd
have
two
things.
One
is
just
putting
my
marketing
communications
kind
of
hat
on
I
would
say:
I
would
encourage
you
to
look
at
how
to
focus
on
like
a
landing
page
like
you,
I
didn't
see
anywhere
in
there.
You've
got
a
great
URL
I.
B
Can
that
org
slash
KSK
roll,
which
drops
you
in
a
landing
page,
is
a
whole
bunch
of
stuff
and
I
encourage
you
to
push
that
rather
than
the
long
ones
that
go
across
there,
that
my
old
eyes
can't
even
read
on
some
parts
of
that.
So
I
encourage
you
to
do
that.
The
other
piece
is
I.
Think
the
one
of
the
things
so
last
fall.
I
gave
a
presentation
at
the
ISC
to
security.
Congress
talked
about
this
and
I
had
been
big
letters.
What
are
you
doing
on
October
11th?
B
It
was
great
and
it
was
the
day
before
you
announced
the
delay.
So
then
I
had
to
kind
of
go.
Oh
sorry,
but
the
there's
a
lot
in
the
enterprise
space
I
think
who
don't
they
had
no
idea
about
it
much
of
this
and
when
I
was
talking
to
them
and
they're
all
operating
large
private
networks
that
they
do
their
own
dias,
dia,
DNS
lookups.
B
A
Now-
and
we
have
tried
on
several
occasions
to
gothe
yeah
through
like
the
CTO
for
the
CIO
forum
and
those
sorts
of
organizations
to
try
to
get
more
access
into
the
enterprise
communities,
but
that
is
a
very
large,
very
diverse
community.
Yes
and
it
has
been
challenging,
but
thank
you
yes
and
just
roll
the
damn
thing.
Well,
yes!
Well,
it
is
yeah.
I've
heard
that
before
again,
thank
you
very
much
for
taking
the
time
and
listening
to
me,
ramble
on
just
you
know,
provide
input.
Please
thank
you.