►
From YouTube: IETF112-DNSOP-20211112-1430
Description
DNSOP meeting session at IETF112
2021/11/12 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
B
A
A
A
Paul
will
use
his
own
will
take
minutes
on
his
own
laptop,
not
using
code
him
or
it's
now,
hedge
doc,
I
think
called,
but
please,
if
you
want
to
drop
text,
use
the
url
here
shown
codemd
or
hedgehog
of
notes.
It's
today
it's
notes,
itf.org
and
we
will
integrate
the
notes,
the
minutes
okido.
We
assume
that
you
are
familiar
with
the
note
well
and
also
with
the
itf
code
of
conduct.
The
short
version
is
be
a
nice
person
good,
any
other
things.
Well,
yes,
agenda
for
sorry
the
agenda.
A
For
today
this
is,
we
made
a
small
change.
We
added
with
hardiker
to
the
agenda
for
today,
after
the
discussions
after
the
presentation,
there
was
quite
some
discussion
on
the
in
the
job
room
on
nsec,
3,
parameter
guidance
and
the
chairs
and
wes
luckily
thought
it
was
a
good
idea
to
continue
this
discussion.
Also
in
this
session,
so
this
is
the
agenda
for
today.
There's
the
oh
sorry
I
mess
up
as
a
bit.
A
E
E
E
And
there
it
was
discussed
that
would
be
nice
to
have
a
measurement
that
a
what
would
happen
if
a
authoritative
would
send
a
unsolicited
eds
option
to
in
response
to
a
resolver.
So
there
was
also
an
email
about
this
on
the
mailing
list.
So
that's
what
we
tried
to
do
for
this.
We
used
ebbf
the
extended
berkeley,
backed
filter.
E
This
is
way
beyond
what
maybe
some
of
you
know?
Is
it
what
was
used
for
tcp
dump?
It
now
runs
in
the
inside
of
the
linux
kernel.
So
it's
a
restricted
subset
of
c
is
what
was
used
and
with
this
you
can
create
nice
server,
name,
server,
agnostic
or
even
resolver
agnostic
programs,
which
you
don't
have
to
anticipate
beforehand.
So
it's
just
a
drop-in.
E
What
is
omitted
here
is
that
you
will
need
to
have
some
dependencies,
but
you
know
that's
fine,
and
then
here
we
show
that
it
actually
works,
so
the
url
we
used
here
is
report.intelnetlabs.com,
as
you
can
see
here,
because
th
this
is
for.
Those
of
you
who,
like
to
look
at
code,
is
how
we
can
sorry
how
we
can
configure
this
program.
That's
what
I
was
looking
for.
So
we
have
a
report
domain
which
has
said
is
a
report.nlabs.nl.
E
Then
we
chose
the
eater
code.
As
you
see
there,
it's
it's
the
first
one
for
the
experimental
ones,
and
then
we
have
a
sampling
rate.
This
was
also
discussed
during
during
the
interim
meeting.
That
would
maybe
be
nice.
Currently
we
tested
with
100,
but
maybe
other
other
tests
could
be
done
without
so
for
the
measurements
we
used
a
ripe
atlas
for
those
of
you,
don't
know
it.
It's
a
ripe,
ncc
measurement
platforms.
It
has
about
12
000
probes,
and
these
probes,
you
can.
You
can
ask
them
to
do
a
lot
of
things.
E
E
E
Get
a
baseline
but
don't
accept
the
unsolicited
message.
Then
you
can
see
a
lot
of
resolvers
there.
This
is
mostly
due
to
that.
The
right
measurements
right
measurement
probes
have
more
than
one
resolver
in
their
respective
networks.
So
roughly
two
less
than
two
usually
and
then
the
the
funny
part
is
on
the
right
here.
You
see
is
73.
E
E
So
so
that's
fine!
So
that's
the
baseline
is
good,
but
then
on
the
right
you
see
the
part
that
doesn't
overlap.
That's
responses
that
are
only
from
the
eater
and
not
from
both.
So
so
so
in
the
middle.
There's,
there's
positive
to
both
and
on
the
right
there's
just
a
positive
response
to
just
our
test,
not
the
baseline,
which
makes
it
weird.
E
E
E
B
C
E
F
G
H
F
G
No,
that's
true,
but
it's
only
like
0.1
percent
or
something
if
you
calculate
the
the
error
rate,
which
is
already
there
but
zero
zero.
One
percent
sounds
pretty
high
to
me.
Yes,
but
therefore
there's
also
the
sampling
rate
right,
so
you
don't
have
to
send
the
unsolicited
option
with
every
response.
It
could
also
be
like
on
five
percent
of
the
responses
or
something.
F
G
A
A
G
G
G
The
example
on
slide
uses
the
domain
name
catson,
but
that
name
is
actually
free
to
be
chosen.
One
could
consider
something
below
a
reserved
tld,
for
example
such
as
infill
it.
The
picture
shows
a
primary
and
its
relationships
with
secondaries,
so
the
catalog
zone
cat
zone
is
distributed
along
these
relationships
and
from
the
catalog
zone.
The
secondaries
learn
that
they
should
serve
example.com,
example.net
and
example.org.
G
So,
what's
new,
since
version
2,
we
introduced
the
terms
catalog
producer
and
catalog
consumer
to
describe
everything
more
clearly
in
the
draft
producer
generates
the
catalog
zone
and
a
consumer
processes
it
produces,
and
consumers
do
not
necessarily
align
with
the
primary
and
secondary
relationships.
For
example,
in
this
slide
you
see
that
there's
one
machine
producing
two
catalog
zones
for
one,
the
blue
one.
The
producer
is
also
the
primary
and
the
consumers
are
the
secondaries
and
the
other
catalog.
G
It's
nice
that
we
have
four
authors
of
open
source,
name
server,
implementations
working
on
this
task
and
discussing
the
dwarf,
because
the
resulted
this
this
resulted.
I
think,
in
the
most
permissive
and
generate
way
to
handle
and
implement
catalog
terms.
For
example,
we
no
longer
have
text
on
optimizations
that
are
consequence
of
predictable
rnas.
G
Memozones
can
have
properties
version.
4
of
the
draft
has
more
uniform
and
consistent
description
of
how
properties
may
be
defined.
Properties
from
standard
documents
are
always
one
label
below
the
zone.
Member.
We
described
three
such
properties
in
the
draft
which
are
optional,
and
I
will
go
over
them
quickly
in
the
coming.
Slides,
implementations
or
operators
of
catalog
zones
may
also
define
their
own
properties
below
the
lamp
label,
xt,
which
is
itself
one
label
below
the
zone.
Member
name.
G
G
The
zone
is
then
not
migrated
yet,
but
after
the
consumer
receives
an
update
that
adds
example.com
as
a
new
member
of
autocad
sound.
It
knows
that
example.com
came
from
catalog
catzone.
It
knows
the
associated
member
name
unique
id
a
so
it
can
look
up
the
coup
property
and
see
that
the
migration
has
the
catalog
catson's
consent.
G
G
G
G
G
G
Is
another
property
defined
in
the
draft?
Its
intention
is
to
increase
reliability
of
certain
updates,
because
you
know,
if
you
have
a
large
number
of
secondaries
and
a
large
number
of
sounds
notifiers
might
get
lost
on
the
internet
or
secondaries
might
be
down
and
not
receiving
the
notifies,
and
it's
also
the
intentions
also
to
reduce
the
notify
and
sarah
query
traffic
if
you
have
lots
of
secondaries
and
lots
of
zones.
So
how
does
that
work.
G
G
G
G
We
also
updated
the
security
section.
It
now
makes
very
clear
that
the
administrative
control
over
what
zones
are
served
from
the
configured
name,
servers
shifts
from
the
server
operator
or
the
consumer
of
the
catalog
to
the
owner,
the
producer
of
the
catalog
zone
content
and
we
have
a
other
edit
peter
thomason.
He
contributed
text
and
ids
and
did
a
lot
of
work
on
this
kitchen.
So
he's
a
arthur
nato.
D
I
actually
said:
no,
you
should
go
ahead.
Well,
actually,
let
me
I
do
have
a
clarifying
question.
So
in
your
example
slides
you
used
real
looking
tlds
at
the
end
of
your
of
your
zone
and
in
the
document
you
use
dollar
cat
z.
One
of
the
things
I
worry
about
is
these
will
leak
because
it's
the
dns
and
everything
leaks,
and
so
what
are
you
actually
thinking
for
naming
records
on
the
left-hand
side
of
your
records
with
respect
to.
D
D
J
J
K
G
K
H
K
A
Thank
you.
Thank
you
willem.
Thank
you,
authors
of
catalog
zones,
so
it's
close
to
working
group
last
call
right
here.
There's
some
work
to
do
for
you
for
the
working
group.
Please
review
this
document.
This
version
and
certainly
when
working
group
lost
call
you're
kind
of
obliged
to
have
a
re
review
the
document.
A
A
A
D
D
It
was
definitely
in
that
case,
so
I
want
to
try
this
again.
Today
is
a
little
bit
different
today.
I
actually
think
based
on
conversations
on
the
mailing
list
and
on
the
discussion
yesterday
that
we
may
be
at
a
good
point
for
really
wrapping
this
up
with
some
text
that
I
will
propose
at
the
end
so
based
on
discussions
yesterday
and
based
on
the
list.
We
know
that
we
want
zone
publishers
to
move
to
iterations
equals
zero.
D
I
think
there's
a
lot
of
consensus
around
that
not
today
we
know
that
we
want
validators
to
start
enforcing
lower
counts
and
that
serve
fail
is
better
than
insecure,
because
insecure
allows
takeovers
and
surveillance
at
least
denial,
but
we
want
to
do
all
of
these
at
a
reasonable
deployment
rate.
It's
not
an
instantaneous
move
that
we've
made
a
lot
of
progress
in
in
part
thanks
to
victor's
reaching
out
to
a
lot
of
people,
but
you
know
this
reasonable
deployment
rate
is
not
going
to
be
immediate
and
it's
going
to
be
large.
D
So
this
is
my
recommendation
for
how
to
modify
the
draft,
so
this
proposed
text
this
is
you
know,
actually
a
suggestion
by
paul
hoffman
that
I
made
a
little
bit
stronger
and
it's
in
section
2.3
and
it's
in
the
middle
of
a
paragraph.
So
some
of
these
are
a
little
bit
hard
to
read
out
of
context,
but
I'm
I'm
really
trying
to
propose
essentially
text
that
will
go
in.
D
D
We'll
discuss
in
a
second,
you
know
timelines,
but
but
you
know
this
is
zone.
Publishers
really
should
do
xero.
I
see
nobody
in
the
queue,
so
that's
a
win
all
right.
So
how
do
we
get
to
b
and
d
so
b?
Is
we
want
validators
to
start
enforcing
these
lower
counts?
And
how
do
we
do
this
at
a
reasonable
deployment
rate?
So
for
this
we're
going
to
steal
text
from
propose
from
petter?
Thank
you
and
it
will
go
in
section
four
that
says
really
talks
about
timelines
right.
D
J
On
my
screen
number
one
so
I'll
pretend
to
be
pull
one
so
normally
at
itf
in
in
rfcs.
We
don't
actually
put
things
like
expiry
dates
in
there.
So
and
that's
a
good
reason
for
that,
because
we
don't
really
know
or
can
predict
what
the
future
deployments
will
be
like,
so
that
we
internally
have
something
where
we
say
we'll
get
back
in
november.
2021
and
we'll
reevaluate
based
on
measurements
done
by
people
like
victor
is
great,
but
I
don't
think
there
should
be
anything
in
this.
J
D
So
this
isn't
a
time.
This
isn't
a
deadline
right.
This
is
where
we
are
today
and
it's
the
starting
point
for
what
people
might
want
to
consider.
I
recognize
I
actually
was
hesitant
to
put
this
in
the
document
too,
for
exactly
that
reason
that
rfcs,
don't
typically
have
history
in
them.
So
I
will
take
that
as
a
is
a
complaint
from
paul
that
he
would
prefer
not
to
have
it.
I
guess
paul
you're,
still
there
any
follow-on.
J
J
L
M
M
You
know
the
vendors
have
to
evaluate,
what's
actually
feasible,
to
enforce
at
any
given
point
in
time
and
you
know
adapt
the
defaults
they
ship
to
current
situation,
because
that's
what
vendors
do
anyway,
so
I
mean,
but
I
really
think
this
is
bike
shedding
because
it's
not
setting
any
expiry
date.
It's
saying
at
this
specific
point
in
time.
The
situation
was
this
and
this
I
don't
see
any
future
prediction
in
the
in
this
two
paragraphs,
so
I
don't
really
see
the
objection.
K
D
K
B
A
B
D
Right,
thank
you
sorry.
So
the
last
one
is
sir.
Fail
is
better
than
insecure,
and
so
we
talked
about
this
yesterday,
so
the
text
I'm
proposing
this.
This
totally
needs
wordsmithing.
So
let's
not
wordsmith
this
at
all.
I
sort
of
put
together
late
last
night
after
not
enough
coffee
again,
but
similarly,
because
treating
insect
three
with
a
high
iterations
count
is
as
insecurely
zoned
subject
to
attack
validating
software.
D
Vendors
are
further
encouraged
to
lower
their
default
and
acceptable
limits
for
returning
serve
fail
for
large
iteration
count,
values
and
again
we
have
text
about
dates,
and
maybe
500
is
a
reasonable
starting
point.
Based
on
the
discussion
on
the
last
slide,
I
would
argue
that
last
sentence,
we
should
just
drop
entirely.
D
M
Just
a
quick
note
from
a
vendor,
because
because
vendors
have
to
do
some
defaults
and
when
it
breaks
by
default,
users
go
to
vendors
and
cry
and
that's
the
reason
why
we
try
to
establish
reasonable
values.
That's
it
I
mean,
of
course,
operators
are
free
to
patch
the
software
or
pay
vendors
to
do
something
else,
but
this
is
about
defaults
right.
Everyone
can
change
the
software
any
way
they
want.
D
Yeah
and
some
in
some
documents
in
the
past,
we've
also
put
things
like
this
must
be
configurable.
You
must
provide
a
configuration
hub
and
we
haven't
done
that
in
this
document.
So
all
right,
I
believe
I
don't
even
know
oh
and
then
I
haven't
proposed
appendix,
but
I
think
we
can
do
that
on
the
list
and
again
that's
from
paider
all
right.
I
think
we're
done.
B
K
N
D
A
I
A
I
I'll
be
talking,
there's
no
problem
I'll,
be
talking
about
authentic,
but
automatic
dns
bootstrapping,
so
putting
in
the
s
records
into
the
parent
by
means
of
authenticated
signals
from
the
zones
operator.
I'll
explain
what
that
means.
So
today,
when
you
bootstrap
your
dns
sec
delegation,
you
have
to
somehow
get
the
ds
records
to
the
parent.
There
is
various
ways
for
this
often
involving
the
register.
I
The
registrant,
which
is
complicated,
doesn't
even
know,
dynastic
exists
and
all
this
and
all
of
the
different
methods
have
some
downside
at
least
one
of
being
unauthenticated
like
cds,
from
insecure
or
out
of
band
or
being
slow
things
involving
multiple
steps,
for
example,
registrant
and
error
prone
too
many
parties,
no
automation
and
so
on,
especially
the
authenticated
workflow
involves
too
many
steps.
So
you
started
the
dns
provider,
which
has
the
key
material,
usually
the
registrant
fetches
it
through.
Some
web
interface
then
goes
into
the
registrar.
I
I
I
Once
you
have
this
mechanism,
you
can
use
it
to
publish
an
authentication
signal.
You
start
out
with
the
cbs
and
cd
and
sq
records
at
the
apex
of
the
target
domain
of
the
customer's
domain,
and
you
just
co-publish
them
under
that
signaling
namespace
and
under
the
signaling
namespace
it
will
be
signed
with
the
ns
zones
keys.
So
that's
from
the
operator
you
can
validate
that,
so
you
can.
As
a
parent,
you
can
fetch
the
cds
records
as
usual
from
the
customer's
target
zone
from
your
child,
then
validate
it
against
this
using
dns.
I
And
if
that's
successful,
you
can
provision
the
ds
records
in
the
parent.
That's
what
we
call
transferring
trust
from
the
pac
from
to
the
target
domain,
and
you
should
clean
up
records
when
you're
done
to
make
sure
there's
no
clutter
hanging
around
there's
a
visual
representation
of
this,
which
is,
I
guess,
nice
to
have.
Let's
start
out
with
dotnet
and
dot
com.
Dot
com
is
where
the
example
dot
com,
customer
will
reside
and
dot
net
is
where
the
provider
has
a
host
name
for
its
name,
server,
which
is
securely
delegated.
I
I
I
This
avoids
hitting
length
constraints
and
has
other
implications
too,
but
it's
a
point
of
contention
and
I
think
it
would
be
great
to
get
the
working
groups
input
on
that.
So
we
can
either
do
that
after
this
presentation
or
maybe
on
the
list.
I
also
have
slide
on
that
separately,
so
hang
on,
and
there
should
also
be
an
extra
label
before
the
names
have
a
host
name.
Here.
It's
called
underscore
boot
so
that
you
can
delegate
the
signaling
data
to
a
separate
zone.
I
I
So
question
is
how
frequent
that
is,
and
we
did
an
analysis
from
the
tranquil
top
1
million
data
set
and
we
looked
for
all
insecure
domains
which
don't
have
currently
a
validation
path,
what
the
name
server
targets
are
and
if
those
are
in
secure
zones,
when
you
have
that
you
can
compute
the
number
bootstrappable
zones,
which
is
where
all
the
nameserver
targets
are
secure,
but
the
domain
self
itself
doesn't
have
dnsc.
Yet
so
by
looking
at
that,
we
probably
could
have
done
better.
We
had
a
bit
of
a
failure
rate.
I
We
also
brought
this
down
by
top
level
domain
and
by
provider.
So
you
can
see,
for
example,
that
of
the
dot
com
domains.
23
are
bootstrappable,
which
is
120
000
and
the
numbers
are
not
as
large,
obviously,
but
still,
I
would
say,
significant
for
other
tlds
and
then
by
provider.
We
looked
at
the
the
name,
server
zones
soar
name
field,
and
if
there
is
if
this
was
non-ambiguous,
then
we
put
it
here
and
you
can
see
that
cloudflare,
for
example,
has
250
000
domains
amongst
the
top
million
76
of
which
are
bootstrappable.
I
Here's
the
slide
on
whether
we
want
the
hash
label
or
not
I'll.
First
talk
about
what
are
the
pro
arguments,
because
it's
currently
in
the
draft-
and
I
want
to
explain
why
it's
in
the
draft.
I
have
personally
no
stakes
at
all
and
it
would
be
inappropriate,
obviously,
as
I
will
also
say,
the
the
against
arguments,
but
only
afterwards.
I
I
Then
it
also
improves
privacy
during
discovery
because
to
do
an
insect
walk,
you
need
to
know
the
hash
of
the
parent.
So
if
you
have
some
private
enterprise
domain,
for
example,
nobody
would
reasonably
be
able
to
do
an
insect
walk
if
they
don't
know
where
to
start,
and
it
gives
you
a
flat
structure
which
may
simplify
the
scanning
logic.
If
you,
for
example,
know
ahead
of
time
that
you
only
have
two
labels
here
in
all
cases
and
in
case
so
that's
an
idea
I
just
had.
I
I
don't
know
if
that's
reasonable
at
all,
but
one
could
say
that
one
should
have
a
more
general
signaling
mechanism.
So
it's
called
underscore
signal
not
underscore
boot,
and
then
the
specific
signal
would
be
specified
as
a
prefix.
Just
like
the
properties
for
the
catalog
zones.
We
underscore
cds,
for
example,
and
yeah.
I
Counter
arguments
are
to
smash
the
hash,
and
so
obviously
it
has
complicated
implementation.
All
cooling
needs
to
be
able
to
hash,
makes
debugging
more
difficult.
You
can't
just
use
dig
you
need
to
get
the
hash
somewhere
and
also,
I
think
most
notably.
It
was
pointed
out
that
synthesis
is
more
difficult
if
you
have
a
hash,
because
imagine
a
request
comes
in
for
example.samh
and
you
would
like
to
dynamically
serve
cds
records
for
that.
You
somehow
need
to
look
up
what
the
corresponding
target
domain
is
from
which
to
take
those
records.
I
So
you
need
a
mapping,
but
you
need
that
for
the
ancestors.
Only
so
probably
the
number
of
mapping
entries
you
need
is
few,
so
you
wouldn't
need
it.
For
example,
that's
the
order
uk.
You
would
only
need
it
for
co2k
in
this
case
also
for
those
who,
like,
let's
say,
a
special
fetish
for
weird
implementations,
you
could
probably
do
this
with
a
dname
record.
I
know
there's
implementation
problems,
so
it's
a
half
serious
idea,
it's
cashable,
but
per
parent,
so
it
wouldn't
be
much
of
an
extra
performance
penalty
yeah.
I
So
what
now?
We
have
a
signaling
mechanism
of
zone,
specific
information
from
the
an
s
operator
to
the
public.
It's
authenticated
in
banned,
immediate
and
requires
no
third
parties.
We
propose
to
use
it
for
authenticating,
cbs
and
cdnsk
records.
Some
people
have
expressed
interest
and
I
think
the
potential
is
quite
high,
given
the
numbers
I
showed
earlier
and
perhaps
there
will
be
other
uses
in
the
future
for
multicenter
key
exchange.
For
example,
there
was
an
idea
we
need
to
settle
on
the
naming
scheme
to
hash
or
not
to
hash.
A
A
J
Yeah,
you
did
the
wrong,
but
I
did
the
wrong
button.
I'm
sorry.
I
also
just
want
to
say,
because
I've
given
a
lot
of
comments
about
the
small
bits
of
the
proposal,
I
did
not
like.
Let
me
just
emphasize
as
well
that
the
majority
of
your
proposal
is
awesome
and
I
think
we
should
adopt
it
and
continue
with
it.
Okay,.
A
A
K
A
A
B
Sure
just
wanted
to
say
thanks
to
everybody
and
just
remind
people
that
we
had
tried
a
couple
of
things
with
reporting
more
to
the
working
group
and
running
interim
meetings
between
ietf
week
meetings
and
those
seem
to
be
successful
and
helpful
to
everybody.
So
we're
going
to
continue
to
do
those
things
and
watch
for
questions
about
proposed
dates
and
proposed
agendas
for
the
next
interim.
A
Yeah
indeed,
thank
you.
I
would
like
to
thank
you,
the
working
group
for
your
well
positive
discussions,
really
good.
I
really
enjoyed
the
sessions
from
today
and
yesterday.
Please
continue
discussing
these
issues
on
the
mailing
list
and
also
excuses
we're
running
out
of
well
four
times
four
times
four
minutes
beyond
the
time.