►
From YouTube: IETF116-DNSOP-20230330-0030
Description
DNSOP meeting session at IETF116
2023/03/30 0030
https://datatracker.ietf.org/meeting/116/proceedings/
A
B
B
B
So
we'll
go
through
the
chair,
slides
first
and
then
we'll
get
into
our
regular
agenda.
Tim
is
not
with
us
in
person,
but
is
out
in
The,
Ether
and
Beno
and
I
get
to
be
here
in
real
life
and
see
all
you
lovely
people,
so
we're
good
I
found
out
Tim
and
Suzanne
Warren,
who
is
not
who's,
also
not
in
the
room,
but
it's
recovering
from
being
ill
and
we
look
forward
to
hearing
from
him
the
usual
things
about
chat
rooms.
Minutes
thanks,
Paul
Hoffman
for
taking
care
of
that.
For
us.
B
B
B
A
couple
more
meeting
tips
that
the
chairs
were
asked
to
make
sure
the
room
had
heard
this
session
is
being
recorded
for
in-person
participants,
make
sure
to
sign
into
the
session
using
mediaco
from
the
data
tracker
agenda,
use
medeco
to
join
the
mic.
Cube
It's,
especially
appreciative
if
you
can
do
that,
because
that
helps
us
manage
between
the
virtual,
the
virtual
and
physical
cues,
keep
your
audio
and
video
off,
if
not
using
the
on-site
version,
and
please
wear
masks
unless
actively
speaking
on
a
microphone.
B
C
B
B
B
D
D
So
thanks
Susan
and
thanks
Beno
thanks
all
so
we
have
a
bunch
of
document
updates
and,
as
you
can
see
since
our
last
meeting,
the
dnsc
BCP
is
now
published
and
thanks
for
Paul,
for
putting
the
effort
into
that.
We
appreciate
that
sitting
in
the
editors
too,
is
the
catalog
zones
document
just
sort
of
waiting
for
the
editors
to
get
to
it,
it's
all
in
good
shape.
So
that's
pretty
good.
D
Did
you
do
to
the
next
page?
Sorry,
there
we
go,
I
see
it
now.
The
service
B
document,
as
you
all
remember,
was
sort
of
stuck
in
the
editor's
queue
waiting
for
the
ensi
document,
and
this
was
sort
of
holding
up
a
bunch
of
stuff.
So
Warren
did
his
super
magic,
stuff
process
magic
and
he
brought
it
back
to
the
working
group.
The
authors
removed
those
sections
and
we
it's
back
in
the
process
and
it'll.
It's
an
ietf
last
call
already,
and
it
will
end
next
week.
D
The
much
shorter
ens
eye
portion
will
most
likely
end
up
in
the
TLs
working
group,
because
it's
it's
a
very
small
document
and
it's
probably
more
relevant
there
and
they
can
sort
of
have
fun
with
that.
So
thanks
all
of
course,
the
all
TLD
document,
which
is
kept
Morgan,
Paul
sort
of
busy.
That's
an
ietf
last
call
as
well.
That
goes
another
week
until
the
10th
looks
like
things
are
good,
but
with
that
wrapping
up
Christian
is
hoping.
D
D
We
do
have
several
documents
in
this
post
working
group
last
call
State
and
we
I
finally
realized
today,
like
hey
I,
can
put
these
I
can
put
notes
in
the
data
tracker,
so
it
shows
up
in
a
weird
spot,
and
so
that's
that's
kind
of
strange,
but
it's
it's
at
least
a
start,
so
the
first
one
is
to
avoid
fragmentation.
Thank
you,
Suzanne.
D
There
are
some
comments
from
the
implementers
on
deployment
guidance
that
was
sent
to
the
mailing
list.
So
we
attempted
to
summarize
those
comments
in
an
organized
fashion
into
an
implementation
appendix
and
the
author's
published
version
12
today,
and
there
was
some
communication
mix
up
on
our
part.
It'd
be
good
to
get
some
reviews
and
good
to
get
feedback
from
the
working
group,
because
there
is,
there
seem
to
be
some
strong
opinions
on
what
they
will
and
will
not
do,
and
and
I'd
like
to
hear
what
people
sort
of
think
about
that.
D
D
I,
don't
think
we
sent
a
note
to
the
list,
but
please
see
the
author's
note
to
the
mailing
list
regarding
the
sibling
blue
part
that
is
really
relevant
and
Schumann
and
Dwayne
both
made
very
good
comments
about
that
so
and
I
think
both
of
those
are
in
pretty
good
shape.
So
then
we
sort
of
come
up
to
the
domain
verification
techniques
which
actually
Siobhan's
sort
of
talking
about
here.
D
In
a
bit
and
I,
we
felt
that
the
working
group
last
call
had
hit
consensus,
but
there
was
a
little
bit
of
stickiness
around
a
few
around
the
token
top
concept
that
seemed
to
be
resolved,
but
there
are
some
editorial
clarifications:
I
see
them
in
the
GitHub
repo
that
the
authors
want
to
sort
of
put
together
and
Siobhan's
gonna
do
a
little
sort
of
update
on
what's
going
on
there
I
think,
because
it
went
from
an
informational
to
a
BCP.
A
few
people
felt
things
had
sort
of
changed
along
the
way.
D
We
have
some
editorial
comments
that
came
in
most
of
them,
helping
to
clarify
the
language
and
we're
working
with
the
authors
and
reviewers
to
get
those
addressed
and
I.
Think
one
of
the
authors
who
we
have
signed
up
to
help
work
on
that
is
in
the
room,
and
so
we
will
work
with
you
Ed
to
make
sure
those
things
get
sort
of
sorted
out
and
mostly
it's
more
clarification
and
sort
of
cleaning
up
the
language.
D
D
We
really
I
want.
We
want
to
get
a
couple
of
these
documents
and
working
that's
called
moving
along,
not
all
of
them,
but
just
a
couple
before
we
start
moving
these,
but
we
want
to
make
sure
we
get
good
working
group
feedback
to
help
us
on
these
working
group
class
called
documents.
So
and
next
page
we
do
have
some
more
documents
that
are
kind
of
being
worked
on.
D
Oh,
did
we
miss
a
page
yep
the
DNS
Peter's
DNS,
like
bootstrapping,
there's
I've,
seen
we've
seen
a
bunch
of
nice
sort
of
comments
and
edits
from
Peter.
We
want
to
sort
of
double
check
with
him.
We
we
think
it's
pretty
close
and
we
failed
to
sort
of
track
him
down.
That
was
our
fault
and
as
revalidation
the
authors
seem
to
have
resolved
all
their
outstanding
to
Do's,
I
think
mostly
removing
text
that
seem
to
be
helpful.
D
So
thanks
Schumann
data
set
automation.
We
we
think
we
kept
thinking.
It
needs
another
author,
because
it's
sort
of
stuck
but
we're
waiting
to
sort
of
figure
out.
What's
going
on
there,
surface,
B
Dane
has
been
quiet
and
then
on
the
agenda
today
is
structured,
DNS,
error,
page
it's
on
there
twice,
so
it
seems
to
be
a
Hot
Topic.
D
D
B
D
E
Okay,
good,
that's
good!
Thank
you!
Thank
you,
yeah,
so
I'm
here
to
talk
about
the
green
name
system.
That's
a
document!
That's
not
part
of
this
working
group
officially,
but
somewhat
related,
since
it's
the
new
name
system,
not
the
domain
name
system.
Next,
so,
as
you
all
know,
DNS
censorship
is
widespread.
Dns
is
part
of
the
mass
surveillance
apparatus
and
we
also
have
injection
attacks.
E
E
E
For
example,
if
you
have
you
know,
www.example.dns.alt
looks
like
a
DNS
name
and
you
could
have
the
whatever
gns.alt
there's
a
Zone
example
in
there,
and
then
that
could
delegate
to
Sub
Zone
ww
or
to
a
record
in
our
configuration.
You
would
then
typically
put
for
any
Zone,
the
respective
public
key
of
the
authority
that
would
sign
the
records
in
that
zone
and
that's
kind
of
how
you
start.
E
The
resolution
process
is
by
configuring
for
any
kind
of
domain,
name
that
you
want
what
the
public
key
is
supposed
to
be
next,
so
the
key
features
of
DNS
is
first
of
all,
it's
compatible
gns
is
compatible
with
DNS,
so
you
could
use
it
as
a
drop
in
replacement
and
resolve
DNS
names
using
gns.
The
key
feature
is
that
you
get
a
query
and
response
privacy.
So
if
somebody
asks
a
question
in
gns
near
the
Zone
public
key
nor
the
label
become
public
knowledge.
E
The
server's
answering
those
queries
do
not
know
what
the
question
was
and
I
do
not
know
what
the
answer
was.
So
the
record
can
remain
a
secret
between
the
Zone
publisher
and
the
person
performing
the
name
resolution,
of
course,
under
the
assumption
that
the
zone
or
the
label
remains
secret
as
well,
because
of
course,
if
you
can
ask
the
same
question,
you
should
get
the
same
answer.
E
E
E
We
have
two
different
implementations
in
C
and
go
we've
done
a
usability
study
that
basically
shows
the
users
wouldn't
even
know
that
they're
using
gns
over
DNS,
and
we
have
a
way
to
migrate,
DNS
zones
into
gns
automatically
and
we've
run
this
on
large
zones
like
dot,
FR
dot,
SE
that
we
have
public
access
to.
You
can
install
the
software
and
run
it
if
you
have
a
appropriate
free
software
distribution.
Next.
E
Okay
so
as
we
can
resolve
DNS
names
in
gns,
you
know
there's,
of
course,
this
possibility
of
having
a
conflict.
The
dot
outdraft
tries
to
address
this
challenge.
It
doesn't
specify
a
registry
for
DOT
alt,
which
I
personally
think
is
a
mistake.
The
new
net
project
runs
the
Ghana
registry,
where
we
are
putting
in
a
registry
for
DOT
out,
so
you're
welcome
to
come
to
us.
E
H
Hi
so
two
things
first
off
I
just
realized
that
I
still
owe
the
JNS
authors
or
actually
I,
guess
the
ISE,
a
email
reply,
I
just
found
a
thread
that
had
been
looking
at
me,
so
I
will
hook
to
reply
and
hopefully,
by
the
end
of
the
day
and
then
also
for
the
working
group.
As
you
all
probably
know,
I
got
tasked
with
doing
the
conflict
review
thing.
H
H
H
This
is
conflicts
directly
with
work
in
the
ietf
and
should
not
be
published
and
those
are
sort
of
the
main
overview
of
the
positions.
There
is
some
Nuance,
so
just
so
everyone
knows,
my
position
is
because
you
know:
we've
worked
with
the
authors
and
the
ISE
to
make
it
so
that
this
won't
conflict
directly
because
of
the
suggestion
to
use
all
the
position
is
going
to
be.
You
know,
related
to
work,
does
not
prevent
publication.
I
Enough
West
herricker,
USC
isi,
I'm
on
the
a
b
and
also
on
the
ican
board
I
have
a
couple
of
thank
yous
to
start
off
with
you
know,
first
off,
thank
you
for
encouraging
the
use
of
dot
alt
and
actually
doing
that
separation.
The
IB,
as
you
know,
has
a
a
document
that
is
quite
old
saying
you
know.
A
unified
namespace
is
beneficial
to
end
users
because
it
gets
confusing
if
it's
not
so
greatly
appreciate
yoga's
willingness
to
adapt
to
that
Second.
I
Thank
you
for
all
the
cool
technology
that
is
in
you
know.
This
I've
said
this
before
you
know:
I've
read
the
the
the
new
DNS
specification
before
and
there's
a
lot
of
cool
math
that
you
know,
I
think
is
pretty
novel
and
you
know
will
help,
even
even
if
it's
not
used
in
the
future,
which
I
hope
it
is.
But
even
if
it's
not,
it
will
still
drive
new
technology,
and
so
thank
you
for.
I
One
one
final
point,
though,
is
that
everybody's
been
concentrating
on
the
naming
conflicts
at
this
point
you
know,
especially
with
respect
to
tlds
and
things
like
that.
There's
other
conflicts
in
the
document
that
I
have
marked
up
written
of
the
document
that
conflicts
with
the
DNS
protocol
in
other
ways,
for
example,
you're
reusing,
RR
types,
but
you
have
a
larger
field,
so
you've
essentially
co-opted
the
rest
of
the
numeric
values
beyond
the
existing
ietf
specifications.
E
Yeah
I
mean
we
deliberately
said:
okay.
The
current
DNS
protocol
only
allows
the
16
bits
and
they
seem
to
be
enough
for
the
foreseeable
future.
So
we
didn't
see
a
reason
why
DNS
would
expand
it,
and
so
we
used
a
32-bit
address
space
to
avoid
record
type
conflicts
and
said
the
lower
ones
are
the
ones
of
DNS
and
we're
going
to
stick
to
that,
and
we
only
want
to
use
those
above
2
to
the
16.,
in
the
hope
that
this
would
not
generate
conflicts.
E
Now
we
have
the
Ghana
registry,
where
our
types
will
be
registered
and,
of
course,
if
the
ITF
in
the
future
were
to
decide
that
they
need
for
some.
For
me,
incomprehensible
reason
more
than
two
to
the
16
record
types,
we
might
just
combine
the
two
Registries
to
avoid
conflicts
on
that
level
as
well.
I
think.
F
F
No,
so
you
use
this
word
on
slide
six
about
by
implication.
The
registry
function
that
you're
going
to
implement
the
registry
function,
to
resolve
differences
between
parties
and
to
refine,
who
has
delegation
under
dot,
Alt
and
I
I
struggle
a
little
with
that
concept
set
against
the
idea
that
dot
alt
is
effectively
structure,
free
and
I.
Understand.
First
occupant
has
some
expectation
of
behavior,
but
this
becomes
a
process
question
which
is
not
really
a
technical
question.
It's
a
process
question
who
is
adjudicating
these
delegation
questions
well.
E
I
went
to
this
working
group
about
10
years
ago,
and
we
said
we
have
a
bunch
of
special
use,
top
level
domains
like
dot
onion,
which
was
effectively
passed,
Dot,
i2p
and
so
on.
That
were
not
and
the
goal
was
to
avoid
conflicts
with
the
DNS
namespace
because,
as
we
just
heard,
a
unified
namespace
is
beneficial
for
users,
highly
beneficial.
E
Probably
beneficial
beneficial,
and
if
that
is
our
goal,
that
we
avoid
these
kinds
of
conflicts
right
then
the
best
way
of
doing
you
know
this
allocation
is
to
basically
say:
okay.
This
is
actually
a
real
implementation
effort
on
actual
protocol
design
that
deserves
to
have
a
a
unique
suffix
so
to
speak,
and
that's
the
only
education
we're
going
to
do
is
you
know.
E
First,
come
first
serve
on
somebody
who
implements
a
new
name
system
and
I
think
that's
again
beneficial
to
users
that
want
to
have
this
conflict
avoidance,
which,
for
me,
is
the
main
motivation
behind
dot,
alt
yeah
and
not
this.
We
need
something
completely
unstructured
wild
west,
where
users
will
not
have
this
common
expectation
of
names
not
having
conflicts.
F
F
An
outside
scope
of
this
room,
but
I
was
intrigued.
You
put
them
on
the
slide,
so
the
word
reserves
kind
of
took
me
there.
The
second
part
is
the
Collision
of
protocol.
Are
our
types
that
is
a
registry
function
right,
so
I
mean
if
you
front
up
and
say,
hey
we're
starting
to
consume
these.
You
shouldn't
be
spinning
an
alternate
registry
of
use.
You
should
be
lodging
them
in
the
same
register.
B
J
Good
evening,
good
afternoon,
I
good
morning
and
first
of
all,
I
just
would
like
to
add
my
thanks
to
the
working
group
and
the
authors
and
the
ads
as
the
internet
as
the
independent
submissions
editor
I
wanted
to
make
one
clarification
and
one
request,
and
by
the
way,
it's
a
pleasure
to
see
the
authors
in
person
or
on
video
because
we
haven't
actually
met
the
independent
submissions.
Editor
has
not
yet
made
a
publication
decision
that
happens
pretty
much
at
the
end
of
the
process.
J
Furthermore,
I'd
like
to
just
also
invite
people
in
the
room,
virtually
speaking
if
they
have
comments
on
the
draft.
Of
course,
please
send
them
to
the
independent
submissions.
Editor
and
I
would
happily
entertain
those
and
I'm
sure
the
authors
would
benefit
from
those.
So
thank
you
very
much
and
have
a
great
rest
of
your
meeting.
L
K
K
I
think
so
far
we
have
addressed
all
the
comments
that
we
have
received,
and
we
have
few
discussion
points
next
slide.
Please
yeah
so
I
mean,
as
we
all
know,
this
craft
defines
a
sub
error
codes.
What
we
did
was
added
citations
for
each
of
the
server
codes,
so
it
makes
quite
easy
for
to
have
an
ambiguous
definition
of
each
of
these
error
codes
and
added
a
registry
for
feature
supper
codes
to
be
added
as
well,
next
slide
yeah.
K
So
what
we
have
done
is
we
have
mapped
these
sub
error
codes
to
the
error
codes
that
are
already
defined
in
RFC
8914.
So,
basically,
all
these
error
codes
map
back
to
either
block
censored
or
filtered,
and
we
had
a
had
a
good
discussion
internally
on.
Why
is
there
a
need
to
use
forced
answer
and
we
thought
it
was
not
required
next
slide,
please
that
should
give
an
explanation.
K
So
what
we
thought
was
the
fourth
answer
basically
is
forging
the
response
and
the
client
is
losing
the
DNS
error
response,
which
is
block
censored
or
filter
which
gives
additional
meaning
to
these
sub
error
codes.
So
in
this
specific
case,
where
it
is
edgy
supporting
client
which
is
using
this
extended
error
codes,
we
felt
there
was
no
need
to
use
the
forged
answer
for
the
clients
which
support
Ade
next
slide.
K
So
we
did
bunch
of
changes
to
address
to
explain
the
changes,
how
it
aligns
with
RFC
8914,
and
we
also
added
information
to
say
that
the
information
in
fields,
especially
the
contact
justification
for
blocking
or
filtering
a
domain
and
the
organization
Fields,
will
be
only
displayed
if
the
resolver
has
sufficient
repetition
to
address
the
comment
with
regard
to
utf-8,
we
extended
it
to
allow
utf-8
as
well,
but
we
couldn't
address
the
user
preferred
language.
We
have
the
same
issue
as
RFC
8914
and
the
other
challenge
that
we
saw
was.
K
K
Yeah
so
since
we
have
already
defined
several
Json
attributes,
we
were
thinking
what
is
the
best
way
for
a
feature:
specifications
to
add
new
attributes
to
the
sign
or
registry,
whether
we
want
to
go
with
the
designated
experts
or
a
more
restrictive
policy
by
requiring
IDF
review.
We
would
like
to
hear
your
comments
from
the
working
group
on
that.
K
Yeah,
the
current
version
for
the
sub
error
codes
requires
an
expert
review
for
registering
new
sub
errors.
We
can
use
the
same
policy
for
even
the
Json
attributes
and
we
would
like
to
hear
comments
on
any
other
additional
items
that
we
need
to
record
in
the
guidelines
for
adding
new
sub
errors.
Certain
Json
attributes
next
slide.
N
B
G
O
Think
there
are
a
lot
of
places
in
the
world
where
a
return
type
code
to
indicate
why
something
is
blocked.
You
know
a
where
the
the
legal
system
would
love
to
have
a
return
type
code
of
blasphemy
to
explain
why
something
is
blocked.
I
think
that
these
are
there's
high
level
of
policy
sensitivity
here
and
I
would
not
want
to
put
that
on.
A
designated
expert
I
think
that,
ultimately,
the
the
iitf
needs
to
have
the
Change
Control
there.
K
P
Hello,
Tommy,
Polly,
Apple,
yeah,
I
think
for
the
review.
I
agree
with
Ben
I.
Don't
have
a
particularly
strong
opinion.
There
I
think
either
works.
The
two
things
I
wanted
to
say.
One
I
just
filed
the
issue
as
I
was
reading.
This
I
noticed
that
the
document
cites
some
like
specific
browser
strings
about
what
happens.
If
you
see
certain
errors,
I'd
love
to
see
that
be
a
bit
more
generalized,
because
that's
one
snapshot,
and
also
like
assumes
that
browsers,
aren't
looking
at
extended
DNS
errors
at
all.
P
P
Yes,
so
I
I
think
I
understand
the
rationale
for
that
of
you
know,
don't
block
it
and
give
a
reason
and
not
tell
me
how
to
follow
up,
but
you
know
in
that
case
this
field
is
kind
of
expecting
it
to
be
some
specific
contact.
Uri
types
I
think
there
are
cases
where
there
may
be
other
context
or
let's
say
we
add
more
Fields
here-
that
potentially
could
supersede
needing
contact
in
that
format.
P
So
I'm
just
a
little
bit
concerned
about
being
mandatory
that
you
have
to
come
up
with
some
telephone
number
or
email
address.
You
know,
for
example,
there
are
cases
today
where
we
allow
a
DNS
configuration
to
be
installed
by
an
application
that
can
say
I
want
to
configure
this
encrypted
DNS
service
from
my
whole
device.
That
does
this
filtering.
P
C
P
I
I,
no,
no
I
I
meant
we
don't
paint
ourselves
into
a
corner
as
this
group-
oh
sorry,
yeah
some
client
operating
system
or
browser
or
application.
Yet
whoever
is
processing
the
error
if
yeah,
if
it
is
just
getting
the
error
from
a
DNS
server
that
comes
from
you,
know,
DHCP
on
your
local
network
yeah.
Absolutely
it's
going
to
be
useful
to
get
contact
info,
but
there
may
already
be
other
contexts
in
how
that
DNS
resolver
was
provisioned.
That
will
not
be
necessary
to
include
here
as
a
telephone
or
email
address.
K
Yeah
that
makes
sense
to
me.
In
fact,
if
you
see
that
field
that
we
have
defined,
we
don't
in
fact
define
what
what
should
be
there
in
that.
But
we
give
suggestions
like
it
could
be
sips,
URI
or
a
telephone
format
or
something
else,
because
we
were
not
sure
what
are
all
the
contact
mechanisms
that
could
be
there.
So
we
just
give
examples
on
how
it
would
look
like,
so
we
are
not
mandating
on
whether
it
should
be
adjusted
telephone
number
or
receipts
URI,
so
they're
just
just
examples
that
were
quoted
there.
P
Impression
is
that
it
that
I,
you
do
need
to
include
some
value
for
this
c
contact
entry,
and
it
does
need
to
be
a
list
of
Uris
Okay.
So
I'm
just
worried
that
that
may
be
a
little
bit
too
narrow.
If,
like
we
may,
have
people
end
up
putting
just
like
placeholder
Uris
in
there,
because
it's
the
thing
that
they
want
actually
isn't
a
URI.
It's
some
other
context.
They
have
sure.
G
G
L
G
L
L
So
this
is
for
customers
that
are
subscribing
network
based
security
products,
for
example
the
Vodafone
Secure
net.
The
traffic
flow
in
this
case
is
in
in
case
of
a
clean
request
operator.
Dns
respond
with
the
proper
IP
address
in
case
of
a
malicious
content.
The
the
operator
DNS
respond
with
a
blocking
page.
L
It
was
all
fine
before
the
encryption
era,
so
in
case
of
HTTP
request,
it
was
possible
for
the
customer
to
see
a
blocking
page,
so
good
user
experience,
but
high
risks
of
I
mean
the
middle
attacks.
The
customer
understood
the
reason
of
blocking
and
was
aware
of
it
of
the
protection.
After
the
rise
of
encryption,
there
are
much
lower
risk
of
men
in
the
middle,
but
the
user
experience
is
bad,
so
we
are
still
able
to
protect
customers,
but
we
are
not
able
to
show
the
reason
of
blocking
customers
is
angry.
L
L
L
Q
L
Q
R
L
So,
in
this
case,
I
enabled
the
extension.
This
is
a
fake
malware
page
and
in
case
the
plugin
enabled
I
see
the
blocking
page
with
the
the
log
of
the
security
product
and
the
reason
there
is
an
explanation
so
that
the
customer
can
be
aware
we
can
have
a
several
level
of
blocking.
In
this
case,
a
block
also
for
parental
control
is
reason.
So
this
is
a
fake
idle
site
and
the
while
it
is
blocked.
I
can
see
the
blockade
for
parental
controls
reasons.
L
I
Q
So
the
actual
return
code
is,
as
you
saw,
on
each
domain,
so
we
want
to
when
we
want
to
block
stuff.
We
don't
want
people
to
go
there,
so
it's
I
mean
in
the
old
days
as
during
composite.
We
would
have
returned
an
IP
address
of
a
web
server.
These
days
we
only
do
NX
domain
and
then
the
actual
web
page
that
presents
the
blog
page
is
in
the
Ed
error.
Okay,.
I
But
you
could
have
a
main
page:
that's
okay,
with
content
from
another
name
that
you
are
blocking,
and
so
what
does
the
UI
do?
In
that
case,
where
the
main
page
you
know
domain
is
fine
and
you're
requesting
CSS
from
malicious.com
the
the
then
you
can
no
longer
use
because
it's
being
blocked.
You
can't
show
the
error
code
as
well
right.
K
Yeah
when
we
were
discussing
the
draft,
one
of
the
major
comments
was
not
to
display
any
new
pages
right
beyond
the
error
codes
so
that
the
browser
would
render
them
or
an
app
would
render
them.
So
the
idea
was
you:
don't
want
the
end
user
to
go
to
some
other
page
which
would
probably
mislead
the
user
into
something
else.
L
G
K
L
J
G
S
S
Oh
perfect,
cool
yeah,
so
we've
been
working
on
a
on
a
draft
for
a
while.
It
was
an
informational
draft,
but
then
folks
said
that
it
just
makes
sense
to
make
it
a
BCP,
so
we've
been
kind
of
plugging
away
at
it
for
a
while
and
yeah,
as
I
mentioned,
we
did
a
last
call
recently
and
we
had
some.
We
had
some
comments,
so
I'll
go
through
some
of
the
changes.
We're
planning
to
do
and
folks
can
opine
about
what
they
think
about
that,
but
just
as
a
refresher.
S
What
is
domain
verification?
The
idea
is
that
many
providers
on
the
internet
need
people
to
prove
that
they
control
a
particular
domain
before
granting
them
some
kind
of
privilege.
So,
for
example,
the
you
know,
a
great
great
example
is
Acme,
which
has
a
dns-based
challenge
for
a
user
to
prove
that
they
control
a
particular
domain
and
hence
they
should
be
issued
a
certificate
for
it
so
and
yeah,
and
previously
we
had
just
a
survey
where
we
talked
about
text
and
cname
and
then
with
the
BCP
we
said.
S
Okay,
so
it's
it
seemed
like
text
was
just
the
right
way
to
do.
It
and
CNA
might
lead
to
issues,
but
then
we
did
get
some
feedback
that
maybe
we
should
still
keep
seeing
him,
but
not
recommended,
and
just
say
that
this
is
an
option
that
folks
can
do,
but
we
still
recommend
using
text
so
and
not
be
too
prescriptive
about
the
fact
that
people
cannot
use
cname,
because
it's
definitely
a
thing
that
people
do
right
now
and
is
you
know,
is
fine.
S
S
The
the
idea
behind
this
draft
is
that
in
in
Practical
deployments
right
now,
the
it's
often
like
tons
and
there's
often
tons
and
tons
of
records
that
really
bloats
up
the
you
know
DNS
response,
and
then
you
kind
of
kind
of
you
kind
of
have
to
fall
back
to
DCP,
and
that
leads
through
issues.
So
so
that's
the
suggestion
was
to
make
it
very
clear
in
the
record
itself
when
the
record
can
be
removed.
S
And
yeah,
and
then
you
can
also
have,
if
you
have
multiple
features
that
you're
trying
to
do,
then
you
can
just
kind
of
keep
prepending
to
the
left.
So
you
have
like
underscore
feature
one
as
an
example,
and
we're
also
think
that
you
must
provide
clear
instructions
on
when
the
record
can
be
removed
either
through
putting
that
in
the
record
or
through,
like
some
help,
text
and
yeah,
and
then
we
also
say
that
you
should
have
detailed
help
pages.
S
S
M
C
So
my
name
is
jprs
and
so
so
yeah
so
we
demonstrate
outside.
So
we
dream
about
ourselves.
Technical
information
is
that
our
first
day
a
host
equipment
Demos
in
in
using
the
Euro
draft,
so
so
the
so
yeah
I
want
to
discuss
in
this
draft
as
after
a
vs
sessions
and-
and
so
I
want
to
add
so
recommendation
for
external
DNA
service
providers
and
ensure
that
underscore
sub
zones
of
existing
zones
cannot
be
configured
by
other
customers
on
the
same
authoritative
DNA
service.
So
yeah
underscore
name
underscore
level.
C
G
S
N
B
A
Yeah
John
Levine,
You,
probably
noticed
I
had
some
fairly
testy
exchanges
with
Paul
about
this
draft.
Yeah
I
think
it's
actually
considerably
improved
and
I
have
sort
of
one
one
and
a
half
suggestions.
One
is
I,
think
it
could
you
could
you
could
make
it
clearer
what
parts
are
intended
to
be
mechanically
interpreted
and
what,
by
but
by
humans,
but
particularly
the
thing
like
the
the
expiration
date?
It's
like
right,
yeah
like
it
would
be.
A
If
you,
if
you
could
recommend
you,
know,
put
the
expiration
date
in
this
format,
so
you
can
have
something
that
scans
your
Zone
file
and
takes
out
the
junk.
That
would
be
that's
actually
that
would
be
nice,
okay
and
and
I.
Think
you
could
also
make
it
clearer
why,
even
though
everybody
uses
I
mean
the
reality
is
C
names
are
very
popular
right
and
in
the
discussion
there
were
some
things
about
like
why?
A
Why
some
of
the
naming
issues,
maybe
beyond
what
you
say,
what
what
the
C
name
is
colliding
with
other
stuff
like
putting
long
complicated
names
and
is,
is
harder
than
putting
on
complicated
contents,
which
I'm,
not
sure
I
believe,
but
at
least
it's
a
plausible
argument,
so
I
think
you're,
pretty
close.
It's
just
like
so,
given
that
people
have
been
doing
it
ways,
you
do
not
recommend
for
a
long
time.
It
would
be
nice
to
make
it
clearer
why
you're
recommending
doing
it
this
way,
rather
than
that
way,
yeah
I.
S
I
For
verifiers
for
service
providers,
excuse
me
the
dnsi
proponent
in
me
says
it
should
be
a
must,
but
I
recognize
that
that's
not
likely
the
right
solution,
so
I
recommend
seems
good.
What
I
would
encourage
you
to
do
is
put
in
additional
text.
However,
that
says
there.
You
must
use
some
mechanism
to
reduce
the
you
know
the
chances
of
a
client,
spoofing
or
cash
poisoning,
or
something
like
that,
which
may
be
something
like
what
Acme
does
is.
You
know
query
from
all
or
let's
encryptos.
T
I
S
U
U
G
U
U
U
At
that
time
it
was
called
black
lies,
so
we've
since
renamed
it
to
just
compact
denial
of
existence
or
compact
answers.
If
you
prefer
something
more
pithy,
it
is
widely
deployed
amongst
a
set
of
commercial
online
signers
today
in
the
industry,
notably
cloudflare
ns1
and
Amazon,
Route
53
and
one
of
its
distinguishing
and
controversial
features
is
that
it
eliminates
NX
domain
responses
completely
so
or
at
least
the
traditional
conception
of
NX
domain,
and
that,
as
you
might
expect,
has
some
operational
implications
next
slide,
please
all
right.
U
So
what
this
does
is
for
names
that
don't
exist
it.
These
implementations
pretend
that
it
does
exist.
It
just
doesn't
have
any
resource
records
for
the
type
you
queried
for
so.
In
other
words,
it
returns
a
rather
than
an
NX
domain
response
and
no
data
answer,
and
crucially
in
that
answer,
is
a
dynamically
generated
and
signed
nsac
record
with
proof
of
the
no
data
and
the
stated
rationale
stated
benefit
for
this
scheme.
Is
that
we
get
more
compact
answers
so
assigned
no
data
response
requires
just
one
nsec
record
in
this
corresponding
RR
Sig.
U
So
there's
another
reason
which
I
sometimes
forget,
but
Christian
reminded
me
of
recently
that
a
lot
of
these
implementations,
for
whatever
reason
you
can
debate
whether
this
is
a
good
idea
or
not,
but
they
have
challenges,
understanding
the
tree
structure
of
the
DNS
Zone.
So
for
an
MX
domain
response.
What
you
need
to
do
is
you
need
to
find
the
ancestor
of
the
name
that
didn't
exist
to
compute
the
closest
closer,
so
that
you
can
generate
the
the
proof
that
a
wildcard
couldn't
have
generated
the
answer
right.
So
that's
a
concern.
U
We
can
have
a
debate
about
whether
that's
the
correct
way
to
implement
a
DNS
Zone,
but
I.
Don't
think
this
is
the
right
way
to
do
the
right
place
to
do
that.
There
are
lots
of
these
implementations
out
there
in
the
industry
by
many
companies.
So
next
slide,
please
all
right.
So
what
are
the
operational
implications
of
this
scheme
for
typical
end
user
applications?
Probably
nothing.
In
most
cases
a
no
data
response
is
treated
almost
identically
to
an
Annex
domain.
U
There
are,
however,
a
no
data
result
can
result
in
additional
follow-on
queries
for
additional
types
of
the
same
name,
and
this
actually
has
been
observed,
and
it
does
happen
because,
if
you
think
of
the
very
common
case
of
a
dual
stack
host,
a
common
DNS
query
pattern
is
a
quad
a
followed
by
an
A.
So
if
the
quantity
didn't
exist,
an
Annex
domain
would
have
immediately
suppressed
the
following
query,
whereas
in
this
case
it
will
generate
those
additional
queries.
U
But
apart
from
that,
there
are
a
variety
of
diagnostic
troubleshooting
and
traffic
characterization
tools
that
may
be
impacted
and
have
to
deal
with
this
new
protocol,
especially
tools
that
commonly
rely
on
the
correctness
of
the
DNS
Response
Code.
Now,
arguably,
we
could
say
that
in
the
age
of
dnsc
you,
you
can't
trust
the
Response
Code,
because
it
is
unauthenticated
and
can
be
spoofed
right.
But
if
that's
the
case,
then
what
we
have
to
do
is
infer
the
exist.
U
The
non-existence
of
a
name
by
looking
deeper
into
the
packet
at
sine
data
record,
specifically
the
nsac
records
and
the
question
is:
can
we
reliably
infer
the
exist
non-existence
of
a
name
from
that?
So
next
slide?
Please,
and
the
quick
answer
is
there's
a
problem
because
it
turns
out
as
the
spec
is
currently
written.
There
is
no
way
to
distinguish
an
X
domain
from
empty
non-terminal
names
because
they
share
the
exact
same
type
bitmap.
U
There
are
some
implementations
out
there
that
kind
of
hack
around
this
with
a
workaround.
By
for
empty
non-terminal
responses,
they
basically
display
a
wide
type
bitmap
which,
which
is
composed
of
every
record,
that
they
support,
except
the
name
that
you
queried
for.
But
this
has
other
implications
because
then
you've
lost
distinguishability
of
emptying
on
terminals,
you've
potentially
bloated
the
size
of
the
type
bitmap,
and
you
could
potentially
confuse
tools
that
do
type
inference
from
the
type
bitmap.
So
this
is
essentially
a
hack
and
we
want
a
cleaner
solution,
not
a
hack.
So
next
slide.
U
U
All
right,
so
what
can
we
do
to
fix
the
situation?
So
essentially,
what
we
need
to
do
is
we
need
to
introduce
a
distinguisher
protocol
element
in
the
response
either
for
NX
domain
or
for
empty
non-terminals
I.
Suppose
you
could
do
it
for
both
of
them
and
I.
Think
somebody
suggested
that
in
the
on
the
mailing
list,
but
really
you
only
have
to
do
it
for
one
of
them
in
another.
U
Expired
draft
I
previously
have
proposed
an
empty
non-terminal
distinguisher
and
that
has
actually
been
implemented
and
deployed
in
the
field
by
ns1
and
is
successfully
used
by
US,
and
there
were
some
specific
technical
reasons.
I
chose
to
the
ENT
distinguisher
and
you
can
read
about
those
reasons
here:
bro,
let's
just
skip
on
to
the
next
slide,
so
here's
an
example
of
that
in
the
field.
I
think
this
is
a
real
example.
You'll
see
the
Ian.
U
This
is
a
query
for
an
empty
non-terminal,
ent1
dot,
blah
blah
blah
and
you'll,
see,
there's
a
synthetic
type,
stuffed
into
the
Anzac
type
maps
at
the
bottom
right
of
the
screen
right
now,
using
a
private
type
code.
Next
slide,
please,
and
now,
we'll
move
on
to
the
new
proposal
in
the
current
draft
is
that
we
are
instead
proposing
to
do
the
pseudotype
distinguisher
for
NX
domain.
U
Instead,
the
mnemonic
we're
proposing
for
this
is
NX
name,
which
stands
for
non-existent
name,
and
we
deliberately
chose
not
to
use
NX
domain
just
to
avoid
any
confusion
with
the
Response
Code
mnemonic
of
the
same
name.
Our
plan
is
to
use
the
lowest
available,
RR
type
in
The,
Meta
type
range
and
last
I
checked.
U
128
is
still
available
and
very
recently
cloudflare
I
think
maybe
a
week
or
two
weeks
ago,
but
Christian
can
probably
tell
you
exactly,
but
cloudflare
has
recently
done
a
preliminary
implementation
of
the
scheme
for
now
using
a
private
RR
type
code.
Although
I
sh
I
should
say
that
our
plan
is
to
ask
for
Ayanna
for
an
early
allocation
of
the
real
time
so
that
we
can,
you
know,
get
the
stuff
deployed.
U
U
In
theory,
you
could
work
with
the
developers
of
those
tools
to
enhance
them
to,
instead
of
looking
at
the
r
code
to
look
and
recognize
the
annexonomy
and
Annex
name
signal
in
the
response.
But
the
question
is:
will
that
ever
happen?
How
much
work
is
involved
in
doing
that?
On
the
resolver
side,
we
could
for
non-validating
queries
at
least
a
resolver
that
recognizes
NX
domain
could
substitute
the
annex
domain
back
into
the
r
code
in
responses.
It
relates
backs
to
those
queries,
but
I
think
we
really
need
to
have
a
solution
for.
U
Queriors
as
well
things
that
send
do
equals
one,
and
the
related
question
is:
is
there
a
way
to
put
the
NX
domain
R
code
back
into
the
response
that
is
generated
from
the
authoritative
server
itself?
That's
more
challenging
and
I
think
the
only
way
I
know
at
least
to
do
that
is
by
implementing
new
edns
signaling
with
its
complexity,
costs
I.
Think
I
received
some
pushback
about
it,
but
at
least
we
should
think
through
that
option.
Next
slide,
please
all
right!
So
here's
a
link
to
the
latest
draft.
U
U
And
finally,
my
question
to
the
working
group
and
to
the
chairs
is:
are
we
ready
to
adopt
this
draft?
To
reiterate?
Compact
answers
is
widely
deployed
in
the
industry
today,
and
yet
it
has
no
formal,
published
specification
and
I
do
not
think
that
is
a
good
State
of
Affairs
and
we
should
do
something
to
fix
that
and
also
to
make
it
work
better
by.
U
U
U
This
is
what
cloud4
in
fact
does
today,
but
some
of
the
other
providers
don't
so
we
can
recommend
that
so
the
question
I
have,
though,
is
you
know
you
could
ask?
Is
it
worth
doing
it
if
most
resolvers
today
by
default,
send
do
equals
one
query,
regardless
of
what
the
downstream
querier
does
right.
So
that's
an
open
question.
I
have
but
I'm,
at
least
in
principle,
open
to
documenting
that
if
it
helps
no.
W
Thank
you.
Yes,
please
do
and
a
small
comment
that
it
may
actually
have
an
impact
on
the
resolver,
because
the
resolver
may
say
say:
do
one
and
do
the
validation
arrive
at
something,
and
maybe
it's
actually
better
to
substitute
and
send
the
the
NX
domain
going
down
to
the
end
client
yeah.
So
that's
something
that
I
would
like
to
have
at
least
described.
That
process
described
in
the
document.
Sure.
U
X
Okay,
my
mic
is
on
now
I
hope.
I
was
also
going
to
mention.
Do
equals
one
versus
do
equals
zero
as
an
issue
at
the
resolver
response,
not
the
authority
server
response
so
that
that's
important
to
consider
and
specify,
and
that's
where
much
of
the
complexity
arises.
You
know
if
the
cost
of
supporting
this
is
having
the
resolver,
you
know
transform
the
response,
depending
on
how
the
client
asked
gets
complicated.
X
The
the
other
thing
that
should
be
specified
clearly
is
the
behavior
of
actual
queries
you
know
made,
you
know
to
me
to
probe
misbehavior
perhaps,
but
somebody
might
deliberately
send
queries
for
an
ex
name
to.
You
know,
give
the
resolvers
a
hard
time
of
the
world
and
perhaps
authoritative
servers.
How
should
either
of
those
respond
need
some
consideration
you
know.
X
So
those
I
think
are
the
the
key
things
to
flesh
it
out
fully
and
there
was
I
guess
on
the
list
or
DNS
operations,
perhaps
a
point
that
it
may
take
a
while
for
the
current
implementation
to
go
away
and
in
the
meanwhile
we
have
confusion
and
that's
why
there
was
a
demand
for
making
both
and
and
NX
domain
be
Sentinels
I,
don't
know.
If
that's
a
compelling
argument
or
not.
U
Yeah
thanks
Victor
so
on
your
I'll
I'll
work
backwards.
So
so
your
third
suggestion,
yeah
I,
mean
in
principle
I'm.
Okay
with
that,
especially
if
it
takes
a
long
time
for
implementations
to
change
to
adopt
the
late.
The
the
current
recommendation
in
the
draft
I'm
a
little
bit
more
optimistic,
I've
I've,
spoken
to
all
these
vendors
and
I,
think
my
impression
is:
they
can
quickly
change
their
implementations.
U
U
Oh
right,
yeah,
okay,
yeah
I,
agree
that,
yes,
the
draft
should
mention
what
should
happen
if
a
resolver
deliberately
sends
a
query
for
the
NX
name
pseudotype,
even
though
we
don't
expect
normal
software
to
do
that.
So
I
was
thinking
about
that
and
I
think
the
default
Behavior
might
be
okay,
it
might
just
just
work
if
you
send
a
nxname
query
for
a
name
that
doesn't
exist.
You'll,
probably
just
get
a
no
data
answer
back
right,
but
we
could
specify
that
and
for
something
that
doesn't
exist,
then
from.
U
Correct
correct
that
this
map
disproves
it
yeah
and
the
the
non-existent
name
thing
is
a
little
bit
more
complicated.
It
depends
on
the
whether
the
authority
understands
the
scheme
is
using
the
scheme
or
not
right,
but
either
way,
I
think
we
can.
We
can
write
up
a
succinct
description
of
what
we
expect
to
happen
if
we
accidentally
get
these
queries
from
whoever
or
attackers
Etc
and
on
your
first
point,
yeah
I
think
I
agree
we
will
describe
the
do
equals
one
behavior
on
both
sides
at
the
authoritative
server
and
the
resolver.
R
Okay,
so
next
Jim
Reed
Shimon
thanks
very
much
for
our
very
clear
presentation.
I've
got
much
more
skeptical
view
of
all
this
stuff
that
this
seems
to
me
rather
ugly
from
a
protocol
point
of
view
and
I.
Don't
think
that's
the
way
to
solve
the
problem.
We're
talking
about
here
and
I
also
think
this
is
a
hell
of
a
lot
of
work
just
to
shave,
a
couple
bits
or
a
couple
of
bit
bytes
offer
a
response,
I'm,
not
sure.
If
that's
the
right
course
benefit,
calculation
has
been
done
here.
V
R
U
U
Savings
yeah
I,
agree,
I
mean
when
I
first
encountered
this
game.
That
was
my
same
thought
and
I.
Think
a
lot
of
other
people
in
the
community
share
that
opinion.
But
the
truth
is,
these
implementations
are
already
out
there
and
they're
being
used
at
a
fairly
large
scale
and
I,
don't
see
it
likely
that
the
situation
is
going
to
change.
So
what
we
can
do
is
try
to
improve
these
protocols.
R
Well,
yeah
I
could
accept,
have
a
document
that
says
this
is
a
spec
for
this
stuff,
without
just
so,
we've
got
the
degree
of
interoperability
between
these
implementations,
but
I.
Don't
think
this
is
something
we
should
be
trying
to
encourage
generally
because
it's
an
ugly
hack
in
the
protocol
and
that
stats
us
on
a
very
slippery.
So
if
we
keep
tweaking
things
in
this
way
and
adding
unnecessary
complexity,
in
my
view,.
V
Yeah
so
rightly
from
a
complexity,
question
I
would
actually
say
that
this
simplifies
things
quite
a
bit,
but,
more
importantly,
we
are
already
using
this
in
in
production
and
so
are
other
implementers
as
well.
So,
and
the
issue
is
that
these
current
implementations
are
not
they're,
not
the
same,
as
already
mentioned,
and
as
one
uses
the
end
Sentinel
and
we
have
just
recently
last
week,
started
to
implement
the
NX
name
signal.
R
Yeah,
okay,
thanks
question:
we
kind
of
agree
and
disagree.
I
still,
don't
think
this
idea
is
is
as
simple
as
you're
claiming
it
is
you're,
adding
we're
going
to
have
to
add
more
code
to
them
server
implementations.
So,
in
my
view,
that's
an
incomplexity.
You're
gonna
have
to
write
code
to
cope
with
this
stuff,
so
that
has
complexity
in
my
opinion,
as
far
as
documenting
something
so
there's
an
interruptible.
We
are
doing
this
thing
even
though
I
think
it's
a
bad
idea.
I'm
quite
happy
with
that.
R
V
There
is
no,
let
me
just
respond
to
that.
You
have
you
already
have
to
deal
with
this
today
and
if
you
don't
add
any
code
to
deal
with
this
today,
you
don't
have
to
add
any
code
to
deal
with
this
tomorrow.
To
be
honest,
if
you
wanna
upgrade
these
answers
to
to
sort
of
actually
see
that
this
is
a
NX
domain,
just
responded
in
a
different
way.
Then,
of
course
you
will
need
to
add
code,
but
you
don't
have
to
do
that.
V
R
G
Q
It's
actually
a
very
short
remark,
so
thanks
a
lot
for
doing
this,
I
think
that
we
need
to
document
this,
but
in
my
opinion,
we
should
make
the
impact
to
other
players
in
the
DNS
ecosystem
as
kind
of
minimal
as
possible,
so
not
have
resolvers
do
anything
special
when
returning
an
extra
main
or
something
but
just
really
document
it
have
the
NX
name
and
the
rest.
The
rest
of
the
ecosystem
kind
of
deal
with
it.
U
B
C
M
M
T
M
M
The
CVS
stuff
is
used
for
automatic
DS
management
for
key
rollovers
dynastic
bootstrapping
stuff
like
that,
and
if
things
go
wrong,
it
has
a
potential
security
impact.
So
we
should
think
about
whether
that's
standard
resolution
is
the
correct
way.
Then
the
c-sync
specification
a
little
bit
different.
It
actually
Advocates
limiting
queries
to
just
one
authoritative
server,
so
it
does
save
it
explicitly
under
the
CDs
spec.
M
M
So
if
you
ask
a
simple,
a
single
name
Circle
only
then
obviously
you
don't
ensure
consistency
across
authoritative
name
servers
and
apart
from
the
back
and
forth
slapping
you
can
get
when
there
is
two
different
record
sets
the
two
offs
and
the
parent
scans
one
and
then
next
to
the
other.
For
example,
they
are
quite
serious
failure,
modes
and
multi-homing
scenarios
with
multis,
Nano,
stuff
and
provider
change.
Stuff
I've
talked
about
this
last
time,
so
I
moved
to
the
backup.
M
M
Mode
I
mean
it's
not
new,
but
it
occurred
to
me
so
a
paper
by
Casey
claaffy,
that
is
about
an
Epp
Quirk
that
sometimes
prevents
the
removal
of
expired
name
server
names,
and
then
you
can
hijack
at
least
part
of
the
name
of
the
DNS
traffic.
If
you
manage
to
register
that
expired
name
and
click
on
traffic,
the
query
traffic
that
you
can
send
whatever
responses
you
like,
and
you
would
think,
okay
cool
dnsic-
does
offer
Integrity
protection
against
that,
so
that
Rogan
himself
I
wouldn't
have
any
say.
M
But,
as
you
know,
about
90
of
domain
names
that
actually
use
dnsx
and
as
long
as
that
isn't
employed
more,
let's
see
what
could
be
an
attack
Vector
here
so
assume
you
have
a
main
with
an
expired
name
server.
And
then
there
are
some
other
legitimate
name
servers
still
in
operation
and
now
I'm,
the
hijacker
I'll
just
stage
one
so
to
speak
and
they
publish
their
own
Keys
via
series
or
CDs
key
records.
M
And
if
the
parent
happens
to
process
that,
then
their
the
attacker's
keys
will
end
up
in
the
DS
record
set
and
will
prevent
the
legitimate
responses
of
the
remaining
authoritative
name
servers
to
be
accepted
by
validating
with
solvers,
and
they
will
become
bogus.
So
this
breaks
the
availability
of
the
legitimate
name
service,
even
though
they
are
still
in
the
delegation
and
then
even
worse.
M
In
that
paper,
where
it
was
investigated,
how
frequent
that
kind
of
risk
is
it
turned
out
that
a
few
hundred
thousand
domains
are
exposed
to
the
risk
in
about
one-third
were
taken
over,
which
doesn't
mean
that
each
of
them
was
targeted.
Maybe
it
was
just
a
few
name
servers
and
they
were
hosting
many
domains,
but
it's
not
negligible
I
would
think
and
yeah,
so
the
draft
essentially
proposes.
All
of
that
couldn't
happen.
M
So
this
is
actually
the
last
slide.
So
the
update
since
the
last
ITF
meeting
are
very
minor,
so
the
basics
essentially
are
the
same.
When
you
process
record
types
that
start
with
a
c
as
a
parent,
then
you
must
ensure
that
they
are
consistent
across
authoritative
name
servers
and
if
one
doesn't
respond,
that's
fine
and
you
just
skip
over
it,
but
it
can't
be
that
you
get
responses
whose
contents
are
inconsistent.
M
I
think
Victor
proposed
to
add
an
optional
retry
mechanism
with
exponential
back
off
for
resolving
inconsistencies,
so
I
added
that
and
there's
also
minor
editorial
changes,
plus
the
added
motivation
that
I
just
talked
about
with
the
lame
delegation
hijacking
now.
One
thing
that
occurred
to
me
is
that
the
CDs
specification
says
that
when
you
process
that
stuff,
you
must
ensure
that
then
UTS
record
set
would
not
break
validation.
M
It
just
occurred
to
me
that
that
could
be
a
thing
that
perhaps
can
be
added
to
that
consistency,
requirements
document
if
the
working
group
feels
that
makes
sense,
and
that
actually
is
the
next
question.
What
would
be
reasonable
next
steps?
I
think
some
people
provided
feedback
already
and
last
year,
sometime
at
followers
some
discussion
on
the
list
about
it.
So
there
seems
to
be
some
interest.
G
X
I
wanted
to
mention
a
corner
case
for
for
seasync.
If
somebody
is
willingly
giving
up
a
domain,
transferring
it
to
another
party
and
the
other
party
doesn't
want
to
do
dnsic
the
target
name
servers
will
be,
you
know,
I
will
have
an
unsigned,
Zone
and
so
validating
the
validity
of
the
zone
at
the
Target
won't
be
possible.
Right
a
transfer
from
assigned
to
unsigned
via
seesync
can't
work.
No,
we
don't
necessarily
need
to
make
that
possible,
but
it's
one
corner
case
to
at
least
consider
whether
it's
in
scope
or
not.
M
Yeah
I
think
one
way
to
address
this
is
that
when
processing
CDs
we
could
consider
ignoring.
So
your
opinion
would
be
interesting.
Actually,
we
could
consider
ignoring
any
insecure
responses.
We
get
and
treat
them
like
an
unresponsive
name
server,
and
that
would
allow
even
when,
for
some
reason,
the
new
provider
that
doesn't
have
DNA
SEC
is
in
the
name
server
record
set
already.
M
G
T
Think
that
could
have
bad
implications
over
time
saying
if
it's
really
important,
don't
trust
the
dnsic
signature
talk
to
all
the
authoritative
servers,
because
someone
else
will
come
up
at
some
point
in
the
future
saying
well,
my
stuff
is
really
really
important:
I'd,
better
check,
all
the
authoritative
name,
servers
and
I.
Don't
think
we
want
to
go
there.
T
They
are
assumed
to
publish
information
that
already
strong
wants
published
if
they
don't
as
if
they
disagree
or
if
it's
out
of
sync
or
whatever.
This
is
more
of
a
reflection
on
a
potential
business
issue,
a
potential
choice
of
a
bad
provider,
a
potential
disagreement
between
multiple
providers
or
whatever.
All
of
these
are
non-dns
protocol
issues.
They
are
business
issues
and
I,
don't
think
we
should
add
complexity
to
DNS
to
deal
with
what
is
essentially
not
protocol
issues,
but
rather
business
issues.
I
Thank
you,
West
herdicker
Asin,
author
of
the
c-sync
document.
It
was
10
years
ago
and
and
I
think
I
originally
wanted
to
query
all
the
name
servers
not
because
of
getting
you
know
different
answers,
but
rather
to
make
sure
that
we
always
had
the
most
recent
version
of
something
from
an
SOA
perspective,
but
I
lost
that
battle.
I
think
at
the
time
and
I.
Don't
remember
why.
But
the
important
thing
is
that
the
the
decisions
that
were
made
were
about
the
robustness
of
keeping
the
DNS
up
and
running
right.
I
So
if
dnsc
was
required
to
do
validation
of
csync
and
all
of
the
records
that
csync
was
going
to
be
updating,
then
you
have
to
assume
that
the
cryptographic
validation
with
the
chain
of
trust
is
valid.
There's
no
other
as
Johan
just
put
it
sort
of
a
business
relationship
beyond
that.
The
the
seasync
and
CDs
documents
can't
fix
that
fundamental.
You
know
misconception
of
of
the
upward
hierarchy.
L
M
M
Okay,
so
in
principle,
I
fully
agree
that
it's
a
goal
of
DNA
SEC
that
you
only
have
to
ask
one-
and
you
know
verify
one
chain
of
trust,
but
I-
think
precisely
to
to
guarantee
that
that
property
is
a
dnastic
property.
You
have
to
make
sure
that
the
chain
of
trust
doesn't
break
for
accidental
reasons.
M
M
The
second
thing
there's
already
precedence
for
that,
not
specifically
for
what
I'm
proposing,
but
for
cases
where
you
don't
just
as
one
question
validated
as
I
said
before
the
csync
RFC
says
you
may
ask
all
of
them,
so
that
is
already
something
that
hasn't
sent.
A
very
bad
signal,
as
Johan
is
afraid
of
that
people
will
be
doing
it
all
the
time
and
second,
the
CD
aspect,
for
example,
says
you
have
to
assign
and
check
that
the
CCS
record
is
signed
with
a
ksk
and
not
with
the
zsk,
for
example.
M
G
T
Next
slide,
please,
so
this
is
about
work
that
Peter
and
I
did
following
the
the
last
iitf,
the
one
in
London
and
the
the
starting
point
for
this
is
the
the
problem
statement.
So
to
speak
is
that
scanning
is
costly
and
we
have
a
growing
number
of
scanning
things
in
DNS.
Now
we
have
CDs
scanning
and
we
have
seizing
scanning
and
we
have
things
that
are
slowing
down
convergence
of
the
DNS
hierarchy
at
a
rather
high
cost
or
in
some
cases,
extremely
high
cost.
T
Then
we
also
have
because
both
Peter
and
I
work
on
on
the
multi-signer
things
we
we
have
another
case
where
this
is
a
bit
of
a
problem
with
scanning,
because
we
have,
in
the
multi-signer
case
a
need
to
keep
signal,
keep
keys
in
sync
across
multiple
signers
and
if
they
are
not
in
sync,
we
open
up
for
well
for
broken
signage
chain
which
will
cause
problems.
So
that's
another
point
where
scanning
comes
into
play,
and
perhaps
we
really
need
very,
very
frequent
scanning,
which
is
obviously
not
a
good
design.
T
T
Instead,
the
primary
sends
a
notification
to
the
secondary
and
saying
now
is
a
good
time
to
actually
check
for
updates,
because
I
happen
to
know
that
there
have
been
updates,
and
we
all
know
that
we,
we
actually
use
nodeify
for
basically
every
every
shown
on
the
internet
today
and
it
works
fine.
So
then
we
thought
okay.
Do.
We
need
to
actually
update
RFC
1996
for
this
to
make
it
work.
T
I
didn't
know
that
before
I
learned
that
so
we
don't
have
to
update
1996
it's
fine
as
it
is
it's
just
that
today
we
only
use
it
for
notify
with
an
SOA
in
it,
because
we
haven't
found
a
use
case
for
any
other
thing,
but
now
we
do
have
those
use
cases.
So
what
we
are
suggesting
is
notify
CDs
to
inform
the
parent
that
the
child
has
published
a
new
CDs
and
notify
csync
to
inform
the
parent
that
the
child
has
published
a
new
seasick
next
slide.
Please.
T
But
where
should
we
send
them
well
in
the
in?
Because
this
is
sort
of
vertical
notification
rather
than
the
traditional
notify,
which
is
sort
of
Sideways
from
the
primary
to
the
secondary?
We
need
to
figure
out
where
to
send
it,
and
we
obviously
know
where
the
parent
is.
So,
let's
ask
the
parent,
so
our
proposal
is
to
send
the
notification
to
a
destination
announced
by
the
parent
I'm
suggesting
we
started
working
with
this
with
with
other
Alternatives.
T
We
we're
trying
to
fit
this
into
an
SRV
record
Etc,
but
we
couldn't
really
get
a
clean
fit.
So
the
the
current
proposal
is
to
use
a
new
R
type
for
the
history
proposed.
We
call
notify
and
the
notify
RR
type
would
be
the
publication
point
of
where
we
want
to
have
the
notification
sent.
As
you
can
see
in
the
in
the
example
there
we
also
add
a
scheme
parameter.
T
The
reason
why
we
add
a
scheme
parameter
is
because
of
concerns
that
perhaps
there
may
be
other
needs
for
how
to
locate
where
to
send
the
notification,
in
spite
of
us,
only
defining
one
such
mechanism
next
slide.
Please
and
and
then
we
get
to
the
slightly
more
complicated
case,
which
is
what
we
need
for
multisigner.
In
the
multi-signer
case,
we
have
more
than
one
signer
and
when
you
have
more
than
one
signer
that
it
generates
its
own
Keys,
we
need
to
basically
cross
feed
the
keys
between
designers,
the
public
keys.
T
No
need
to
inform
anyone
in
advance
and
that's
sort
of
true,
if
you're,
the
only
designer,
but
it
immediately
breaks
down
if
you're,
not
and
in
the
multi-signer
case.
You're
not
so
we
need
to
have
information
about
Keys
rolling
so
that
we
can
make
sure
that
they
are
immediately
synchronized
across
to
multiple
signers.
So
we
have
a
similar
situation
as
we
have
with
the
CDs
and
the
c-sync
scanning.
We
need
to
track
these
changes
of
the
DNS
key
RSS
in
each
signer
and
that's
costly.
So
we
need
some
sort
of
notification
next
slide.
T
T
So
here
we
have
the
proposal
to
add
a
third
new
type
of
notification,
which
is
to
notify
DNS
key,
and
the
problem
with
the
notified.
Dns
key
is
obviously
that
well,
we
need
it,
but
it
shouldn't
be
sent
to
the
parent,
because
the
parent
basically
doesn't
care
it
should
be
sent
so
that
it's
available
to
other
signers
or
to
the
infrastructure
that
is
keeping
signing
in
sync
in
in
a
multi-signer
context.
Next
slide,
please.
T
T
T
We
have
the
same
format:
the
same
scheme
parameter.
We
only
use.
This
first
scheme
equals
one
here
in
what
we
Define
as
most
simple
mechanism,
but
we
leave
it
open
for
the
future
to
Define
possible
other
mechanisms.
Should
such
mechanisms
become
needed
next
slide,
please
yeah.
So
what
about
the
Triple
R
model?
Well
in
the
Triple
R
model?
T
In
most
cases
there
is
no
issue
I
mean,
for
instance,
many
cctlds
and
and
other
tlds.
They
already
do
this
type
of
scanning
and
they
do
update
the
parent
Zone
based
on
what
they
find
as
they
find
a
CDs
for
instance,
and
then
they
inform
the
registrar
through
Epp
notifications,
somehow
on
the
registrars
keeps
in
track.
Should
that
not
be
possible
in
some
context?
I
don't
know.
But
of
course
that's
that's
theoretically
possible.
We
could
have
some
sort
of
notification
forwarding
either
through
DNS
or
directly
in
app
or
whatever
I.
T
So
what
about
the
security
model?
Well,
I
think
one
of
the
best
things
or
RFC
1996
is
that
it
doesn't
impact
security
because
it
doesn't
say
anything
of
whether
to
trust
the
hint
that
the
notification
is.
It
only
says
it
could
be
a
good
thing
doing
whatever
verifications
we
intend
to
do
regardless
about
now,
so
we
keep
the
security
model
of
whatever
the
scanner
is
doing,
we're
just
telling
the
scanner
do
it
now
rather
than
tomorrow,
and
thereby
we
improve
service
to
the
client
and
we
improve
coherency
in
this
in
the
system.
T
T
This
is
still
DNS
protocol,
but
it's
not
sent
between
name
servers.
It's
sent
to
a
service.
The
recipient
of
these
notifications
is
typically
some
sort
of
scanner
service
or
similar
or
in
the
multi-designer
case.
It's
a
multi-signer
controller
thing.
It's
not
a
name
server,
just
to
point
that
out
next
slide.
Please.
T
And
that's
it.
We
propose
a
bunch
of
new
notifications,
we're
not
changing
the
protocol,
because
RFC
1996
already
allows
this.
We
suggest
that
for
the
location
mechanism
of
how
to
find
where
to
send
the
notifications,
we
add
a
new
RR
type,
there
could
be
other
Alternatives,
but
this
is
our
proposal,
and
that
would
mean
that
would
mean
clearly
a
protocol
change,
while
the
added
types
of
notifications
by
itself
is
not
a
protocol
change,
and
we
would
very
much
like
to
see
this
adopted
questions.
Victor.
G
G
G
N
They
can
add
and
remove
any
cards
any
cause
nodes
dynamically
and
when
any
girls
node
is
added,
it
behaves
as
follows.
So
the
prefix
in
which
the
IP
address
resides
that
serves
the
zones
isn't
announced
yet
from
that
new
location.
But
first
is
the
the
name:
server
loads,
all
the
zones
and
when
it
has
other
zones
loaded,
it
signals
outside
of
the
name
service
software
and
that
triggers
the
the
route
or
the
prefix
announcement
to
be
made
next
slide.
N
N
N
So
what
other
conditions
are
interesting
to
Signal
out
of
the
name,
server
and
what's
associated
action?
Could
I
have
and
what's
published
subscribe
mechanisms
would
suit
that
best,
so
some
conditions
that
we
thought
of
already
is,
of
course
the
first
one
are
all
zones
loaded
already
for
which
you
can
start
bgp
announcements
or
is
a
Zone
perhaps
about
to
expire,
because
then
you
want
to
remove
the
prefix
announcements
same
for
dnf
sex
signatures
if
they
expire.
N
We
could
also
imagine
that
if
the
query
rate
is
exceeding
a
certain
thresholds,
you
would
like
to
or
one
could
want
to
demotify
it
demotivate,
the
reachability
of
the
innercast
node
by
lengthening
the
bgp
parts
or
the
other
way
around
shorten
it.
So
it
will
absorb
a
denial
surface
attack
and
may
also
be
actions
which
are
not
related
to
routing
such
as,
if
a
zone
is
loaded,
updated
trigger
a
external
validator
to
validate
them
next
slide.
Please.
N
Next
slide,
thank
you.
So
there
are
some
existing
signaling
mechanisms
notify,
but
that
stays
within
the
DNS
is
not
fairly
suitable.
For
this
use
case,
sending
queries
to
Extended,
DNS
errors,
monitoring
agents,
that's
very
new,
not
yet
RC
I,
don't
think
it
has
a
lot
of
implementation
yet
because
the
drunk
name
server
that
does
it.
Of
course,
it's
also
more
focused
towards
logging
of
signals
and
yeah
to
be
fair.
Debus
may
not
be
a
bad
option
right.
N
So
so
far,
all
the
actions
that
we
have
inventorized
have
been
local
deepest
has
local
or
local
to
the
system,
security
and
authentication
mechanisms
which
are
standardized
within
the
ITF.
It's
a
very
good
support
on
Linux
and
it's
supported
on
BC
and
it's
easy
to
use
and
for
reference.
I
quoted
python
script,
which
listens
to
debash
and
performs
actions
from
the
not
DNS
repository
next
slide.
Please.
N
So
this
we
discussed
this
in
November
after
the
DNS
org
per
station
of
sidns
any
cost
Network,
and
they
would
like
to
have
a
standardized
shirt.
You
can
use
more
software
in
the
same
fashion
and
I
informed
the
different
open
source,
name,
server,
vendors
and
some
recognize
the
operator
interest
for
this
and
I
also
think
it's
worth
standardizing.
N
Let's
go
artists,
Cassie
almonds
for
IC,
who
has
a
lot
of
exposure
to
operators,
Peter
Van
Dyke
for
power,
DNS
and
Daniel
Saltzman
for
not
DNS,
who
was
the
one
who
came
up
with
the
deepest
idea
for
not
DNS
in
first
place
and
yeah.
By
presenting
this
here,
I
would
like
to
get
feedback
from
you
to
to
get
statements
of
interest.
If
you
are
interested
in
this,
in
particular,
from
ncast
operators
and
also
I,
think
it
will
be
good
for
the
to
complete
the
requirements
to
also
inventorize
more
conditions
and
actions
Associated
actions.