►
From YouTube: IETF115-DNSOP-20221108-0930
Description
DNSOP meeting session at IETF115
2022/11/08 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
C
D
E
F
C
Hello
welcome
welcome
group,
well,
team
is
remote,
but
he
sent
his
regards
of
course,
and
he
will
be
presenting
the
document
updates.
Yeah.
C
Exactly
we
can't
it's
a
good
tradition
here:
the
chairs
myself,
Suzanne
Tim,
our
area
director
Warren,
he's
here
in
the
room,
the
chat
room.
We
have,
of
course,
the
jabber
room,
but
also
integrated
in
the
meter,
Echo
and
zulip.
So
there
are
the
links
in
the
reference.
C
The
minutes,
Paul,
Maybe,
yeah
and
Tim
will
be
back
up,
or
vice
versa.
So
Tim
will
also
take
notes
together.
Thanks.
C
Okay,
so
we're
an
ITF
working
group,
so
the
node
well
applies
here.
Everything
you
contribute
mentioned
at
the
microphone
will
be
recorded
as
part
of
the
of
is.
The
node
will
applies
to
your
work
in
your
contributions,
so
we
we
expect
that
you're,
aware
of
the
node
well
part
of
the
node.
Well,
is
the
IDF
conduct
kind
of
sorry
code
of
conduct?
C
Well,
there
are
six
points
here
mentioned
summary
be
respectful
to
each
other.
If
you
think
code
of
conduct
is
violated,
please
reach
out
to
the
dean
sub
chairs
the
meeting
tips
we
are
in
hybrid
meeting,
so
everybody
in
the
room
is
asked
also
to
register,
find
the
the
meet
Echo
light
client,
you
can
scan
the
quad
code
or
just
use
the
the
full
client.
C
Also,
we
are
asked-
or
it's
ITF
policy
here
at
ITF
115-
to
wear
masks
at
any
time,
except
for
the
presenters
here
are
allowed
to
take
off
their
mask
other
things
for
especially
for
the
people
in
the
room.
The
on-site.
If
you
want
to
go
to
the
my
queue,
use,
the
mid
Echo
light
app
or
the
mid
Echo
app
raise
your
hand
and
then
you
are
asked
to
come
over
to
the
microphone.
C
C
G
Yes,
oh
yeah,
good
morning,
all
and
thanks
for
thanks
for
being
here
so
we'll
we'll
kind
of
go
through
this
because
I
know
we
have
some
busy
stuff,
as
you
know,
in
the
isgq
5933
Biz,
which
is
scheduled
for
the
teletracker
I
believe
in
January
in
December
and
catalog
zones,
which
has
warrants
as
the
action
but
I
think
they
need
an
update
from
the
authors.
G
So
authors
I,
know
you're
there.
You
may
have
to
step
up
a
little
bit
and
do
that,
but
everything
else
is
moving
along
for
those
avoid.
Fragmentation
has
been
approved
and
Ben
and
I
are
going
to
work
on
the
write-up
on
that
and
we'll
we'll
sort
of
Chase
that
down
here
very
shortly.
So
next
slide.
F
Service
B
I.
F
H
C
Because
for
some
reason
the
audio
becomes
worse
and
worse.
G
G
Is
there
anybody
in
the
room?
That's
against
moving
this?
The
working
group
last
call
please
speak
up
or
we'll
consider
that
the
working
request
call
approval
and
we
can
move
on
from
there.
I
know
we
have
one
comment
from
Brian
that
needs
to
be
addressed
so
and
we
will
get
that
address
from
Daniel
and
part
of
the
reason
we're
expecting
moving
documents
as
long
as
we're
not,
we
need
more
help
from
working
here
on
that.
G
E
G
I'll
I,
just
that
was
all
really
the
comment.
I'd
like
to
just
get
more
folks
on
the
working
group
last
call
to
sort
of
help
us
get
those
things
moving
along
and
I'll
kick
over
to
benno
then
and
I
apologize
me
Deco
seems
to
be
hating
me
this
morning.
I
Jeff
Houston
yeah,
responding
to
the
previous
slide.
Please,
yes,
I
think
it's
pretty
sad
that
we're
moving
a
document
into
working
group
last
call
with
only
one
comment
and
yeah.
The
thing
that's
kind
of
changed
is,
of
course,
there's
now
a
DNS
directorate
and
as
chairs
I
believe
you
have
the
ability
to
actually
request
an
early
review
by
a
member
of
the
directorate,
and
so
one
of
the
ways
to
actually
resolve
this
is
rather
than
go.
Oh
working
group
last
call,
even
though
no
one
has
read.
I
E
Yep
yeah.
Thank
you.
Jeff.
That's
actually
really
helpful
to
have
the
reminder
that
the
80s
have
spun
up
the
DNS
directorate,
and
that
is
another
resource
we
have
as
far
as
managing
our
documents.
Thank
you.
G
I
G
C
Okay,
oh
so,
oh
so
other
current
working
group
documents,
we
think
an
author
think
is
close
to
working
group
last
call,
so
not
just
any
specific
order.
Here
we
see
blue
note
is
not
optional.
The
RFC
84.99
base
there's
now
discussion
on
two
terminology.
Yes,
at
the
the
belly,
wig
I
think
that
discussion
is
Billy.
Victor
historical
is
well.
J
C
C
All
TLD
will
be
presented
in
a
minute
or
in
five
minutes
the
Nissan
version.
The
authors
think
they
Incorporated
all
the
feedback
from
the
mailing
list.
They
think
it's
ready
for
working
group
last
call.
We
will
schedule
it
and
please
have
a
second
look
at
the
document
and
give
feedback
on
the
mailing
list
and
Dinesh
error
reporting
my
good
progress
and
will
be
presented
later
this
this
session,
so
we're
making
good
progress.
Overall,
we
just
just
had
a
meeting
with
the
author
of
dinosaur.
Oh
sorry,
dinasek
bootstrapping,
I.
C
Think
the
author
also
think
it's
ready
for
working
group
last
call
the
Incorporated
a
number
of
the
feedback
from
the
working
group.
There
was
some
discussion,
so
we
also
probably
want
to
make
progress
here.
I
will
discuss
it.
Also
with
the
author
and
as
revalidation,
it
will
be
some
other
authors
helping
with
the
document,
because
some
one
of
the
authors
has
another
job
in
other
priorities:
rights,
more
work,
unisec
automation
that
one
there
will
also
be
in
another
author
or
author-
should
be
added
to
the
document.
C
It's
in
good
shape.
Maybe
another
revision
and
we'll
also
ask
for
a
working
group
last
call
from
the
from
the
working
group.
The
domain
verification
techniques
will
be
up
will
be
presented
and
updated
if
time
permitting.
Let's
put
it
on
the
agenda
yesterday
and
caching,
resolution
failures
will
be
presented
so
all
in
all
yeah.
We
make
a
good
progress
with
the
documents
they're
either
close
to
working
group
law
or
making
good
progress.
So
thank
you
and
just
adopt
that
SVC
bit
svcb
Dane.
C
No
well
I
will
skip
these
slides.
These
are
possible
candidates
for
adoption.
New
work
in
the
working
group
I
will
reach
out
to
some
of
the
documents
authors
because
it
didn't
have
much
attention
on
the
mailing
list
yet,
but
there's
big
continuous
development
in
updates
of
the
documents,
so
it
should
get
more
attention
of
the
working
group
or
by
the
working
group
good.
C
C
This
agenda
I'll
have
somewhere
okay.
Well,
this
is
the
current
agenda
for
the
working
current
working
group,
yeah
I
will
yeah
I
will
go
over
the
slides,
it's
not
so
for
consideration.
We
have
three
presentations
and,
if
time
permitting,
other
work
has
priority.
But
if
time
permitting,
we
have
these
two
presentations
at
the
very
end
of
the
of
the
session,
we
can
start
let's
get
started.
I
will
load
the
next
slide
here.
So
you
do
the
introductions.
E
Okay
yeah,
so
we
had
a
lot
of
discussion
on
the
mailing
list,
both
on
the
process
and
the
substance
around
the
all
TLD
draft
and
the
goal
today.
You
know
where
we
gave
it
we're
giving
it
a
strictly
limited
time
and
a
strictly
limited
scope,
but
Paul
has
very
graciously
agreed
to
come
up
and
and
speak
to.
E
E
If
it
seems
we
do
have
open
issues
that
could
be
closed
by
further
discussion,
we'll
schedule,
an
interim
or
some
other
way
of
dealing
with
those.
But
if
it
seems
we've
said,
everything
and
Views
are
not
likely
to
change
further.
We
will
move
to
working
group.
Last
call
thanks
everybody
for
your
patience,
and
we
will.
We
are
getting
this
this
draft
towards
resolution
of
one
kind
or
another,
so
Paul,
if
you
wouldn't.
K
E
B
So,
given
that
I'm
gonna
do
a
mediumly,
brief
presentation,
chairs
are
going
to
run
a
mic
line.
If
there
are
people
who
want
to
say
things
that
haven't
been
said
on
the
list
or
new
and
such
and
a
new
deck
is
being
shared,
yeah.
B
C
C
B
H
Right
so,
if
there's
a
quick
spot,
the
the
similar
somewhat
dot
home
TLD
has
has
a
few
hints
for
validators
to
try
and
reduce
leakage
of
traffic.
I
was
wondering
whether
anything
like
that
should
be
said
for
an
adult.
Like
you
know,
returning,
you
know
proof
of
non-existence
of
BS,
while
not
sending
any
other
queries.
H
You
can
still
return
proof
of
non-existence
off
the
whole
domain,
which
includes
proof
of
the
existence
of
its
DS,
so
it
seems
to
work
I'm,
not
index
domain.
Sure.
K
E
The
pro
yeah,
the
problem
is
that
it's
listed
in
the
manifest,
but
it
does
not
appear.
C
To
actually
but
in
the
meat
Echo
IDC
twice
the
the
chair,
slides,
explain
it.
B
E
A
M
E
Wow
this
is
yeah.
This
is
new
on
me,
with
apologies,
so
Roy
was
next.
L
Okay,
yeah
I,
okay,
yeah,
so
actually
DNS
error
reporting
will
be
the
next
slide
sets
and
also
hackathon
results,
because
DNS
error
reporting
was
a
major
Topic
at
what
we
worked
on
during
the
hackathon.
L
There
were
five
in-person
persons
working
on
it
and
one
remote
and
yeah
so
Roy
asked
me
better
were
also
some
other
projects
worked
on.
So
what
I
said?
Why
don't
you
present
those
other
two
and
then
I'll?
Do
the
hackathon
visuals
for
DNS
air
reporting.
L
So
next
slide,
yes,
so
indeed
one
of
the
projects
was
working
on
netina's,
resolver
inbound,
so
nothing
is,
is
a
bill.
Dns
Library
works
on
primarily
by
dick
Franks
and
Dick,
told
me
once
if
it's
nice
weather
he
goes
out,
plays
golf
and
if
it's
rainy,
then
he
works
on
nattiness
and
he
lives
in
London.
So
it
rains
quite
often
and
but
nothingness
is
actually
a
early
adopter
of
many
of
the
stormers
that
are
drafted
index
up
so
worthwhile
to
to
look
at.
L
If
you
want
to
compare
it
with
your
own
implementation
or
to
see
how
it's
how
your
draft
draft
is
implemented.
L
So
we
worked
on
a
bindings
for
nutinas
with
lip
inbound
and
that
involved
adding
some
new
functions
to
lip
and
mount
to
synth
packets
directly.
So
this
is
not
quite
finished,
but
it's
coming
next
slide.
Please
and
the
other
interesting
hack
we
did
besides.
The
initial
reporting
is
implementation
of
handling
of
encrypted
client,
hello
in
a
proof
of
concept.
L
Library
called
connect
by
name
so
the
server
name
indications
is
one
of
the
holes
in
the
Leaky
privacy
boat
that
leaks
the
the
name
to
which
TLS
session
is
set
up
and
encrypted
clients.
Hello
is
the
solution
to
make
that
private
as
well.
So
we
have
this
proof
of
concept,
library
that
sets
up
connections
and
under
the
hood,
does
everything,
but
it's
good
right,
happy,
eyeballs,
Dane,
you
can
specify
policies
to
say,
I
want
all
the
DNS
lookups
to
be
opportunistically
private
or
authenticated
privates
and
yeah.
L
So
Philip
Holmberg
worked
on
that
for
the
library
looking
up,
svcb
and
https
records
and
using
the
encrypted
client
hello
configuration
parameter
to
set
up
the
encrypted
clients
hello.
With
this
with
this
one
server,
we
know
that
support
is
which
is
default.io
and
filipio.
Also
later,
in
this
session
talk
about
the
policy
option.
That
is
also
a
part
or
came
out
of
the
connectpoint
name
projects
and
next
slide.
Please.
L
So
yeah
as
we,
we
have
a
really
good
time
so
I
think
it's
also
for
other
people
working
on
drafts
good
to
participate
in
the
hackathon,
if
not
for
the
importion
or
the
direct
feedback
on
your
drafts,
then
for
for
the
foot,
because
it
was
amazing
and
we
also
learned
that
DNS
error
reporting
rocks
next
slide.
L
So
this
is
these
are
all
the
people
that
worked
on
it
I
see,
there's
one
name
missing:
we
also
had
a
remote
participant
on
Cape
and
next
slide.
Roy
is
going
to
take
over
to
talk
about
the.
N
Thank
you.
Sorry
thanks
William
I'm,
Roy
Adams
I'm,
one
of
the
two
authors
for
DNS
error
reporting.
N
Where
are
we
just
smart
introduction?
Dns
air
reporting
builds
upon
extended,
DNS
errors.
It
reports
to
the
operator
of
an
authoritative
domain
instead
of
reporting
back
to
the
client.
That's
what
rc8914
is
useful
to
begin
with
the
resolver,
where
a
small
change
I
will
get
to
that
in
a
minute.
The
resolver
now
indicates
support
for
reporting.
N
The
authoritative
Sheriff
had
then
sends
an
agent
domain
in
an
IDI
in
his
zero
option.
Sorry
I'll
take
this
off
eating
a
zero
option
alongside
a
regular
response
and
then
the
resolver
sends
errors
to
the
report.
Receiving
agents
format
is
actually
DNS.
Query.
It's
pretty
straightforward.
We've
seen
it
working
during
the
hackathon
also
during
the
hackathon
folks
were
so
enthusiastic
that
we
immediately
thought.
How
can
we
improve
this?
How
can
we
make
this
more
efficient
next
next
slide?
Please.
N
One
thing
to
make
it
more
efficient
so,
instead
of
using
the
report,
instead
of
usually
queue
type,
no
to
send
a
report-
and
you
want
something
back
that
you
can
cash
initially,
we
just
had
no
error
or
any
domain.
Caching
NX
domain
caching
is
a
problem
because
you
will
cut
off
the
entire
string
for
the
the
entire
domain
for
that.
But
if
you
have
a
tax
record,
if
you
just
query
using
a
text
record,
then
you
can
tailor
a
response,
so
you
can
basically
send
a
specific
text.
N
Record
back
with
a
TTL
that
is
stay
loot,
so
it
can
dampen
the
query
load
accordingly
and
now
we
also
have
that
the
resolver
must
indicate
support.
So
what
we
used
to
have
is
that
you
just
Spam
with
unsolicited
Edina
zero
option
in
a
response.
Every
time
always
the
reason
we
change.
That
is
not
because
it's
frowned
upon
to
just
include
unsolicited
DNS
option,
edns
options.
The
reason
for
that
is
to
avoid
later
on
cascading
error
reports
over
error
reports
of
error
reports.
N
So
we
change
that
another
thing
we
we
we
changed,
and
this
is
a
small
optimization
which
is
really
really
handy.
So
in
the
formatters
query,
you
used
to
have
the
extended
DNS
error
as
a
as
a
label
before
the
domain
name.
That
was
broken.
It's
easy
to
have
it
after
domain
name.
N
So
before
the
underscore
error.
If
you
have
read
the
draft
and
the
reason
for
that,
you
have
now
the
error
code
in
a
consistent
Place,
always
it
doesn't
change
depending
on
the
domain
name
length
depending
on
the
remaining.
That's
broken
all
right
next
slide,
please
we
have
a
few
implementations.
I'll
list
them
quickly,
Willem,
who
was
just
up
here
in
Unbound.
N
You
can
actually
test
it
now
by
by
going
to
these
open
testing,
resolvers
and
next
slide.
Please
we
have
Stefan
boxmeyer
Stefan
had
an
implementation
he's
named
a
drink,
I
hope
it's
an
acronym.
Otherwise
it's
a
really
funny
one.
N
It's
an
authority
server,
easily
adjustable
for
experimentation,
etc,
etc,
works
as
well
and
the
report
processing.
So
this
is
basically
the
next
step.
Once
you
receive
the
reports,
you
can
now
process
them
and
do
something
about
it.
Next
slide.
Please
Shane
was
there
as
well.
N
Shane
worked
on
an
Implement,
a
proprietary,
authoritative,
server
called
Trax.
This
is
ns1's
proprietary
server.
He
mentioned
it
was
straightforward
on
the
authoritative
side
and
you
can
configure
unique
report
receiving
agents
per
server
next
slide.
Please
Mark
Andrews
submitted
a
ticket
for
buy
nine
I'm
just
going
to
leave
you
to
that.
I'll
I'll
leave
it
to
Mark
to
to
come
to
the
mic
later
on,
to
explain
what
it
means:
I,
don't
want
to
say,
they're
going
to
implement
it.
N
It's
basically
a
ticket
that
says,
have
a
look
at
this
draft
and
maybe
implement
it
in
the
future.
Tom
Carpe
from
home
I
apologize,
I,
didn't
list
him
in
the
initial
slide,
with
all
the
people
at
the
desk
at
the
at
the
at
the
table
and
Tom
Carpe
worked
on
an
ldns
version,
a
development
Branch,
a
version
for
for
ldns
and
ldns
test
DNS
test
test.
Ns.
Sorry.
O
N
Can
now
easily
be
used
to
fake
an
error,
reporting
support,
authoritative
server
next
slide,
please
oh
yeah!
This
is
this
is
what
I
wanted
to
make
clear,
so
version
03.
We
thought
it
was
stable
enough
after
some
experimenting
we
made
some
optimizations,
not
super
major
changes,
but
some
optimizations,
so
after
Dash
o4
comes
out,
I
haven't
submitted
it
yet
after
that
comes
out.
We'll
give
it
a
few
days
a
few
weeks
to
let
to
let
people
read
it,
and
then
we
will
ask
the
working
group
chairs
to
consider
a
working
group.
N
Last
call
all
right
if
you
have
any
questions
or
suggestions,
there's
of
course
the
mailing
list.
Yes
up
at
itf.org,
it's
not
really
useful
to
to
to
to
to
Mill
me
personally,
I'll
do
my
best,
but
your
what
I've
noticed
is
that
your
questions
often
are
relevant
to
the
entire
working
group,
which
I've
got
a
fair
amount
of
feedback.
That's
now
in
the
draft
and
better
wording,
etc,
etc,
but
send
your
questions
and
suggestions
to
the
mailing
list.
That's
it!
Thank
you.
Thank
you.
H
N
Thank
you,
Victor
DM,
I
think
the
question
is
related
to
the
problem
of
cascading
errors
when,
when
they,
when
a
reporting
resolver
forwards,
the
broken
error
query
in
order
to
get
it
reported
to
a
forwarder.
The
forwarder
might
then
do
ediness.
Sorry,
it
might
might
do
error
reporting
as
well,
and
then
you
get
cascading
error
reports
now.
N
One
idea
is
to
make
sure
that
when
a
domain
starts
with
underscore
ER,
then
don't
send
this
option
in
the
in
the
in
the
query
that
you
send
out.
So
don't
send
the
edns
option
in
queries
about
error
reports.
That's
that's
one
way
to
do
it.
The
other
way
to
do
it.
If
you,
if
you're
a
forwarder,
are
you
actually
doing
error
detection
right
I
mean
that's,
that's
a
question
with
the
forwarder.
N
If
you
do
do
error
detection,
you
basically
need
to
implement
the
draft
accordingly,
so
I
will
add
some
language
into
the
documents,
basically
regarding
forwarders
or
basically,
clients
that
may
not
do
error
reporting
that
may
set
the
the
the
reporting
option.
Thank
you.
Victor.
B
Okay,
so
some
people
have
been
asking:
what
is
the
status
of
the
draft?
The
actual
status
I
can
do.
This
is
held
by
working
group,
Warren
and
I
co-authors.
Ask
for
working
group
plus
call
shares
ask
for
changes.
We
did
those
the
chairs
seem
to
have
accepted
those
changes.
B
There's
a
new
draft
now
and
then,
once
that
newest
draft
came
out
a
whole
bunch
of
discussion
happened,
I'm
going
to
be
covering
the
discussion
here,
but
basically
the
status
is
we're
still
in
held
by
WG.
The
chairs
are
still
trying
to
decide
about
working.
You
know
moving
it
into
working
group
last
call.
So
it's
still
just
a
draft
next.
B
There
are
two
top
issues
and
I
think
probably
two
of
the
only
issues
that
really
matter
here.
This
is
the
first
one.
I've
got
two
slides
on
this
and
I've
got
two
slides
on
the
second
issue.
B
So
basically
we
have
this
text
which
says
what
resolvers
should
do
when
when
it
comes
to
dot
alt
and
the
current
text
basically
says
treat
it
like
anything
else,
it's
not
special.
Some
people
on
the
list
want
to
make
it
special.
B
That
is,
they
want
to
put
text
in
this
document
and
say
resolvers
should
or
must
do
something
here
and
the
difference
being
that,
if
the,
if
the
text
says
a
resolver
should
or
must
be
doing
something,
then
the
hope
is
that
resolver
operators-
I'm
sorry
resolver
vendors-
will
read
the
draft
go
I'm
supposed
to
do
something
with
this,
and
do
it
next
slide.
B
So
the
reason
for
putting
in
a
muster
should
is
to
is
to
get
resolver
implementations
to
not
send
things
to
the
root.
So
the
you
know
that's.
The
only
reason
to
do
it
is
to
is
to
have
an
effect.
The
desired
effect
is
fewer.
Queries
will
go
to
the
root
because
they'll
just
get
swallowed
by
the
resolver
itself,
and
that
has
been
shown
to
to
be
to
work
in
the
past.
Dot
onion,
the
whatever
the
RFC
that
created
dot
onion,
says
resolvers
should
not
send
these
on
and
some
revolvers.
B
Don't
some
resolver
implementations
don't
and
some
resolver
implementations
ignored
that
and
they
do
pass
it
on
and
and
their
root
server
operators
sitting
in
the
room.
They
can
look
at.
You
know
how
many
dot
onion
queries
they
get
and
such
so
it's
definitely
not
zero.
But
if
you
look
in
the
code
for
some
of
the
resolvers,
they
swallow
dot.
Onion,
okay,.
B
B
B
Take
yourself
out
of
the
queue
or
so
the
the
the
benefit
is
for
adding
this
code
would
be
to
the
root
servers.
It
does
not
help
a
resolver
to
have
more
code
in
it.
You
know
more
code
can
always
cause
more
errors.
It
also
doesn't
hurt,
as
we
know,
because
this
is
true
for
Don
onion.
It's
been
true
for
years
in
a
couple
of
the
resolver
software
and
no
one's
had
any
problems.
B
So
really
the
question
is:
what
do
we
want
to
do
here
about
saying
that
a
resolver
software
should
or
must
do
something,
and
then
the
last
bullet
here
is.
The
note
which
is
this
is
an
informational
document
which
is
fine,
but
it's
sort
of
weird
for
an
informational
document
to
tell
all
of
the
resolver
operator
all
the
resolver
vendors
out
there,
what
they
should
or
must
do
so.
Would
you
do
you
want
to
stop
and
do
this
one
first
or
go
to
the
next.
B
So,
okay,
now
we're
switching
topic
next
slide.
This
is
the
second
major
issue
that
came
up
on
the
list
after
we
posted
the
last
draft,
which
is
some
people
said:
oh
no,
we
shouldn't
be.
We
shouldn't
be
using
the
current
design,
which
is
just
never
allocate
dot
alt
in
the
root.
We
should
allocate
it
and
then
have
it
Point
as
a
d
name
to
as112..
B
We
have
rfcs
on
that.
This
was
brought
up
five
years
ago
when
the
document
was
in
working
group.
Last
call
the
first
time
it
wasn't
accepted
then,
but
now
there's
a
discussion.
Maybe
we
should
really
think
of
this
now.
B
The
reason
for
doing
this
that
was
stated
on
the
list
and
is
backed
up
by
data
is
that
it
seems,
like
resolver
implementations,
do
better
with
a
delegation
at
caching
the
fact
that
it's
delegated
then
remembering
that
they
have
a
negative,
a
negative
answer
in
their
cash.
So,
as
you
can
see,
if
you
go
to
that
link,
Dwayne
has
a
long
presentation,
but
basically,
when
they
dropped
in
a
delegation,
the
cash
is
kicked
in
much
better.
B
So
this
is
not
an
easy
fix,
because
in
fact
the
whole
point
of
this
document
has
to
date
been
this
TLD
will
never
appear
in
the
root.
So
when
we
say
to
somebody
hey,
please
use
this
TLD
you're
safe
to
use
this
TLD
for
all
of
your
alternative
stuff.
They
knew
that
anything
that
leaked
wouldn't
would
never
pass
the
root
servers.
That
is,
they
would
come
back
with
an
NX
domain.
What
doing
as112
says?
Is
we
already
have
a
set
of
of
authoritative
servers?
B
That
will
then
include
this,
for
who
always
give
back
the
right
NX
domain
answer,
but
this
means
that
to
somebody
who's
writing
something
that
might
use
this.
They
know
that
in
fact,
it'll
go
to
the
root
server
and
then
go
to
some
other
server-
that's
not
controlled
by
them
that
they
are
relying
on
to
send
an
NX
domain.
So
that's
a
very
different
promise
to
the
people
who
would
be
using
the
dot
alt
domain.
B
It
would
require
new
agreements
with
Ayanna,
but,
and
some
people
said
oh,
we
can't
do
it
because
you
know
you
can't
put
these
in
in
the
root
Zone.
You
can
make
changes
to
what
Ayanna
does
it
has
to
be.
You
know
asked
officially
and
stuff
like
that,
but
saying
this
will
never
happen
is
simply
silly.
The
ietf
gets
to
say
what
happens
in
the
root
Zone
on
a
technical
level.
So
that's
not
an
argument
against
it,
but
the
basic
argument
against
it
is
that
this
is
a
complete
redesign.
B
This
is
saying,
instead
of
simply
don't
do
this
we're
going
to
design
it
this
way
and
then
just
as
a
side
note,
Warren
and
I
have
talked
about
this.
If
the
working
group
wants
to
go
for
this,
it
needs
to
start
as
a
completely
new
draft,
because
a
lot
of
the
text
in
the
document,
it
would
be
simply
wrong.
That
is
the
lot
of
the
text
in
the
document
is
assuming.
This
is
not
going
to
be
something
in
the
root
Zone,
and
neither
of
us
are
interested
in
this.
B
E
Yeah,
there
has
been
quite
a
lot
of
discussion
on
the
list
several
times
over,
but
the
reason
why
we're
doing
this
is
so
that
everybody
knows
where
the
where
the
document
stands
now
and
if
there's
anything
you
feel
has
not
been
said
or
needs
to
be
said
and
again
given
where
we're
at
and
where
we
have
been
in
the
discussion.
You
know
we
do
have
a
few
minutes,
but
this
is
my.
This
is
mostly
sort
of
a
status
setting
Wes.
P
Thank
you,
Wes
herediker
uscisi,
not
with
my
icann
board
hat,
not
with
my
baby
hat,
but
with
my
root
server
operator
hat,
because
I
think
that's
the
one
you
wanted
right.
Yes,
exactly
right.
P
So
when
I
think
about
you
know
what
should
be
done
so
hey.
Thank
you
for
putting
the
the
document
together.
In
the
first
place,
the
right
thing
is:
don't
send
packets
to
the
DNS
that
shouldn't
go
to
the
DNS
right,
so
don't
leak,
yeah
right,
don't
leak
and
and
Dot
alt
is
supposed
to
be
the
switch.
That
says:
don't
use
it
weirdly
enough
right,
but
it
will
happen.
We
know
it
will
happen.
I
do
see,
queries
for
DOT,
onion
I,
don't
see
a
ton
I,
don't
worry
about
the
massive
dot
alt.
P
P
Yeah
and
I
recognize
that
the
code
issue
sure,
but
we
already
have
a
code
issue
for
pre-existing
stuff.
B
P
B
P
Have,
and
so
one
of
the
things
I
was
going
to
add,
is
we
won't
get
hundred
percent
deployment,
but
the
reality
is
we
shouldn't
saturate
the
DNS
system
with
anything
so
I?
Don't
really
care
about
the
root
server
system
as
much
because
there's
a
lot
of
them
I
care
more
about
the
constrained
lengths
that
you
know,
maybe
actually
these
extra
queries
might
actually.
P
You
know
affect
people
way
down
the
line
or
something
like
that
as
far
as
it
going
into
an
informational
document,
it's
still
guidance,
you
know,
I
mean
the
reality
is
it
should
must
are
not
enforceable
in
standards
documents
either
right.
So
you
know
I,
don't
have
an
issue
with
putting
should
and
musk
kind
of
information
in
there
before.
P
P
B
P
E
B
I
was
going
to
say,
and
that's
not
required.
The
requirement
for
761
is
either
standards
track
or
isg
approval,
which
this
would
have
isg
approval
eventually.
J
Foreign
I,
don't
like
the
idea
of
as112,
it
just
seems
like
a
hammer
for
what
shouldn't
actually
really
get
to
DNS
in
normal
working
operations.
I
do
have
a
question
though,
and
this
might
be
better
for
the
root
operators.
What
do
we
perceive
as
the
load
increase
of
leakage
of
alt
into
the
normal
DNS
space?
J
I
mean
how
big
of
a
problem
is
it
actually
in
just
leaving
this
out
in
the
sense
that,
if
we
don't
even
say,
should
or
must
what
is
the
actual
load
impact
and
how
much
of
a
problem
would
that
be?
If
we
had
that
leakage.
E
I
can
switch
hats
long
enough
to
answer
that,
one
as
in
my
yes
putting
on
the
roots
overhead
that
Wes
and
I
actually
passed
back
and
forth,
the
the
actual
impact
would
be
negligible.
It's
just
a
matter
of
in
general.
What
you
get
is.
Is
there
there's
an
awful
lot
of
stuff
that
goes
to
the
roots
that
shouldn't.
P
M
There
Elliot
Lear
here,
okay,
so
a
couple
things
first,
thanks
Paul
for
taking
on
the
work
thanks,
Warren
and
thanks
chairs
and
working
group
for
working
through
this
as
the
independent
submissions
editor.
This
came
to
me,
as
you
saw
through
the
DNS
work
and
in
in
the
gns
work,
depends
on
this
work:
completing
and
so
again
I
thank
the
working
group
for
for
working
on
this.
M
There
is
we've.
We've
had
a
discussion
about
a
second
level
registry.
You
pulled
out
the
text
there
in
the
preview
in
the
current
version.
Only
you
sort
of
half
did
that,
and
there
is
still
text
in
the
draft
that
says
that
name
service
name
systems
should
add
a
unique
field
to
the
left
of
dot,
all
and
I'm,
going
to
channel
Martin
shenzenbach,
whose
users
said
you
know,
do
or
do
not.
If
we're
not
going
to
have
a
registry-
and
let's
not
have
that
convention
either,
it
would.
C
B
M
D
C
D
Q
Go
ahead
on
the
topic
of
Aquarius
to
the
root,
the
I
think
that
the
right
answer
here
is
to
say
that
the
from
the
Stubbs
perspective,
a
recursive
resolver's
Behavior,
should
not
be
visibly
altered
by
this
informational
document.
Q
So
while
it's
advantage,
while
it's
advantageous
to
to
the
root
for
recursive
resolvers
to
synthesize
some
responses
locally
for
DOT,
alt
and
and
I,
think
that's
a
good
thing.
That
synthesis
should
not
result
in
a
behavior
change.
Q
That's
observable
to
the
stub
resolver,
and
so
what
that
means,
in
my
view,
is
that,
if
we're
going
to
talk
about
that
kind
of
synthesis,
we
need
to
have
some
very
special
language
about
how
to
handle
DNS
sec,
because
because
I,
if
I,
ask
the
if
I
ask
my
resolver
whether
dot
alt
exists,
I'm
asking
whether
or
not
all
exists
in
the
root
and
I
want
a
DNS
set
validated
I
want
I
want
the
correct,
signed
and
SEC
record
to
tell
me
there's
no
such
thing
and
that
can't
be
synthesized
locally.
Q
So
I
I
don't
object
to
local
synthesis
in
general,
but
I
think
that
it's
not
it's
not
straightforward
to
implement
at
a
minimum.
You
know
the
simplest
way
to
do.
It
is
to
just
disable
local
synthesis
if
the
do
bit
is
set,
for
example,
essentially,
what
we're
saying
is
you're
allowed
to
do
local
root
and
since
dot
all
these
will
never
be
in
the
root.
Q
Q
I
want
to
just
make
one
last
editorial
comment
that
the
draft
constantly
uses
the
has
adopted
the
terminology,
the
DNS
context,
as
the
namespace
anchored
at
the
Ayanna
root.
Q
I
find
this
terminology
very
confusing,
because
DNS
is
a
protocol.
It's
a
protocol
that
anybody
can
instantiate
an
instance
of
not
just
Diana,
and
there
are
a
bunch
of
alt
routes
that,
prior
to
this
document,
have
always,
in
my
experience,
been
described
as
implementations
of
DNS
the
protocol,
just
not
the
the
Ayana
root,
so
I
I
just
have
trouble
reading
the
document
because
of
that.
B
Okay,
if
you
can
send
suggested
text
on
that,
that
would
that
would
be
helpful,
I
think
to
everybody.
E
Right,
thank
you
and
sorry
to
sorry
to
step
on
you
Ben.
We
had
closed
the
queue
after
then,
but
Robert
Rob
did
get
in
the
queue
as
the
responsible
ID.
So
I'm
gonna
you
get
a
special
pass.
Yes,.
O
Sir
Robertson
just
to
say
thank
thanks
thanks
for
working
group
for
working
this
I
know
it's
a
sort
of
contentious
topic
and
tricky,
so
I
get
it
I.
O
Think
we're
close
to
rough
consensus
here,
so
I
think
we're
making
progress
so
I
think
that's
great
I,
love,
someone
to
say:
I,
don't
know
anything
about
DNS,
but
I
just
want
to
make
one
comment
as
an
individual
in
terms
of
the
the
must
or
way
state
must
or
should
statements
is
saying,
is
it
the
the
stub
resolver
shouldn't
be
sending
this
stuff
on,
because,
obviously
you
should
be
filtering
out
at
that
stage
and
if
so,
can
we
put
the
constraint
on
that
and
not
the
recursive
resolvers
is
what
is
that
one
option?
B
An
option
but
I
think
that
the
folks
who
wanted
it
for
the
recursives
know
that
asking
the
stubs
not
to
do
something
is
sort
of
silly.
You
know
it's
like
saying
to
your
your
dog.
You
know,
don't
do
that,
and
the
dog
goes
great.
I
heard
the
do
that
part,
whereas
recursive
resolvers,
we
know,
in
fact
the
resolver
sought
vendors
actually
do
the
right
thing.
A
lot
so
I
think
that
that
was
more.
We
can
also
add
it
in
for
the
stubs,
but
that
that's
almost
wasted
text.
Okay,.
O
And
I'll
absolutely
defer
to
the
experts
on
this
and
then
the
end
of
the
other
point
I
want
to
make
in
terms
of
the
document
status,
I,
I'm,
lesser
keen
on
the
isg
approval
thing
that
could
be
slightly
trickier.
So
is
the
reason
why
this
can't
go
through
a
standards
track
now
and
if
the
isg
then
says
actually
we
wanted
to
be
informational
would
downgrade.
It
is
that.
B
B
C
Step,
thank
you
and,
and
either
the
the
people
that
were
cute
and
well,
the
the
queue
was
locked.
Please
send
also
your
comments
or
your
questions
to
the
mailing
list,
and
next
next
up
is
Dwayne.
R
All
right,
hello,
everyone
so
I'm
here
to
talk
about
the
draft,
which
is
about
caching
negative
caching
of
DNS
resolution
failures.
This
was
last
presented
at
ietf
113.
next
slide,
please.
R
So
as
a
quick
reminder,
there
are
some
recursive
name
servers
that
seem
to
be
really
really
bad
at
caching
resolution
failures
or
remembering
that
when
they
asked
for
for
for
resolution
that
they
didn't
get
an
answer,
the
the
graph
there
on
the
right
is
from
the
the
presentation
to
this
working
group
at
ihf113
and
there's
there's
more
supporting
data
there.
R
R
So
there's
a
little
definition
in
in
the
draft
that
says
a
DNS
resolution.
Failure
occurs
when
none
of
the
servers
available
to
a
resolver
provide
any
useful
response
for
a
particular
name
type
in
class.
R
So,
just
to
be
clear,
we're
not
talking
about
you
know
a
timeout
at
one
of
the
name.
Servers
available,
we're
talking
about
timeouts,
say
from
all
of
the
name.
Servers
available
or
NX
domain
are
not
sorry,
not
NX
domain
refused
from
all
of
the
name
servers
available,
something
like
that.
So
next
slide.
R
So
since
the
last
version,
this
is
probably
the
most
significant
change
where
some
of
the
requirements
have
been
rephrased.
Previously
there
was,
there
was
language
in
in
the
draft
that
said
a
resident
Evolution
failure
must
be
cached
against
a
specific
query,
Tuple
of
name
type
and
class
and
server
IP
address
and,
and
now
that
requirement
is,
is
changed
quite
a
bit
where
it
just
says
that
a
resolver
must
have
a
cache
for
resolution
failures,
and
the
purpose
of
the
cache
is
to
eliminate
repeated
queries
that
cannot
be
resolved.
So
it
doesn't
really.
R
You
know
it
doesn't
say
it
has
to
be
cached
by
Tuple.
That's
now
sort
of
an
implementation
dependent
detail.
Folks
can
choose
how
to
how
to
do
that.
However,
they
want
and
then
provide
some
examples
of
of
reasons.
My
why
you
might
want
to
do
it
by
Tuple
or
my
white
might
want
to
do
it
by
server
IP
address
alone,
for
example.
R
R
There's
also
some
new
text
about
how
resolvers
should
protect
themselves
from
possible
attacks.
So
since,
since
there's
a
requirement
to
Cache
resolution
failures,
there's
that
sort
of
introduces
a
new
security
risk
where
an
attacker
could
try
to
exhaust
this
cache.
You
know
send
lots
of
specific
queries
designed
to
fill
up
this,
this
new
type
of
cache
and,
of
course,
resolvers-
need
to
protect
themselves
and
and
can
can
limit
the
resources
they
devote
to
such
a
resolution.
Failure
cache
next.
R
There's
there's
some
text
in
the
in
the
draft
about
about
timing,
and
this
is
really
unchanged
since
the
last
version.
There
was
a
little
bit
of
discussion
about
this,
but
what
what
the
draft
currently
says
is
that
resolution
failures
must
be
cached
for
at
least
five
seconds
and
and
the
justification
for
this
is
that
this
is
the
amount
of
time
that
a
user
could
reasonably
be
expected
to
wait
to
retry
or
something
like
that.
R
There's
a
should
level
requirement
that
the
resolver
should
use
an
exponential
back
off
in
the
amount
of
time
that
it
caches
these
sorts
of
things.
So
you
know
five
seconds
to
start
increase,
increase
and
so
on,
but
no
longer
than
five
minutes.
R
R
And
so,
lastly,
this
is
this
is
kind
of
a
new,
a
new
thing
that
we
would
like
discussion
on
so
some
implementations,
some
resolver
implementations
would
have
different
caches
based
on
edns
client,
subnet
values
and
sort
of
open
for
discussion,
whether
or
not
resolution
failure
caching
should
be
should
ignore.
Edns,
client,
subnet
or
if
partitioning
the
cache
by
that
client
subnet
value
would
be
appropriate
or
a
good
thing
to
do
so.
R
C
Thank
you.
Thank
you,
Dwayne
in
the
queue
beta
beta,
Thomas.
S
Yes,
science,
Peter
Thomason
I,
think
like
a
few
slides
earlier,
you
showed
that
the
partitioning
of
the
cache
should
be
up
to
the
implementers,
whether
it
would
be
Q
name
or
IP
address
or
whatever,
and
now
this
proposal
seems
to
contradict
that.
R
Yeah,
that's
that's
a
fair
question.
I
I
think
the
argument
I
would
make
is
that
you
know
if,
if
there's
an
implementation
that
normally
has
separate
caches
based
on
eating
this
client
subnet
that
can
really
sort
of
blow
up
the
the
size
of
the
cache,
and
so
there
may
be
thousands
of
different
subnet
values,
which
would
mean
that
now
the
resolver
is
is
emitting,
maybe
thousands
of
more
times
queries
than
than
it
needs
to
right.
S
A
certain
perhaps
that
concern
should
go
into
this
protect
the
self
section.
T
Duane
thanks
for
for
doing
that,
work
also
to
your
to
your
colleagues
and
there's
one
minor
thing:
the
security
consideration
section
talks
about
resource
exhaustion
by
deliberately
asking
for
domains
or
cue
names,
resulting
in
in
certain
failures
now,
given
that
most
of
these
resolution
failures
aren't
authenticated,
there's
probably
also
an
attack
Vector
in
forging
so
those
responses.
Is
that
something
you
would
consider
for
adding
to
that
discussion.
It
might
not
be
catastrophic,
but
it's
it's
a
window
of
opportunity
as
well
sure.
U
U
I
sort
of
would
agree
that
it
would
be
great
if
we
could
ignore
edina's
clients.net,
but
a
lot
of
implementation
sort
of
where
this
would
be
hard
and
we've
seen
in
the
wild
that
kind
of,
depending
on
what
you
give
the
authority,
sometimes
the
answer.
Sometimes
they
don't
so
it
would
make
the
positive
resolution
worse.
I
guess.
C
C
I
think
Philip
with
rights.
C
V
My
name
is
Philip
Humber
I
did
this
work
with
Philip
torup?
So
if
later
you
have
questions
find
either
of
us,
and
this
is
basically
about
making
a
try
to
make
complexity
of
a
slippery
solder
a
bit
more
manageable,
while
still
letting
the
stop
resolver
be
in
control
next
slide.
V
So
this
is
when
life
was
simple:
stop
resolve
for
censor
query
just
out
for
Port
53
and
then
hopefully
gets
an
answer
back,
but
then,
of
course,
when
most
of
the
traffic
on
the
internet
became
encrypted,
everything
has
stopped
resolver
said
queries,
say
plain
text,
it's
not
so
great
anymore.
So
the
ITF
took
its
Apollo
itself
to
create
ways
to
solve
that
backslide,
and
then
we
got
this
because
one
option
is
fine,
but
lots
of
options
is
always
better.
V
So
we
got
DNS
over
TLS
that
people
about
it
DNS
of
HTTP,
but
HTTP
is
actually
at
the
moment,
sort
of
two
protocols,
hp2
and
hp3,
and
then
there's
a
separate
DNS
over
quick
and
then
you
can
also
create
a
nested
implementation.
So
you
get
oblivious
Doh,
so
complexity
for
a
stop.
Resolver
is
get
a
completely
out
of
head
next
slide.
Please
foreign.
V
Well,
this
the
next
one
after
this
yeah.
A
V
We
were
working
on
a
library
called
called
connect
by
name
and
the
ideas
you
put
in
a
name
and
outcomes,
TLS
collection
and
then
does
all
the
happy,
eyeballs
and
Dane,
and
whatever
simplifying
the
life
of
the
application
and
the
on
top
of
the
gets
library
that
we
have
and
and
just
doing
all
of
the
DNS
parts
right
sort
of
costs.
What
we
wanted
to
Chase
and
get
here
that's
to
completely
explode,
because
a
lot
of
this
stuff
is
recursive.
V
If
you
connect
to
Doh,
then
you
could
also
do
data
whatever.
So
we
were
looking
for
ways
to
simplify
it
next
slide,
and
we
also
notice,
like
sort
of
in
general,
with
this
model.
There's
quite
a
few
stop
resolvers
out
there.
Are
they
going
to
implement
all
of
these
different
transports?
What
if
they
don't
UDP
to
Port
53
has
has
basically
no
state
if
I
run
Bing,
and
it
has
to
set
up
a
DLH
collection
to
look
up
lrp
at
a
name
and
then
tear
it
down
immediately.
V
That
costs
a
lot
of
extra
resources.
Resources
are
also
show
up
on
a
recursive
resolver
and
in
general
you
can
expect
latency
and
stuff
like
that.
So
next
slide.
Please
there's,
of
course
an
obvious
way
to
solve
that,
and
that
is
just
introduce
a
local
proxy
and
then
the
proxy
can
maintain
those
connections
for
a
longer
period
of
time.
So
so
it
becomes
more
efficient
and
there's
plenty
of
those
proxies
already
around.
V
So
there's
a
lot
of
people
who
have
a
local
inbounds,
they're
stubby,
more
designed
as
a
proxy
there's
TNS
mask,
has
been
allowed
for
a
long
time
and
there's
a
systemd
Softee
that
tries
to
do
several
things
next
slide,
please,
but
the
problem
there
is
that
the
application
now
is
talking
to
a
complete
Black
Box,
it's
like
well
what,
if
the
application
would
really
insist
on
having
some
sort
of
a
private
collection,
privacy,
preserving
collection
to
recursively
software.
V
If
you
talk
to
a
local
proxy,
you
just
don't
know,
maybe
an
application
has
very
specific
desires
like
it.
It's
really
about
to
have
a
Doh
collections
to
a
specific
public
resolver
or
something
like
that.
What
kind
of
feedback
do
you
get
from
the
proxy?
If
it
fails,
I
mean
you
just
get
the
software,
usually
I,
guess
if,
if
the
collection
to
the
Upstream
recursive
resolver
fails
and
also
for
diagnostic
tools,
if,
if
your
deck
or
drill
or
whatever
goes
directly
out
on
the
internet,
any
applications
go
through
a
proxy.
V
V
So
we
came
up
with
this
as
as
a
solution,
and
that
is
the
step.
Resolver
includes
this
option
in
a
request
when
it
sends
it
to
the
local
proxy,
and
basically
this
option
can
describe
What
the
stock
price
author
would
like
to
get
from
the
Upstream
collection
to
the
recursive
resolver,
and
it
consists
of
a
number
of
sections:
that's
first,
a
set
of
bits
which
basically
specify
what
kind
of
encryption
and
authentication
you
want,
whether
there's
a
specific
desire
to
have
or
exclude
certain
Upstream
transports.
V
If
an
application
wants
to
be
more
specific,
it
could
list
IP
addresses
for
Upstream
resolvers.
If
you
want
to
have
any
kind
of
authenticated
collection
that
you
need
to
have
a
name,
if,
for
example,
you
want
to
do,
do
you
want
to
have
a
dough
path
so
that
can
be
put
in
the
SVC
parameters
as
well
as
support
or
LPS?
And
finally,
all
devices
were
outgoing
interface
really
matters
like,
for
example,
on
a
phone.
V
If
an
application
is
aware
of
interfaces,
then
it
could
also
put
in
an
interface
name,
but
the
basic
idea
is
that
an
application
is
not
required
to
put
anything
ill.
I
mean
if
you
just
said
this
option
with
all
bits
clear
that
you
basically
tell
the
proxy
will
do
whatever
you
want.
If
you
just
said
well,
I
need
authenticated
connection
that
the
proxy
should
figure
out
a
way
to
give
you
an
authenticated
collection
or
report,
a
failure.
If
it
cannot
do
that
next
slide.
V
So
a
key
design
thing
of
this
is
It's,
stateless,
every.
So
it
sort
of
mimics
the
original
DNS
to
Port
53
set
up.
So
we
said
the
same
proxy
option
in
every
requests
and
then
assume
that
the
the
proxy
will
do
something
clever.
V
To
avoid
having
some
sort
of
State
between
the
local
proxy
and
the
step
we've
had
to
maximize
control
given
to
the
application
I'm,
not
saying
that
all
applications
have
to
use
it,
but
if
they
want
to
use
it,
they
should
be
there,
of
course,
for
for
step
resources.
The
benefit
of
moving
to
this
model
would
be
that
there's
a
very
bigger
potential
for
caching,
certainly
for
short-lived
applications.
V
It
also
introduces
opportunity
to
implement
local
policies
in
the
blockchain
instead
of
well
try
to
figure
out
whatever
stop
resolve
your
application.
Has
it
and
try
to
do
something
for
that?
The
next
bullet
item
is
formulated
a
bit
sloppy
here.
V
You
need
to
do
the
DLS
acceleration,
but
it
only
does
that
for
internal
stuff,
not
as
a
server
to
the
user,
and
we
implemented
this
not
completely,
but
but
most
of
it
in
a
branch
of
of
Cathy
and
S
people
about
to
play
with
it.
Next
slide.
Please
thinking
about
this.
V
If
you
have
sort
of
a
current
proxy,
then
it's
quite
possible
that
the
current
proxies
blindly
forwards,
edns
zero
options
and
then,
if,
if
you
would
end
up
with
the
situation,
that's
some
because
of
his
authority.
The
network
would
implement
this
proxy
control
option,
which
is
not
ruled
out.
V
Then
you
could
have
the
situation
that
stop
resolver
thinks
it's
topic
to
a
local
proxy
that
affects
traffic
is
just
forwarded
unencrypted,
so
there's
a
separate
option
that
specifically
a
way
to
communicate
between
the
resolved
proxy
and
then
the
the
proxy
basically
tells
the
surplus
of
what
sort
of
oh,
what
sort
of
Network
Source
adders
that
I
get
this
request
from
and
I
really,
if,
if
a
slippery
sulfur
is
very
private,
see
sensitive
that
it
should
say.
V
V
This
is
basically
a
coffee.
This
thing
that
might
need
to
a
separate
document
or
something
like
that-
is
that
if
an
application
or
a
stop
wants
to
do
a
DNS
check,
validation
and
you
want
to
sort
of
be
guaranteed
that
as
a
fallback
trust
anchor
that
it
would
be
nice
if
your
local
proxy
can
just
cash
the
other
side,
trust
or
Data
Trust
anchors
and
return
that
so
there's
an
extra
option.
That
basically
said
well,
please
give
me
this
stuff.
V
If
you
already
have
a
local
trust
anchor
that
you
don't
need
it,
but
but
applications
needs
a
fallback
and
it
would
be
better
if
step
resolvers
they'll
have
to
set
up
https
collections
to
Eli
and
stuff
like
that.
So
that's
the
three
different
options
next
slide.
Please.
V
So
the
question
is:
do
people
find
this
useful?
Would
they
like
this
working
group
to
work
on
it
or
any
other
kind
of
feedback
or
questions?
Thank.
C
You
Philip
just
this
last
ITF,
the
author
sended,
the
document
to
the
add
group
that
was
discussed
there,
but
was
out
of
Charter,
so
the
different
DNS
working
group
chess
discussed
this
were
to
present
it
or
where
should
it
learn?
We
send
an
email
to
the
mailing
list
to
the
DDS
open
list
with
this
question
actually,
and
that's
also
why
we
scheduled
this
presentation
here,
we
would
like
to
share
the
feedback
from
the
from
the
working
group
Ralph.
Please
go
ahead.
Yeah.
U
V
V
U
V
So
we're
looking
at
doing
inter-process
communication
within
the
host
in
a
way
that
fits
within
the
DLS
model.
So
there's
a
fake.
That's.
O
V
Do
something
like
that
and
then
it
sort
of
becomes
completely
outside
the
DNS
Community
to
to
design
anything
on
how
that
works.
So
so
this
is
an
attempt
like.
Can
we
structure
this
part
of
communication
that
just
definitely
happening
in
the
real
world
in
a
way
that
that
sort
of
we
can
have
a
say
on
it,
instead
of
leaving
it
to
the
random
implementer
of
house
operating
system,.
U
V
So
those
are
protocols
between
in
this
model
that
would
be
running
between
the
local
proxy
and
the
recursive
resolver,
whereas
this
would
be
specific
for
a
sub
resolver
at
a
local
to
to
reduce
the
complexity
of
the
step
resolver,
because
otherwise
the
step
resolver
would
have
to
implement
all
of
the
add
protocols
creating
more
complexity.
H
Hi,
can
you
hear
me
so
the
the
Dane
mode
that's
described
in
the
draft
is
either
no
mention
of
Dane
or
Dana's
mandatory
or
pkx.
You
know
mention
or
mandatory,
and
it
seems
to
me
that
that
putting
the
knowledge
in
the
application
of
which
of
these
will
or
will
not
work
is
fragile.
An
application
doesn't
necessarily
know
which
authentication
mechanisms
will
or
won't
be
available
to
a
particular
destination.
H
One
of
the
great
ways
in
which
daneworks
is
something
called
opportunistic
name
which
is
use
it
when
there
are
tlsa
records
and
don't
use
it
when
there
aren't
so
use
Dane
when
possible.
That's
not
covered
in
the
in
the
draft.
V
Yes,
because
if
you
set
both
bits
to
zero
that
it
should
do
exactly
that,
so
the
model
should
be
that's
sort
of
everything
can
be
clear
and
then
it's
up
to
the
the
proxy
to
basically
do
the
right
thing,
but
if
an
application
has
specific
knowledge
or
desired,
an
application
can
override
that
and
say
well.
This
is
now
mandatory
because
I
want
it.
H
Is
the
proxy
expected
to
detain
when
TLC
records
are
published?
There
was
no
language
about
that
at
all.
It.
V
Expected
to
do
Dane,
yes,
so
it's
expected
to
exactly
do
a
Dane
lookup
see
whether
that
would
work
or
not
and
then
use
the
information
yeah.
V
Q
Hi
I
want
I
want
to
focus
on
something
I
I
just
heard
you
say
at
the
end,
I
feel
like
was
was
kind
of
crucial
right
that
this
isn't
formulated
as
an
API,
because
the
ietf
doesn't
standardize
apis,
and
so
the
only
way
we
can
insert
ourselves
into
this
process
and
and
provide
our
our
proposal
for
how
the
system
works
is
to
structure
our
solution
in
the
form
of
a
protocol
and
I.
Q
Don't
know
if
that's
exactly
true
that
the
ITF
has
started
to
dabble
in
API
definitions,
but
whether
or
not
it's
true
it
doesn't.
It
doesn't
strike
me
as
a
good
reason
to
to
structure
it.
This
way,
I
think
that
what
we're
describing
here
is
something
that
that's
really
most,
naturally
characterized
as
an
API
and
if
the
iatf
hasn't
traditionally
been
very
involved
in
API
definitions,
I
think
that's
for
a
good
reason,
which
is
that
those
definitions
have
to
evolve
pretty
fast
and
and
the
requirements
aren't
always
so
clear
up
front.
Q
In
this
particular
case,
you
know,
I
I,
don't
think
that
the
specific
behavior
that's
laid
out
here
would
precisely
work
on,
for
example,
any
of
the
major
consumer
operating
systems
or
for
use
by
any
of
the
major
consumer
browsers.
Those
all
have
very
detailed
and
evolving
requirements
for
how
they
do
their
DNS
lookups
for
what
security
requirements
they
expect
Etc.
Q
So
I
think
that
if
you
actually
look
at
the
the
market
for
this
I
think
it's
sort
of
not
there
and
instead
we
we
do
need
to
figure
out
a
a
richer
API
for
name
resolution
for
essentially
the
the
longer
tale
of
applications
who
aren't
willing
to
deeply
customize
their
DNS
Behavior,
but
also
aren't
willing
to
be
stuck
on
get
Adder
info
forever.
Q
But
I
don't
think
the
answer
is
to
take
all
of
the
metadata
about
how
you
want
the
request
to
be
processed
and
bundle
it
into
the
request
itself,
in
particular,
I.
Think
that
there's
a
layering
violation
here,
where
the
the
client
in
this
case
doesn't
have
any
clear
signal
as
to
whether
it's
talking
to
a
DNS
proxy.
That
is
aware
of
this
until
after
the
query
has
already
been
issued,
it
only
finds
out
it
from
the
response.
Whether
it's
requests
were
were
met.
Q
The
client
can
actually
tell
it
where
it
wants
queries
to
go
so
I
think
there's
a
lot
of
question
marks
about
what
really
what
we
really
ought
to
do
here.
V
So
many
Bucks
one
is:
it
seems
that
at
the
moment
there
is
almost
nothing
for
to
allow
sort
of
an
application
to
talk
to
a
local
proxy
through
an
API,
or
at
least
I'm,
not
aware
of
anything
that
that
works
on
more
than
one
platform.
The
second
part
is
that
the
draft
specifically
has
a
probing
query
to
make
sure
that
the
the
application
doesn't
leak,
any
privacy,
sensitive,
DNS,
query
name,
but
can
still
probe
whether
this
local
proxy
that
supports
this
draft
is
available.
V
E
Sure
we're
running
a
little
bit
behind
time,
so
the
further
discussion
can
go
to
the
list.
Are
you
sure
Warren?
Okay,
thank
you
and
I
guess
Peter
is
next.
T
S
So
I'm
going
to
give
a
quick
update
on
the
draft
that
I
wrote
on
mandating
consistency
checks
when
processing,
CDs
or
csync
records.
We've
talked
about
this
in
Philadelphia
in
July
and
got
some
feedback
which
is
not
Incorporated
yeah.
So
this
is
a
quick
talk
and
the
next
one
will
also
be
mine,
which
I
perhaps
will
borrow
a
minute
or
two
from
this
one.
Thanks.
S
Yeah,
so
this
is
mainly
for
documentation
for
people
who
will
look
it
up
later
when
they
download
the
slides.
So
everybody
probably
knows
CDs
records
are
used
by
the
child
to
tell
the
parent,
which
are
the
future
DS
records.
It
desires,
it's
good
for
Royal
office
and
so
on
and
so
forth
and
the
type
publishes
it
and
the
parent
can
digest
it.
And
similarly,
similarly
for
csync,
the
child
can
indicate
what
other
stuff
should
be
updated,
like
an
S
record
so
glue.
S
S
What
the
CDs
record
at
a
child,
for
example,
is,
and
if
you
do
that,
you
end
up
asking
only
one
authoritative
server,
which
may
be
giving
you
one
response,
and
if
you
ask
another
time
or
I
don't
know
in
another
microsecond,
you
may
be
asking
another
authoritative
server,
which
might
be
giving
a
different
answer
and
there
is
no
no
way
to
decide.
What's
the
right
one
and
the
specifications
so
far,
don't
consider
this
problem.
So,
let's
look
into
what
can
possibly
go
wrong
with
this
next,
so
there's
mainly
two
scenarios.
S
One
is
the
multi-homing
scenario
which
gets
more
interesting.
If
you
add
DNA
SEC,
then
it's
called
multi-signer
so
consider
you
have
two
providers
which
both
host
a
Zone
and
they
sign
it
independently,
each
other
announcing
their
keys,
each
other's
and
their
own
Keys.
S
Now
one
of
them
does
a
key
role
and
accordingly
updates
the
CDs
records
for
their
with
the
updated
keys
in
that
case,
when
they
do
that,
and
they
forget
to
include
the
other
providers
Keys,
which
may
easily
happen
when
you
update
the
CDs
records
with
your
own
new
stuff
and
the
parent
ends
up
querying
this,
it
may
happen
that
the
other
provider
gets
thrown
out
of
the
DS
record
set,
which
makes
the
general
trust
and
breaks
the
solution,
and
similarly,
with
NS
updates
via
csync,
you
can
get
the
same
kind
of
problem
and
remove
the
other
providers
and
S
records
accidentally,
so
that
also
breaks
a
multi-signer
setup
and
the
multi-homing
setup.
S
It
doesn't
necessarily
mean
the
validation
breaks,
but
that
resolution
breaks,
but
it
does
break
the
multi
redundancy
promise
that
you
have
in
a
multi-homic
setup.
Usually
next
and
similarly,
when
you
do
a
provider
change
without
turning
dnsic
off,
you
have
to
do
a
multi-signup
period,
so
you
onboard
a
new
provider
and
then
off-board
the
first
one,
and
that
also
involves
multiple
steps
with
Ds
record
and
NS
record
updates.
S
S
So,
if
the
new
provider
isn't
aware
that
this
is
even
a
multi-signer
setup,
they
may
not
have
included
the
old
providers
stuff
into
their
CDs
record
set,
and
then
the
parent
might
end
up
adjusting
that
stuff
and
throwing
the
old
providers
DS
records
out
of
the
delegation,
although
it
is
still
in
the
NS
record
set
and
that
breaks
the
the
things
too.
So
this
is
kind
of
a
special
case
of
the
multi-seller
thing.
S
So
to
fix
this,
let's
look
at
the
next
and
I
think
final
slide,
so
these
problems
can
be
mitigated
if
the
parent
is
a
bit
more
careful
and
if
you
have
a
policy
that
whenever
you
use
a
CDs
or
cdns
key
or
csync
records
as
a
parent
for
doing
this
kind
of
scanning,
you
should
check
whether
things
are
consistent
across
all
name
servers
in
the
delegation.
S
You
may
disregard
unresponsive,
name
servers,
but
otherwise,
if
you
discover
an
inconsistency,
you
must
abort
and
not
change
the
delegation,
and
you
can
do
it
again
tomorrow
or
you
can
retry
after
five
minutes
or
whatever
your
back
off
policy
is,
but
that
would
solve
that
problem
and
if
multi-signer
deployments
at
some
point
get
more
prominent
I
would
expect
these
things
to
happen.
Unless
care
is
taken.
S
S
So
this
is
what
I
think
about
it
and
I
I
was
going
to
ask
the
working
group.
If
you
think
this
is
reasonable
if
it
should
be
moved
forward
and
so
on
and
so
forth.
P
Thank
you,
West
herdicker,
uscisi,
no
hats!
Actually,
hat
of
the
csync
author
document
I
support
this,
because
I
actually
think
I
wanted
to
do
something
like
this
back
when
I
published
it,
but
there's
some
pushback.
So
if
you
read
the
feasting
document
in
a
particular
section
4.2,
it
says
you
have
to
take
the
the
most
recent
SOA.
So
there
is
some
notion
of
how
to
make
sure
that
you
know.
Even
if
things
are
inconsistent,
you
still
get
the
most
recent
up
to
date
record
and
things
like
that.
P
The
problem
is,
is
that
in
some
deployments
my
recollection
from
the
discussion
is
you
there
may
be
some
complexity
and
you
actually
want
to
point
at
a
at
a
hidden
server,
which
is
actually
what
this
document
also
talks
about.
In
section
4.2,
it
says
you
know
the
scanners,
maybe
you
know
or
registrars
might
be
configurable
to
say:
hey,
go,
look
somewhere
else
and
things
like
that.
So
do
I'd
read
that
section
just
to
see
you
know
what
it
follows
it,
but
otherwise
I
like
the
idea
of.
U
So
you
also
support
this
and
there
were
a
couple
of
things
that
I
mean.
Maybe
in
regards
to
what
Wes
said,
if
you
kind
of
ask
all
servers,
you
still
might
not
have
asked
all
server,
because
there's
any
cast
and
all
the
other
stuff
behind
that.
Maybe
it
might
be
good
to
have
some
text
around
that
in
the
document
and
then
what
is
the
reasoning
behind
kind
of
if
servers
are
not
responding
to
discount
them
rather
than
doing
some
sort
of
retry?
Okay,.
S
So
two
things
regarding
your
first
point
about
various
anycast
nodes:
I
think
the
important
policy
is
to
ask
all
providers
involved
and
you
can
achieve
that
by
asking
one
node
of
each
name:
server
host
name
so
I
think
that's
why
that's
okay
and
then
the
second
way
to
disregard
unresponsive,
name
servers
so
sometimes
there's
maintenance,
but,
more
importantly,
from
some
corners
of
the
topology.
S
Some
stuff
may
just
be
unreachable
because
of
routing
issues,
and
you
would
otherwise
never
have
the
ability
to
to
do
an
actual
update.
If
you
take
that
as
a
blocking
failure,
I
don't
feel
very
strongly
and
it
wasn't
in
the
draft
originally,
but
at
the
last
ATF
was
proposed
to
add
it
in
I
think
it
was
Victor.
So
perhaps
Victor
can
start
the
battle.
U
S
I,
don't
I
don't
feel
strongly
about
it.
So
whatever
the
the
working
group
feels
like.
D
Paul
Walker
speaking
as
one
of
the
authors
of
the
Celia
record,
I
just
skimmed
my
our
sales,
like
did.
We
really
not
say
anything
about
this
and
we
didn't
so.
Yes,
please
do
this
work.
This
is
our
buck.
I'm!
Sorry.
H
Allowing
name
servers
to
be
unreachable.
My
concern
was
about
Hidden
Monsters
and
also
about
being
able
to
remove
name
servers
that
have
died
and
aren't
going
to
come
back
right
when
your
name
server
is
permanently
decommissioned.
You
want
to
be
able
to
still
make
updates
and
it's
presently
listed.
So
you
know
what
are
you
gonna
do.
S
Should
I
add
these?
These
reasonings
to
the
draft
I
mean
I,
said
unreachable
corners
of
the
internet
and
you
said
phasing
out
name
service,
and
all
of
that
do
you
think
that's
important,
or
do
we
just
I
mean
it's
important,
but
do
you
think
it's
important
for
the
draft,
or
should
we
just
specify
the
protocol
without
justification?
I,
don't
know
how
it's
handled
usually.
C
Okay,
thank
you.
Peter
wrapping
up
there's
also
been
good
discussion
on
the
mailing
list
in
July
August
there's
a
good
feedback
from
the
room
will
schedule
a
working
group
adoption
call
later
with,
and
we
coordinate
with
you.
Okay
next
presentation,
also
by
Peter.
S
All
right,
so
it's
Peter
Thomason
yeah.
So
in
the
past
few
years
multi-signing
scenarios
have
been
discussed
in
various
places
and
I
was
sometimes
part
of
the
discussion
and
I
noticed
that
the
the
way
that
the
key
exchange
that's
necessary
between
the
participating
providers
hasn't
been
discussed
on
a
protocol
level
so
far
or
well
like
there's,
no,
no
automatable
recipe
for
it.
Essentially,
it's
not
really
protocol
change
and
I
just
wanted
to
talk
about
that
and
put
it
out
there
to
the
group.
S
How
that
could
be
addressed
again.
I,
don't
feel
very
strongly.
It's
just
an
idea.
I
don't
know
if
anyone
needs
a
solution,
even
maybe
people
like
doing
things
manually,
but
so,
let's,
let's
just
take
a
look
at
it
and
then
we
can
discuss
or
do
whatever
so
next
slide.
S
So
this
is
a
bit
of
a
messy
slide,
but
I'll
walk
you
through
it.
So
to
look
at
what's
needed
for
the
key
exchange.
It's
interesting
to
investigate
how
the
DNS
resolution
works.
If
you
have
a
multi-center
setup-
and
let's
say
you
you're
asking
for
some
record
of
Interest,
let's
say
an
a
record,
and
actually
you
will
need
two
separate
queries.
S
One
is
for
the
a
record
which
gets
you
the
response
and
also
the
signature,
and
the
other
is
for
the
DNS
key
that
you
need
for
validation
and
a
reserver
might
end
up
sending
these
two
queries
to
two
different
name:
server
host
names
and
then
a
multi-center
setup
that
might
be
operated
by
two
different
providers,
and
so
the
DNS
key
record
set
is
not
necessarily
delivered
by
the
party
who
also
gave
you
the
signature
so
to
make
that
work
and
to
to
keep
it
that
way.
S
That
reservers
don't
need
to
be
aware
of
any
of
this
multi-cellular
stuff.
You
need
to
make
sure
that
the
DNS
key
responses
include
all
the
keys
that
a
validator
may
need
to
do
the
validation,
regardless
of
whether
the
record
of
interest
is
delivered
by
the
same
provider
or
not.
So.
The
interesting
question
here
is
what
exactly
needs
to
be
included
in
the
dnsq
record
set,
and
it
turns
out.
Of
course
it
works.
S
If
you
just
include
all
of
the
DNS
keys
of
all
providers,
so
you
just
take
the
global
Union
or
something
like
that,
but
turns
out,
you
don't
need
that
it
actually
depends
on
the
Queue
type,
because
if
you
are
looking
for
the
DNS
key,
only
if
that's
the
record
of
Interest,
then
the
signature
will
always
be
in
the
same
response
as
the
DNS
key.
So
it
will
always
be
done
with
a
key
that
is
part
of
the
dnsc
records
that
you
get
as
a
response.
S
S
It
may
be
that
the
signature
is
delivered
by
a
provider,
that's
different
from
the
DNS
key
delivery
provider,
as
I
said
earlier,
because
then
you
really
have
two
different
queries
and
then
you
need
the
other
provider's
zsks
right,
because
you,
you
don't
know
ahead
of
time,
which
name
server
hostname
belongs
to
who
so
forget?
All
about
that?
The
summary
of
that
is
so
the
bottom
line
is
the
DNS
record
said
that
everybody
has
to
deliver
is
at
least
the
local
DNS
keys
of
that
provider.
S
Who's
responding,
plus
the
other
providers,
is
use
case,
so
anyone
who's
sending
a
response
needs
to
have
imported
the
other
providers
Zs
case,
but
not
necessarily
the
case
case
and
then
very
similarly
for
CDs
and
CDN
SQ
records.
If
you
want
to
use
that-
and
you
also
have
to
to
serve
the
union
of
all
the
providers-
ksk
type
DNS
keys,
because
otherwise
things
wouldn't
work
out
with
the
previous
draft,
where
you
require
consistency
so
next,
so
let's
look
at
what
the
additional
requirements
would
be
Beyond.
S
What
are
the
keys
you
need,
so
we
just
learned
that
providers
need
to
discover
each
other's
Case
Case
and
include
them
in
the
CDs
kind
of
records
and
to
learn
each
other's
Zeus
case
and
announce
them
in
the
dnsq
record
sets,
and
all
of
that
in
principle
has
been
described
in
order.
Automation,
draft
I
think
together
with
Schumann
and
actually
the
link
is
outdated.
It's
been
adopted
already,
but
the
draft
doesn't
specify
how
to
do
it.
S
In
a
technical
way-
and
there
are
a
few
questions
to
to
answer,
for
example,
one
is
which
channel
do
you
use
and
another
is
how
do
you
decide
whether
a
key
that
you
observe
at
another
provider's
DNS
key
record,
set
that
you
want
to
import
if
that
is
actually
a
ksk
or
also
used
for
signing
of
other
records,
in
which
case
it's
a
zsk
or
CSK,
and
that's
hard
to
tell,
because
you
don't
know
if
a
ksk
like
signs
that
other
one
record,
That
You
Don't
See
from
the
outside
and
then
also
if
you
have
three
providers,
for
example,
just
for
illustration.
S
Let's
say:
provider
a
b
and
c
everybody
has
imported
each
other's
stuff
and
then
provide
a
b
obsoletes,
the
key
that
they
phase
out
it'll
have
been
imported
by
A
and
B
right.
So
how
should
a
for
example
know
that
they
should
remove
this
key
because
B
has
faced
it
out,
although
it's
still
visible
in
C,
so
it
could
be.
C
is
key,
a
doesn't
know
and
that
kind
of
inference
doesn't
work.
If
you
just
look
at
the
DNS
key
record
set
in
the
child
to
yeah.
So
so
you
get
these
orphaned
keys.
S
If
you
only
try
to
infer
from
what
you
see
at
the
Apex,
so
you
need
something
else
and
that's
something
else.
What
properties
would
you
like?
So
so
one
property
would
be,
it
would
be
in
band
I
mean
it
doesn't
need
to.
We
can
use
rest
apis
or
whatever,
but
perhaps
you
can
make
it
work
in
band
would
be
nice
if
it's
if
it
is
authenticated
and
because
of
the
how
to
distinguish
different
kinds
of
keys,
a
problem
that
I
just
mentioned.
S
S
The
bootstrapping
draft
has
a
signaling
mechanism.
How
the
DNS
provider
the
names
of
operators,
can
make
authenticated
announcements
of
stuff
about
their
domains
that
they
host
it's
used
in
the
bootstrapping
draft
to
make
an
initial
statement
about
what
the
DS
record
set
should
be
before.
There
is
a
chain
of
trust,
and
there
is
a
label
in
the
beginning
of
the
signaling
owner
names.
S
In
this
draft,
that
is
the
signaling
type
and
we
can
introduce
a
new
one
like,
for
example,
underscore
multi,
and
we
can
use
that
signaling
mechanism
to
have
an
authenticated,
signaling
path
between
the
different
DNS
operators
who
participate
in
a
dnsic
multi-signer
scenario,
and
the
idea
is
that,
under
these
signaling
records,
each
provider
would
announce
their
own
keys,
for
which
they
control
the
private
part,
so
no
Union,
and
then
all
the
other
ones
could
look
at
that
and
collect
whatever
they
find
and
import
it
into
their
local
stuff.
S
S
The
idea
is
to
do
it
as
shown
at
the
bottom
of
this
slide.
So
let's
say
you're
provider.net,
and
you
want
to
make
an
announcement
to
your
multi-signer
peers
about
the
domain
example.co.uk.
Then
you
would
assemble
the
name,
as
it's
shown
here
underscore
multi.example.co.uk
underscore
signal
dot,
whatever
the
name
server
host
name
is
and
on
this
name,
which
is
a
not
an
apex
name,
so
it's
a
subdomain
necessarily.
You
can't
have
a
delegation
there.
S
S
That's
the
basic
idea,
it
kind
of
sounds
complicated,
but
actually
boils
down
to
just
having
providers
publish
a
copy
of
their
own
records
under
these
names
next
slide.
The
question
is,
then,
how
do
you
trigger
this?
How
does
a
provider
know
that
the
other
ones
even
exist
and
when
does
an
import
have
to
happen?
S
So
if
you
consider,
for
example,
the
beginning
of
a
multi-signer
setup,
initially,
the
new
provider
is
not
yet
in
the
name
server
record
set
and
before
you
can
add
the
provider
you
have
to
to
set
up
the
DNS
configuration.
So
you
can't
do
it
based
on
the
NS
record,
sets
because
it's
not
yet
there
you
can't
find
the
new
provider.
Yet
the
proposal
for
Discovery
is
that
we
introduce
a
new
record
type,
I
have
called
it
tentatively
CNS
and
it
could
hold
the
prospective
name.
S
Server
host
names
in
the
final
state
after
the
transition
has
happened.
That's
analogous
to
how
CDs
records
hold
the
prospective
DS
records,
and
the
idea
is
that
when
The
Zone
owner
has
provisioned
the
zone
at
the
old
provider
and
also
the
new
provider
and
synchronized
all
the
contents
like
a
records
or
whatever,
then
when
everything
is
in
order,
they
add
a
CNS
record
set,
which
is
the
union
of
name
server
host
names.
S
So
it
would
have
the
old
and
the
new
name,
server
host
names
and
when
a
DNS
operator
discovers
that
that
has
been
created,
they
can
look
at
it
and
see.
Oh
okay.
So
these
are
my
host
names
and
then
the
other
three
are
from
the
other
provider
and
then
they
can
go
ahead
and
determine
what
the
signaling
names
would
be
from
the
previous
slide
and
import
stuff.
S
This
also
works
for
triggering
a
rollover
synchronization.
So,
for
example,
when
you
have
done
the
multi-signer
setup,
you
would
of
course
remove
this
CNS
stuff
again,
because
you
don't
need
it
anymore
and
then,
when
one
provider
does
a
rollover,
The
Zone
owner
can
trigger
a
synchronization
or
re-synchronization
of
keys
between
multisand
appears
by
recreating
this
CNS
record
set,
and
then
they
go
and
do
the
queries
and
and
collect
yeah.
S
So
that's
the
idea
for
the
trigger
I.
Don't
care
about
what
the
name
of
the
record
type
would
be.
I
called
it
CNS
because
it
lives
on
the
child
side,
just
like
CDs
and
csync,
and
it
conveys
configuration,
although
not
to
the
parent,
but
to
the
peers
and
that's
what
I
thought
the
CNS
would
be
intuitive,
but
I
know
that
some
people
at
least
feel
differently.
S
Some
people
have
told
me
so
whatever
I
just
wanted
to
include
the
concern
here,
we
can
change
it,
but
I
think
it's
neat,
there's
two
more
slides.
The
next
slide
has
an
example
workflow.
S
So
let's
say
you
have
example.co.uk
and
you
are
provider
a
I
mean
you
are
not
provider
a,
but
that's
the
current
setup
and
this
one
dot
provider
a.net
and
you
want
to
onboard
a
second
provider
into
the
multi-signer
scenario.
The
first
thing
to
do
is
that
the
domain
owner
creates
a
zone
at
the
second
provider.
S
B-
and
you
know,
Provisions
are
the
a
records
and
whatever
the
Zone
contents
are
and
then,
when
that's
in
order,
the
domain
owner
creates
the
CNS
record
set,
which
is
a
joint
set
of
name
server
host
names
at
both
providers.
S
They
both
observe
this
and
then
provide
a
B,
for
example,
would
do
whatever
like
underscore
multi
The,
Zone,
name.signal,
Dot,
and
then
the
other
provider's
host
names
which
are
taken
from
the
CNS
record,
set
query
DNS
key
and
CDs
records
to
DNS
ACC
validation
on
that,
because
that's
assigned
with
the
provider
A's
keys
because
the
subdomain
of
their
hostname
and
then
you
can
do
the
import.
Everybody
can
observe
what's
happening
because
provider
B
can
look
at
what
provider
a
is
publishing
at
the
child's
Apex
And.
S
When
everybody
has
observed
convergence,
then
you
can
go
ahead
and
update
the
NS
record
set
to
to
finish
the
onboarding
of
the
new
provider.
It's
possible
to
just
do
that
by
renaming
the
CNS
record,
set
to
the
NS
record,
set
and
overriding
that
and
then
do
csync
or
you
can
use
Epp
or
whatever
you
want.
It's.
It's
an
orthogonal
problem
to
this
one
yeah
so
final
slide.
The
summary
of
The
Proposal
is
that
it
solves
The,
multi-signer,
Exchange
problem
in
a
way
that
has
a
few
properties.
That
I
think
are
interesting.
S
It's
automated!
It's
authenticated
it's
in
band!
It's
explicit
about
the
ksk
versus
zsk
questions,
so
there's
no
guessing
involved
by
the
importing
party.
It's
comprehensive
in
that
it
covers
onboarding
and
off-boarding
and
key
roles,
and
it's
minimal
in
the
sense
that
it
has
a
signaling
mechanism
which
is
necessary
and
it
has
a
trigger
mechanism
which
is
necessary,
but
it
doesn't
add
any
protocol
change.
Resolvers,
don't
need
to
learn
anything
and
all
of
that
stuff.
S
I'm,
not
implying
it's
the
solution,
maybe
there's
a
better
one.
Maybe
nobody
needs
a
solution.
It's
just
what
I
came
up
with
and
I
would
be
interested
in
what
people
think.
C
H
You
haven't
talked
about
ongoing.
Is
it
a
scale
rollovers
from
the
individual
providers?
The
the
customers
then
not
involved
in
publishing
CNS
records,
they
might
have
removed
them,
but
the
operators
will
still
periodically
roll
their
own
set
of
SKS
how's.
The
timing
of
that
manage.
S
It
appears
to
me,
but
I'm,
not
sure
if
I
thought
it
through
fully
that
if
one
of
the
provider
does
is
zsk
roll
over,
then
it
would
be
unsafe
to
allow
the
provider
to
do
that
unilaterally,
and
you
always
need
to
have
the
Zone
owner
approved
kind
of
by
creating
the
CNS
record
and
say:
okay,
that's
fine,
go
ahead
and
change
it
I'm,
not
sure
if
that's
true,
but
no,
it
seems
to
me
like
that
now,
if
you're
saying,
perhaps
there
is
a
way
of
doing
it
unilaterally,
yeah,
probably
there
is
right
because,
as
far
as
a
an
operator
is
in
control
of
their
part
of
the
CNS
records,
but
doing
this
signaling
stuff,
why
not
let
them
do
it
yeah,
so
I
I
know
of
no
method
of
of
triggering
that
synchronization
I.
H
H
No,
we
should
discuss
it
later.
Okay,.
E
Yeah,
since
it's
a
new
draft,
you
know
you
know
we
should
go
ahead
and
bring
the
discussion
to
the
mailing
list.
Looking
forward
to
that
yeah
thank.
C
W
Okay,
good
morning,
everyone
I'm
thiru
I'll,
be
I'm.
One
of
the
co-authors
of
the
draft
structured
data
for
filter
DNS
was
presented
at
the
last
IDF
next
slide.
Please
a
quick
recap:
it's
it's.
The
primary
purpose
of
the
draft
is
to
assist
DNS
filter
troubleshooting
next
slide
at
the
last
idea
of
we
got
feedback
with
regard
to
this
craft
was
how
would
it
interrupt
with
the
RPC
servers
in
case
they
don't
upgrade
themselves
to
support
this
specification,
so
we
added
a
section
to
address
that
specific
comment.
W
Next
slide,
so
RPC
servers
are
the
ones
which,
in
case,
if
they
do
DNS
filtering,
they
would
put
an
NXT
domain
response
with
clearing
the
array
bit
in
those
cases
in
case.
If
the
client
is
upgraded
to
support
this
specification,
but
the
server
is
not,
it
would
continue
to
accept
the
next
domain
response,
but,
let's
imagine
a
case
where
a
server
is
also
upgraded
to
support
this
specification.
In
that
case,
the
client
would
learn
the
server's
capability
using
the
resin
foreign
type.
W
That's
being
discussed
in
the
ad
working
group
and
I
will
be
presenting
that
in
the
ad
working
group.
In
the
next
meeting,
and
then
the
client
includes
the
Ade
option
in
this
pseudo
record
type,
to
tell
that
it's
capable
of
understanding
the
Ade
response.
So
with
that
the
server
knows
whether
the
client
is
indeed
capable
of
understanding
the
Ed
option
or
not.
W
Yeah
I
think
we've
been
presenting
this
graph
for
quite
some
time,
and
we've
been
addressing
all
the
comments
that
have
been
received
so
far,
and
we
request
for
working
group
adoption.
C
Yeah,
thank
you.
So
the
documents
did
have
received
some
feedback
from
the
mailing
list.
I
understand
there
was
also
interest
from
the
industry.
Yes,
so
are
there
any
comments
here
in
the
working
group?
C
W
E
D
C
C
Contribution
to
the
working
group
see
you
next
in
Yokohama
or
online
bye.