►
From YouTube: IETF109-DNSOP-20201117-0500
Description
DNSOP meeting session at IETF109
2020/11/17 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
Okay
looks
like
we're
at
the
top
of
the
hour
it's
midnight
on
the
us
east
coast,
wherever
you
are
welcome
to
dns
op
at
ietf
109.,
we
are
going
to
do
what
we've
been
become
accustomed
to
doing
with
meat.
Echo
tim
will
be
going
through
the
chair,
slides
what
we've
done
since
the
last
and
then
we
will.
We
have
a
bunch
of
new.
We
have
a
bunch
of
drafts,
progress
on
already
adopted
drafts
and
potential
new
work
for
the
working
group.
So
let's
go
ahead
and
get
started.
B
C
Good
evening,
so
let's
go
to
the
next
slide
and
welcome
to
dean.
Asap
benno
is
not
here
today,
benno
is
down
sick,
so
he
is.
He
has
managed
to
sort
of
catch
the
the
covid,
so
so
we
hope
he
gets
better
soon,
so
he
he
contacted
us
the
other
day
and
said
he
wasn't
going
to
be
able
to
make
it
so
it'll
be
suzanne,
and
I
so.
C
You
know
following
all
the
iatf
processes
and
guidelines
and
stuff
and
all
the
nice
things
for
that,
and
if
we
go
to
the
next
slide,
you
can
sort
of
slide
through
these.
Our
agenda
is
pretty
straightforward.
We've
got
some
updates
on
the
old
work.
We've
got
some
that
going
on
now,
some
current
business
and
some
new
business
and
we
did
a
little
bad
math.
So
we're
going
to
run
through
the
chair
stuff
pretty
quickly,
but
you
all
should
you
know,
can
read
the
slides
as
well.
So
as
we
go
through
the
document
updates.
C
Next,
since
our
last
meeting,
we've
had
four
things
become
rfcs,
which
is
pretty
great,
no
response,
multi-provider
dnsec,
extended
error
and
2845
biz,
which
actually
is
in
auth
48.
I
realized
the
last
minute,
but
I
believe
that
should
be
all
sort
of
taken.
Care
of
the
authors
are
sort
of
finishing
up
the
final
edits
there,
so
I
may
have
jumped
the
gun
on
that
one.
But
that's
that's
been
pretty
great,
so
congrats
on.
C
Yep,
let's
go
to
the
next
slide.
We
have
two
more
things
in
the
isgq
zone:
digest
and
server
cookies
server
cookies
just
went
through
working
group
last
call,
and
one
of
them
were
rating.
The
write-up,
which
actually
passed
working
group
last
call
and
benno,
was
working
on
the
write-up,
but
that'll
probably
be
delayed
another
a
little
bit
as
he
sort
of
gets
better
on
the
on
the
yang
stuff.
So
we
still
have
some
more
stuff
moving
forward.
So
as
we
go
to
the
next
slide
in
working
group,
last
call
7816
biz.
C
Actually
I
believe
this
should
this
probably
have
finished
passing.
I
just
need
to
send
out
an
email
to
sort
of
say
that
I
know
there's
some
updates
to
the
documents.
Mr
hoffman
has
a
oh
shoot.
I
actually
removed
you
from
the
cue
paul.
So
can
you
do
that
again?
I'd
like
you
to
sort
of
speak
yeah?
How
can
I
and
why
can't
I
let
you
speak.
Please
go
ahead.
G
The
authors
of
7816
bisque,
we
are
looking
at
the.
We
got
a
bunch
of
good
comments.
The
editorial
ones
are
already
in
our
internal
repo,
but
there
are
actually
some
technical
changes
that
people
asked
for.
So
we
haven't
done
a
new
draft
and
we
also
haven't
discussed
once
we
do
a
new
draft
if
we're
going
to
want
a
second
working
group.
G
B
C
C
C
The
delegation
only
is
interesting,
the
the
fragmentation
draft.
I
think
some
of
these
are
getting
really
close
to
getting
working
group
last
call,
and
so
I
believe
what
we'll
do
is
the
chairs
will
probably
start
focusing
on
some
of
these
to
start
moving
along
and
there's
a
couple
of
small
ones
like
the
glue
is
on
optional,
that
as
well
like
mark's
draft,
that's
pretty
straightforward
that
I
think
that's
been
adopted
that
we
should
probably
also
sort
of
pack
up
and
move
along.
So
that's!
C
I
don't
want
to
let
too
many
things
sort
of
sit,
but
we
do
have
a
lot
of
stuff
going
on
all
right
next
slide.
I
think
what
we've
got
here
is
the
agenda.
So
schumann's
gonna
talk
about
ns,
revalidation,
dimitri
is
gonna.
Give
his
5933
biz
update,
there's
roy's
going
to
talk
about
the
private
use
tld.
C
Mr
fujiwara-san
is
going
to
talk
about
avoid
fragmentation
and
then
on
the
next
slide,
some
of
the
new
business,
which
is
paul's
iana
consideration,
draft,
which
kind
of
ties
into
the
5933
biz.
It's
sort
of
a
you
know,
discussion
on
changing
the
registry-
and
I
know
we
talked
about
this
before
and
there
is
some
strong
pro
and
con
sort
of
thing
and
my
news
got
ip
range
location
and
ray's
got
the
dynastop
error
page
draft.
C
C
B
I
I
I
I've
provided
a
link
to
the
slides
here.
It
was
subsequently
adopted
by
the
working
group
in
june
and
there's
a
link
to
the
current
version
of
the
draft
and,
briefly,
to
remind
folks,
the
two
main
recommendations
are.
The
first
is
upgrading
nsrs
credibility.
That
means
resolvers
should
deterministically
obtain
the
child
an
asset
and
place
it
preferentially
in
their
cache,
and
the
second
part
is
that
they
should
also
revalidate
the
delegation
at
most
at
the
expiration
of
the
ttl
of
the
parent
side
nsrr
set.
I
We
pushed
out
a
new
revision
of
the
draft,
I
think
a
few
weeks
ago
and
I'll
summarize
the
main
update.
So
I
think
all
of
these
updates
have
been
discussed
on
the
list
or
at
a
previous
itf
meeting,
so
there
shouldn't
be
anything
really
surprising
in
there.
So
of
course
we
renamed
the
document
as
a
working
group
doc.
It's
currently
at
revision00.
I
I
We
split
that
out
into
its
own
section,
where
we
mentioned
that,
although
by
spec
so
specifically
rfc
4035,
section
2.4
the
ds
and
the
delegating
nsttl
are
supposed
to
match
in
practice,
they
often
don't
and
typically
don't
so
one
possible
proposal
is
that
resolvers
should
use
the
dsttl,
which
is
of
course
signed
as
the
revalidation
interval
itself.
So
I
think
folks
made
this
recommendation
in
the
past,
but
I'm
not
sure
we
had
consensus
on
it.
So
this
probably
needs
some
more
discussion
right
now
in
the
document
we
say:
resolvers
may
that's,
uppercase
may
do
it.
I
So
the
question
is:
should
that
be
promoted
to
should
or
should
something
else
be
said
or
done
here?
So
that's
one
of
the
questions
that
we
have
and
then,
if
the
entire
ns
set
is
assessed
to
be
lame,
then
the
resolver
should
perform
revalidation
of
the
parent,
but
with
a
hold
down
timer,
to
avoid
inadvertently
spinning
and
inflicting
a
denial
of
service
loop
at
the
parent
zone.
So
we
don't
yet
specify
a
value
for
the
hold
down
and
we
probably
should
recommend
something
here.
I
I
Ns
query
for
those
that
that
don't
and
secondly,
authoritative
servers
that
are
performing
minimal
responses
could
also
help
out
a
bit
by
selectively
adding
the
authoritative
ns
set
in
their
responses
only
for
the
dns
key
queries,
so
they're
minimizing
every
other
response,
except
for
the
dns
key
query,
and
this
might
allow
resolvers
to
cache
that
information
and
similarly
forego
the
additional
child.
Ns
query
for
subsequent
interactions
with
that
zone.
I
So
these
are
currently
just
mentioned
as
possibilities,
without
any
strong
recommendations
either
way.
So
that's
another
open
question
about
how
strongly
or
not
we
want
to
recommend
the
resolvers.
Do
these
things
and,
lastly,
there's
a
new
section
on
on
delegation
changes,
so
things
like
removal
of
delegations
and
redelegations
of
the
zone
to
new
name
servers.
J
I
K
So
I
still
feel
very
strongly
about
this,
and
I
still
don't
think
that
we
should
do
this
work.
As
I
said
by
the
when
we
had
the
call
for
adoption,
it
is
wandering
way
too
far
into
implementation
territory
and
it
forces
away
how
certain
people
think
how
the
resolution
process
works
to
be
kind
of
implemented
by
all
resolvers.
K
There
are
other
ways
to
do
resolution
and
there's
other
ways
to
handle
delegation.
It
also
makes
some
assumption
that
sort
of
the
cash
that
you
have
for
records
and
for
delegations
the
same.
That's
not
always
the
case
and
everything
that
we
do,
that
causes
outbound
curies
on
a
resolver
will
be
abused,
and
this
is
one
thing
that
certainly
will
be
abused.
So
it
is
a
I
mean.
The
the
minimized
question
also
is
something
that
really,
even
if
other
resolvers
would
be
authoritive
would
send
the
stuff
back.
K
It
depends
on
the
result.
If
he
takes
it
or
not,
so
I
think
we're
having
some
bad
assumptions
or
we
are
trying
to
implement
something
that
might
help
one
or
two
use
cases,
but
that
overall
will
kind
of
make
the
way
how
resolvers
over
the
internet
behave
more
consistent
and
more
abusable.
So
I'm
sort
of
very
much
still
opposed
at.
I
I
I
L
L
G
Think
do
as
the
note
taker
I
would
appreciate.
If
people
like
either
you
tim
would
give
full
names
or
people
would
use
their
names.
I
recognize
many
people
by
their
voices,
but
not
everybody.
What,
if
not
everyone's
using
their
their
camera,
so
do
the
equivalent
of
flashing.
Your
name
badge
to
me
by
at
least
focally
saying
who
you
are.
Thank
you.
C
C
B
C
M
M
M
M
M
N
M
N
O
A
C
C
C
F
M
M
P
G
G
And
this
draft
and
the
rfc
that
describes
the
actual
signing
algorithm
if
it's
implementable,
I
I
sort
of
assume
it
is
that
you
know
somebody
who's,
not
dimitri
probably
could
do
it,
but
it
would
be
interesting
to
hear
from
other
people,
although
that's
not
really
a
requirement
but
seriously.
The
only
thing
I
have
on
this
is
whether
this
would
be
for
standards
track
or
not,
and
I
would
say
we
should
wait
before
working
group
last
call
to
determine
that
thanks.
B
S
Good
good
morning,
everybody
hope
I'm
clear
first
first
off
thanks
for
thanks
to
the
adidas
up
working
group
chairs
for
number
one
adoption
number
two
for
allowing
me
to
talk
a
little
bit
about
this.
So
I'll
first
talk
about
what
happened
since
it
got
adopted
and
next
slide.
Please,
or
can
I
do
that
myself.
S
S
S
Now
keep
in
mind,
this
was
the
draft
that
was
adopted
at
the
time,
so
we
had
lots
of
discussions
on
the
list
and
they're
basically
the
way
I
see
it
and
I'm
sure
that
people
line
up
with
my
mic
to
remind
me
of
yet
other
things
and
two
main
points
of
contention.
One
is
private.
Namespace
is
basically
a
bad
idea.
If
you
want
to
have
something
like
that,
use
a
registered
name
instead
and
the
other
thing
is
namespace
policies
are
not
ours
to
make
and
that
lies
elsewhere.
S
S
I've
realized
that
this
is
a
big
kind
of
worms
and
also
if
we
need
a
document
that
talks
about
the
private
namespace
problem
space,
the
concepts,
the
purpose,
the
facilities,
the
setup,
the
need,
etc,
or
even
the
best
current
practice
around,
and
I'm
calling
these
independent
names
to
avoid
private
namespace
just
for
a
second
that's,
actually
a
different
document
than
this
is
what
I
said
to
the
list.
The
other
day
is
maybe
we
need
two
documents,
one
document
that
talks
about
private
names
and
another
document
that
that
proposed
what
a
private
namespace
could
be.
S
So
that's
that's!
That's
one
proposal
to
the
to
the
working
group
and
the
other
proposal
to
the
working
group
is
to
change
the
tone
slightly
in
the
document
is
to
observe
and
recognize
that
these
iso
3166-1
alpha
2
user-assigned
code
elements
are
used
as
intended
right
by
many
different
organizations
in
many
different
ways,
and
the
intention
from
the
iso
has
always
been
locally
defined
and
locally
meaningful
to
those
organizations
that
use
them.
S
S
There
we
go,
and
with
that
in
mind,
I'd
like
to-
and
this
is
actually
a
proposal
from
joe
and
then
it's
not
the
worst
one-
I've
heard
from
him,
so
this
is
this-
is
this
is
a
proposal
from
joe.
This
is
follow
the
spirit
of
basically
obsoleting
a
code
element
in
an
iana
registry.
I
I
realized
that
this
is
slightly
different
than
actually
obsoleting
your
code
element,
because
we
are
talking
about
main
spaces
here,
but,
for
instance,
if
you
look
at
our
type
254
32769,
opcode1
and
edns
option,
4,
etc,
etc.
S
Those
are
code
elements
that
have
been
retired.
I
want
to
avoid
the
use
of
the
term
retired,
because
retiring
a
topic
of
domain
has
a
different
connotation,
for
instance
in
the
ccnso
working
group.
Sorry
in
the
ccnso
icann
workspace.
So
that's
why
I
named
it
obsoleting-
and
I
think
that's
the
correct
term
to
use
here.
S
Well
that
implies
actually
the
spirit
of
obsoleting
that
these
code
elements
cannot
be
considered
as
potential
top-level
domains
in
the
root
zone,
and
I
know
I'm
stepping
on
policy
toes
here,
and
this
is
not
actually.
I
think
this
is
not
an
explicit
policy
that
we
can
make
unless
we
use
something
like
rc
6761,
but
it
does
follow
the
iso's
intent
and
the
policy
that
was
is
one
of
the
founding
documents
of
the
way
I
see
it.
S
I
can
rc
51
sorry
iona
5191
for
1591.,
so
with
these,
let's
call
them
baby
steps
going
forward
on
them
on
the
tone
of
the
draft
I
would
like
to.
I
would
like
to
hand
the
microphone
back
to
suzanne
and
if,
if,
if
people
want
to
ask
questions,
I'm
I'm
I'm
here
for
it.
Joe
is
here
as
well,
and
dr
edward
liz
is
here
as
well
thanks.
Everyone.
T
Cody
thanks
very
much
for
laying
out
the
draft
roy.
I
had
a
chance
to
read
it
a
couple
of
weeks
ago
and-
and
I
confess
that
some
of
what
you've
put
forward
in
today's
meeting
kind
of
echoes
some
of
the
things
I
was
thinking
about
it.
In
particular
you
you
mentioned
a
possibility
of
splitting
the
draft
into
two
things,
one
of
which
talked
about
private
use
names
and
had
that
whole
can
of
worm,
and
one
of
which
talked
about
this
particular
set
of
names.
T
And
I
I
like
that
idea
for
two
reasons:
one.
I
think
it
is
absolutely
required
to
get
a
good
use
of
what
that
sort
of
locally
significant
means
when
we're
talking
about
the
dns
and
and
not
in
terms
of
the
other
ways
in
which
iso
may
have
meant
that
when
setting
these
aside-
and
the
second
is,
I
kind
of
feel
like
we're
that
that
document-
that's
talking
about
these
specific
names-
should
actually
be
an
iso
document
talking
to
icann,
not
an
itf
document,
and
I
think
it
would
be
valuable.
But
I
don't
think
it.
T
C
O
How
this
works
you're
good,
very
good.
Well,
so
the
idea
with
this
was
I
I
get
the
point
that
this
is
a
potentially
a
very
policy
minefield
that
we're
wandering
into
in
this
document,
and
so
first
of
all,
the
study
in
the
documents
was
really
identifying.
There's
two
orthogonal
cans
of
worms.
Here,
let's
have
separate
cans
because
they're
different
kinds
of
worms-
and
I
I
I
do
think-
that's
a
good
idea-
and
it's
good
to
hear
support
for
that,
the
the
the
can
that
contains
the
two
leather
codes.
O
The
idea
really
was
to
try
and
limit
the
scope
of
the
discussion
in
the
itf
to
just
the
things
that
the
ietf
had
something
to
say
about
which
we
thought
was
just
the
fact.
We
have
code
points.
We
have
the
dns.
We
have
elements
of
all
of
this
that
are
very
much
itf
territory,
and
we
have
an
observation
that
these
things
have
been
used
before
and
that
we
can
effectively
expect
name
collisions
if
these
things
were
to
appear
actually
in
the
root
zone,
because
we
know
they're
being
used
for
other
purposes.
O
So
the
idea
of
all
of
this
was
really
to
limit
the
scope
to
just
the
stuff
that
the
ietf
has
something
to
say
about,
and
not
anything
else
and
in
particular
by
basing
it
on
an
observation
of
what's
happened,
based
on
historic
3166
policy
and
historic
operational
behavior.
That's
based
on
that,
we
don't
actually
need
to
link
in
the
future.
All
we
need
to
do
is
make
the
observation.
This
has
happened
in
the
past
and
because
it's
happened
in
the
past.
This
constrains
our
users.
S
S
S
I
I
can
has
basically
followed
rc
1591
on
this
adopting
the
iso's
policy.
Now
that
doesn't
explicitly
mean
that
these
strings
can
be
used,
but
I
think,
if
you
look
at
this
as
a
venn
diagram,
there
needs
to
be
an
overlap
between.
I
can
itf
and
iso,
where
all
three
explicitly
say
that,
yes,
these
can
be
used
for
something
local
and-
and
I
think
the
iso
has
done
that
the
icann
is
busy
with
it.
They
also
need
to
answer
to
assec
113.
S
So
can
I
respond
to
that
really
quick?
I
I
completely
agree,
but
there
are
some
folks
and
I
don't
disagree
with
them.
There
are
some
folks.
That
said,
that's
that's
all
good
that
all
these
organizations
have
these
good
intentions,
but
let's
make
it
explicit
because
we
don't
know
what
these
organizations
will
do
in
the
future,
and
so
and
so
there
are
folks
that
agree
with
you,
and
there
are
folks
that
want
a
little
bit
more
than
just
agree
with
you.
They
want
something
explicit.
U
Thank
you
warren
tomorrow,
so
both
roy
and
joe
mentioned
policy
invitations,
and
I
think
roy
also
mentioned
slack
on
13.,
just
know.
Euron
the
ceo
of
icann
sent
over
a
liaison
statement
a
while
ago.
I
will
paste
the
link
to
it,
largely
saying
you
know
we
have
this
document
from
from
ikansak,
saying
that
you
know
possibly
recommending
that
a
name
should
be
reserved
and
then
a
response
from
the
ietf
or
actually
sorry
from
the
iab
and
iesg
largely
saying.
Yes,
we
agree
with
what
you
said.
U
I'll
actually
put
the
whole
text
and
it
makes
much
more
sense,
but
the
important
thing
at
the
bottom
is.
We
think
it
would
be
useful
to
engage
ietf
and
icann
experts
in
a
dialogue
on
this
topic
and
we'll
follow
up
to
try
and
get
that
arranged,
and
that's
mainly
referring
to
the
special
use,
names,
problem
statement
and
the
sort
of
lack
of
clarity
that
we
all
know
exists
in
6761
and
sort
of
who
does
which
bits
etc.
U
C
B
B
T
T
I
think,
as
before
the
the
right
thing
to
do
is
to
take
up.
You
know
what
what
does
it
mean
to
have
this,
this
style
of
name
in
one
document,
so
split
that
that
out
and
then
the
other
one
to
go
back
to
what
roy
was
saying
to
say
these
are
being
squatted
on
and
to
say
flat
out,
not
that
we
recommend
you
do
that,
not
that
we
think
it
ought
to
happen,
but
that
we
observe
in
the
wild
that
this
is
happening.
T
And
if
you
say
that
I
think
it's
uncontroversial,
you
probably
have
data
to
back
it
up
and
with
that
you're
not
making
a
recommendation
that
they
be
treated
according
to
any
particular
future
use.
You
go
back
to
what
roy
was
saying.
This
is
what
we've
seen
in
in
in
the
wild,
and
I
think
that
allows
you
to
to
go
after
you've
developed
the
the
document.
You
split
out
back
into
that
policy
process
and
say
hey
now.
P
Yes,
yes,
okay,
this
is
my
first
iits
meeting,
so
be
a
bear
with
me,
I'm
an
actual
newbie.
In
these
things
I
have
been
vice
chairing
the
retirement
policy
development
group
at
ccnso.
What
would
happen
if
a
country
ceases
to
exist
or
something
or
splits
apart?
That
has
led
me
to
do
really
detailed
study
of
the
iso
standard,
which
has
recently
been
been
written
in
the
beginning
of
this
process
of
this
particular
document.
P
I
was
a
bit
concerned,
but
I've
changed
my
mind
because
and
and
it
is
very
helpful
what
has
been
said
to
from
by
several
participants-
to
split
this
into
two-
the
iso,
which
is
the
un
type
organization
that
meets
occasionally-
and
it's
not
really
that
predictable
has
been
predictable
in
that
it
says
there
are
a
certain
number
of
code
elements
to
character,
code
elements
that
are
not
part
of
the
standard.
They're
not
reserved
they're,
not
part
of
the
standard,
the
and
then
there
is
a
list
of
32
or
something.
P
So
my
view
is
that
it
will
never
happen
that
they
do
away
with
all
of
them
and
it
is
extremely
unlikely.
It's
much
less
likely
than
a
plane
flies
on
the
hou
lands
in
the
house
that
I'm
living
in
at
the
moment
that
any
one
of
the
ones
that
are
currently
there
are
being
changed.
I
don't
don't
see
this
ever
happening.
P
O
V
V
The
comment
was
along
the
lines
that
there
are
certain
codes,
that
iso
said
they
won't
use,
and
icann
says
they
won't
use
and
the
idf
should
say
that
we
won't
define
anything
about
that
either
and
they're
free
for
local
use
and
the
problem
with
that
is
whenever
you
say
something
is
reserved,
inevitably
a
whole
bunch
of
people,
leap
forward
and
think
that
means
it's
reserved
for
them.
I've
even
thought
about
writing
a
draft
with
the
title.
This
field
is
reserved,
but
not
for
you.
V
C
F
Is
this
working
for
me
now?
Yes,
it
is
excellent!
Sorry
guys
it's
far
too
early
in
the
morning.
For
me,
my
comment
relates
to
the
text.
In
section
four
of
the
document
roy's
got
a
comprehensive,
fairly
comprehensive
list
of
all
the
different
organizations
and
agencies
that
are
doing
things
with
these
special
purpose.
Iso
3166
codes.
F
I
think
this
material
is
inappropriate
for
an
rsc,
because
it's
not
up
to
the
itf
to
document
what
the
international
salvation
organization
or
the
world
bank
chooses
to
do.
I
think
that's
completely
inappropriate
and,
of
course,
those
organizations,
behavior
and
policies
could
change
so
maybe
they're
using.xml
today,
but
maybe
they'll
change
the
use
dot
xu
tomorrow.
So
I
don't
think
this
material
is
relevant
to
analysis,
useful
background
information,
but
I
don't
think
it's
at
all
appropriate
to
go
into
an
rsc
thanks.
S
F
C
U
If
iso
were
ever
to
try
and
say
you
know,
dot
zed
is
now
going
to
be
reassigned
for
zanzibar,
unlike
with
many
other
users,
if
we
started
using
it
in
the
dns,
that
really
makes
it
very
hard
for
the
because
of
these
sort
of
uncoordinated
use
of
this.
It
makes
it
really
hard
to
take
it
out
of
that.
Once
people
start
using
got7
for
whatever
internal
use,
you
can't
figure
out
where
it
is,
you
can't
remove
it.
Basically,
the
name
collisions
problem.
U
If
we
had
something
from
iso
saying
no
seriously
these
ones
that
we're
saying
you
can
use
internally
for
private
type
stuff,
you
can
use
them
no
worries.
We
will
never
never
reassign
them
for
anything
else.
Then
I
think
this
is
a
grand
idea.
My
concern
constantly
what
happens
when
iso
tries
to
use
it
and
then
the
ietf
has
to
say.
Oh
sorry,
we
trusted
your
earlier
document,
and
now
you
kinda
can't
do
that.
W
W
W
Section
3.2
recommendations
for
udp,
responders
udp
responders
should
send
dnc
responses
with
ip,
don't
log
ip16
clock
options,
udp
responders
main
probe
to
discover
the
real
empty
value
for
destination.
Gtps
1.6
gdp
responses
that
result
in
id
packets
that
do
not
exceed
the
percent.
Due
to
the
distance
to
the
requester,
of
course,
as
in
the
conventional
case,
a
special
aspect,
a
specified
barrier,
for
example,
1220
or
1232,
as
the
dns
pakistani
limit
may
be
used
and
in
section
3.2
recommendations
for
udp
requesters.
W
Usb
requesters
should
send
dns
responses
with
ip,
don't
collect,
ipv6
control
options.
Udp
requesters
should
use
the
requestors
payroll
sites
to
limit
the
percent
fuel
value.
Minus
the
ip
header
lengths
and
udp
header
lengths
and
limited
resistors
may
drop
fragmented,
dncd
responses
without
ipd
assembly.
To
avoid
just
pointed
attacks
extract.
W
I'd
like
to
add
text
to
about
package
trust
at
udp
response,
responder,
I'd
like
to
add
text.
If
the.
If
the
udp
responder
detects
immediate
error
that
the
udp
packet
cannot
be
sent
beyond
the
possibility
size,
e-message
sites,
the
udp
responder
may
create
responses
response,
packets
hitting
possibility,
size
or
tcp
set
and
I'd
like
to
change
priority.
W
First
ip,
don't
worry
second
avoid
packet
draw.
Then
I
would
like
to
add
existing
interrupt
introduction.
This
document
proposes
to
set
ip
don't
drop
ip160
in
dns
udp
responses
in
order
to
avoid
active
fragmentation
and
describes
how
to
avoid
bucket
losses
due
to
ip
don't
drive.
I
even
just
don't
clap
and
I'd
like
to
change
order.
B
B
X
You
one
has
a
different
there's,
a
different
need
in
terms
of
whether
you
allow
fragmentation
to
occur
or
not.
When
you're
sending
a
tcg
reply,
the
tcg
replies
you
can
fragment
as
much
as
you
want
and
there's
no
reassembly
attack
that
can
successfully
deliver
the
dns
packet
dnsudb
packet,
which
we
misinterpreted.
X
I
do
have
enough
do
have
the
well-known
graph
which
we
also
as
a
way
of
making
as
as
a
way
of
extending
dns
without
without,
but
I
haven't,
require
requiring
dns
sec
to
prevent
path
attacks,
including
off
path.
Reassembly
attacks
succeeding,
so
this
needs
issue.
This
document
should
a
very
minimum
take
into
consideration.
X
X
X
X
K
Yes,
so
t-seg
curies
are
only
a
smart,
small
part
of
sort
of
the
old
overall
dns
traffic,
and
I
don't
think
that
we'll
see
more
adoption,
but
the
other
main
problem
is
that
fragmentation
within
ipv6
is
from
what
I've
heard
just
not
working
so
rather
than
to
kind
of
make
one
additional
kind
of
special
use
case
yeah.
We
can
do
fragmentation
with
t6
over
v4,
but
we
can't
do
it
over
six.
I
think
what
fujiwara
proposes
much
better,
I
mean
have
a
clear
guidance.
X
X
X
X
X
X
C
N
Well,
this
is
peter
van
dyke
at
powerdinos
over
the
last
two
years.
Several,
but
not
all
dns
vendors
have
come
together
to
somewhat
solve
fragmentation
problem
as
well,
by
agreeing
on
a
default
buff
size
in
a
configuration
of
1232
bytes.
This
document
plainly
states
that
that
was
wrong.
I
think
that
that
is
divisive,
and
I
do
not
think
that
that
text
belongs
in
an
rfc.
B
C
I
R
G
G
Other
ietf
working
groups
have
all
of
their
algorithms
done
either
by
expert
review
or
just
rfc
required.
So
an
informational
rfc
is
okay.
And
if
you
look
in
in
this
document,
you
will
see
that
that
we
just
forgot
with
ds
and
nsec3
records.
You
know
we
actually
made
everything
else
for
dns
sec,
the
rfc
required,
but
we
we
didn't,
do
it
for
ds
records,
because
we
weren't
updating
that
next
slide.
G
Like
I
said
earlier,
you
know
we
we
actually,
we,
the
working
group,
actually
looked
at
this
in
2010
with
rfc
6014,
and
we
made
all
of
the
dnsec
registries
rfc
required,
meaning
it
could
be
an
informational
rfc.
It
doesn't
have
to
come
through
the
working
group
and
we
forgot
ds
records
and
then
sec3.
G
G
So
to
backtrack,
there
are
three
things
that
we
could
choose,
which
working
group
different
working
groups
choose
for
algorithm
assignment.
We
can
have
standard
requirement,
which
is
what
we
currently
have
for
ds
records,
which
also
must
have
a
full
ietf
review,
which
of
course
takes
a
lot
longer
and
anytime.
Anyone
wants
one
of
these
for
a
dns
sec,
ds
record.
It's
going
to
probably
have
to
come
to
dns
off.
G
Although
the
isg
gets
to
preview
it,
those
still
can
come
through
dns
ops.
So,
if
someone
is
is
saying,
I
want
an
rfc
and
it
comes
to
dns
off.
That's
fine.
It's
just
rc
required
doesn't
have
to
come
through
dns
off
and
go
through
the
ietf.
It
can
go
through
the
ise
or
just
specification
required,
which
is
any
external
document.
G
It
could
be
a
particular
version
of
internet
draft.
It
can
be
an
rfc,
so
rfcs,
you
know,
are
there
with
specification
required
for
like
ds
records?
It's
not
like
that
anyone
can
get
whatever
they
want.
It
will
definitely
have
an
expert
review,
so
it's
not
like
we're
giving
them
out
like
candy
and
as
we've
seen
for
many
of
the
other
things
in
the
dns
op
has
done.
Expert
review
is
completely
sufficient
for
fixing
things
that
people
want
and
yet
still
getting
them.
G
So,
just
to
be
clear
ex
if
we
said
expert
review,
not
even
rfc
required,
but
just
expert
review,
the
experts
actually
are
assigned
by
the
isg.
So
it's
not
just
that
someone
says
I'm
an
expert.
Someone
has
to
agree
that
they're,
an
expert
and
the
isg
can
replace
experts.
So
if
an
expert
sort
of
goes
rogue
they're
going
too
slowly
they're
going
they're
being
too
conservative
they're
being
too
liberal,
I
dropped
an
o
there.
The
isg
can
replace
them
and
does
replace
them
at
times.
G
So
you
know
it's
not
going
to
be
like
that.
We're
going
to
have
an
inherently
polluted
registry.
If
we
just
go
with
expert
review
so
and
and
anytime,
an
expert
makes
a
decision,
especially
against
the
code
point
request.
Decisions
can
be
appealed
to
the
isg.
They
are
often
the
isg.
Sometimes
over
overturns
experts
often
doesn't
so
really
what
what
we
in
dns
op
need
to
decide
is.
G
Thanks
so
here
are
the
possible
next
steps.
One
is
do
nothing
that
is
don't
adopt
this
draft,
at
which
point
then
the
the
gost
signing
still
has
to
be
a
standard,
which
means
it
would
have
to
go
through
working
group
last
call
and
then
followed
by
ietf
last
call
it
might
have
to
come
back
to
the
working
group.
G
There
are
questions
such
like
that,
and
if
we
do
nothing,
then
in
a
few
years,
when
we
get
all
of
the
post
quantum
signature,
algorithms,
then
we're
gonna
have
to
you
know
all
of
them
will
have
to
come
through
the
working
group
we
can
adopt
this.
You
know
this
draft
and
choose
rfc
required,
which
is
what
is
in
the
current
draft
so
with.
G
But
basically,
if
you
look
at
the
national
crypto
for
asian
countries
for
other
other
things
for
goss
they're,
all
just
informational
and
I
think
they
should
be-
or
we
can
adopt
this
document
and
then
choose
specification
required
again
at
which
point
dimitri
could
move
his
document
through
through
here
as
an
informational
rfc.
He
can
take
it
out
of
the
working
group
whatever
I.
C
Steps
thanks
paul,
I
remember
the
the
last
time
you
brought
this
up.
We
had
some
issues
raised
by
some
of
the
implementers
about
you
know.
How
do
we
give
guidance
on
to
the
implementers
and
stuff
and-
and
that's
where
I
kind
of
like
to
hear
if
any
of
the
implementers
like
to
speak
up
and
sort
of
say
their
piece,
they
they
they
were
the
ones
that
had
you
know
good
arguments
like
how
do
we
sort
of
give
guidance?
G
Well,
we've
already
done
that
we
already
have
the
should
you
know
the
the
should
be
implemented,
not
implemented.
We
already
passed
that,
and
so
this
would
tie
right
into
that
yeah.
But
but
again
I
I
certainly
yeah.
I
am
not
an
implementer
and
I
don't
have
to
deal
with
this
and
I
don't
have
to
deal
with.
You
know
the
the
stuff
that's
coming
down
the
line
with
post-quantum
either,
which
will
be
probably
a
lot
more
painful.
Q
Z
K
X
X
O
F
My
preference
would
be
use
an
expert
review,
but
of
course
we
need
some
kind
of
document
to
specify
the
standard,
and
that
needs
to
be
documented
for
a
new
crypto
algorithm.
But
I
think
something
lightweight
pragmatic
is
the
way
forward
here
requiring
an
rfc
for
every
single
crypto
algorithm
that
might
be
possibly
used
for
dns.
Sec
seems
overkill
to.
G
But-
and
I
will
say
this
having
been
s
mine
working
group
chair,
we
actually
did
have
one
of
ours
disappear,
but,
as
someone
noted,
no
one
gave
up
whatever
about
it
anyway,
so
it
was.
It
really
just
made
it
easier
for
implementers
to
say
I
didn't
want
to
implement
that
the
first
time
and
rip
it
out
you
know
so
mark
is
correct
that
they
can
disappear,
but
basically
nothing
important
ever
has.
F
G
So,
yes,
that's
true
tim,
but
then
we
would
have
to
have
the
discussion
of
whether
this
working
group
actually
wants
to
standardize
a
new
signature
algorithm
that
is
less
secure
than
the
last
one
that
we
we
standardized.
That's
true.
That
is
that
that
you
know
the
goss
stuff
has
the
same
security
properties
as
p256,
which
is
worse
than
eddsa.
G
Y
Thank
you.
I
had
to
log
out
and
back
in
again
so
the
thing
I
would
like
to
to
bring
forward
here.
That's
I.
I
see
a
distinction
between
two
types
of
records.
One
is
that
requires
special
processing
in
the
servers.
I
would
call
them
structure
carrying
records.
These
will
be
like
ns
records
and
and
dns
related
records,
and
then
you
have
the
data
carrying
records,
which
are
the
things
that
applications
actually
look
for.
Address
records,
srv
records
and
what
have
you
and
I
think
we
might
want
to
make
a
distinction
between
the
two.
Y
M
G
G
L
Specification
and
specifications
disappearing
if,
if
something
gets
approved
by
an
expert
review,
maybe
do
an
informational
after
the
fact
and
maybe
not
do
them
individually,
but
maybe
lump
them
together,
maybe
once
every
other
ietf
or
something
like
that
very
lightweight,
but
at
least
that
as
a
as
a
informational
rfc.
Just
a.
L
U
G
B
AA
AA
AA
AA
On
the
ip
ranges
front,
readers
are
often
a
subset
of
a
global
organization,
iep
pool,
and
people
maybe
may
want
to
use
actually
these
subsets
these
ip
ranges
as
a
source
to
build
network
caches
or
to
build
ddos
mitigation,
as
was
mentioned
by
the
net
lab
recently
in
there
in
the
hdp
post.
You
know
talking
to
dns
operators
at
conferences.
People
are
using
response
rate
limiting
it
works
well
for
them,
but
they
would
like
to
be
able
to
exclude
some
resources
that
comes
from.
AA
So
goal
and
on
goals,
the
goal
here
is
mostly
to
provide
a
mechanism
to
to
have
resolvers
operator
to
share
the
ip
ranges
in
geolocation
and
the
mechanism
on
the
other
side
for
earth
operators
or
network
policies
makers
to
to
be
able
to
get
that
that
data
and
to
be
able
to
consume
it
in
a
progressive
programmatic
way.
One
of
the
non-goal
is
to
be
a
real-time
database
that
is
accessed
directly
from
from,
let's
say,
authoritative,
server.
AA
So
the
current
status,
as
far
as
I
could
get
it
is
a
bit
all
over
the
place.
There
is
no
consistency
in
the
location
where
people
that
share
this
information
will
put
it.
It
may
be
a
faq,
it
may
be
some
api
documentation.
There
is
no
no
consistency
either
in
the
medium
use,
sometimes
over
http.
Sometimes
it's
over
dns,
sometimes
it's
over
private
email,
and
there
is
neither
consistency
in
the
format.
It
goes
from
a
standard
html
web
page
to
csv
or
json
next
slide.
AA
Please
so
here
the
proposal
will
be
to
define
a
publication
format
that
can
be
used
globally.
So
people
don't
have
to
reinvent
the
wheel.
They
don't
have
to
think
about
how
they
could
prevent
that
pre
present
that
information
and
the
consumers
don't
have
to
think
hard
about
how
they
can
easily
consume
that
data.
AA
Some
potential
contenders,
the
good
old
txt
record
that
will
be
a
space
separated
list
of
subnets
or
a
space
separator
list
of
tuples
that
contains
subnet
and
the
two-letter
country
code,
or
it
could
be
a
https
record
that
returns
a
rac8805
geofeed.
I
think,
essentially,
there
is
two
parts
here.
One
is
how
to
format
it,
the
the
presentation
of
the
data
and
the
other
part,
is
how
to
find
that
information.
AA
On
the
discovery
side.
This
is
maybe
the
the
hardest
part.
One
idea
was
to
essentially
use
a
reserved,
underscore
name
that
people
could
request,
say
underscore
rgns.organization.com
and
I
will
return
either.
They
will
ask
for
the
txt
or
the
https
record,
and
that
will
return
the
data
that
they're
looking
for
next
slide.
AA
AA
Some
of
the
ideas
that
I've
been
that
have
been
mentioned
to
me
one
is
to
use
the
ip
range
to
basically
use
the
the
internet,
no
object
to
to
store
this
geofeed.
This
is
actually
now
a
working
group
item
from
the
ops
awg
group.
I've
got
a
hard
time
to
find
how
we
could
make
it
specific
for
resolvers.
This
is
essentially
the
whole
ip
subnets
versus
just
like
the
subset
of
resolvers.
AA
The
original
ifc8805
draft
was
mentioning
using
name
authority
pointers.
I
didn't
dig
too
much
into
it.
I'm
not
reverse
with
the
record
itself.
It
seemed
to
be
kind
of
complex,
but
I
mean
for
the
sake
of
of
mentioning
it
here
and
now.
Also
people
have
been
mentioning
leveraging
reverse
lookups
to
find
given
an
ip,
a
request.
Let's
say:
rdns
dot.
Reverse
record
name
txt
record
to
to
find
to
find
this
to
your
feed
yeah,
and
I
think
that's
that's
it.
The
next
slide
is
essentially
opening
for
questions
feedback.
AA
AA
Q
Hi
benchmark,
okay,
I
think
I
have
two.
Maybe
three
comments,
the
so
the
the
https
record
that
you're
that
you
have
as
an
example
in
section
3.2
is,
I
think,
not
a
good
choice.
That's
not
really.
A
good
use
of
the
https
record
I'd
be
happy
to
work
with
you.
If
you
want
to
try
to
find
a
way
to
use
service
bindings
for
this,
I
think
we
could
talk
about
that,
but
I
think
that
probably
the
uri
record,
like
you
mentioned,
or
the
txt
record
format,
is
a
better
choice.
Q
I,
the
second
thing
I
wanted
to
say
was
about
the
the
geo
codes.
I
think
that
the
distributing
the
list
of
ip
prefixes
makes
a
certain
amount
of
sense
to
me
that
that
seems
logical.
The
the
geocodes
I'm
pretty
confused
about.
I
don't
understand
why
it
would
be
the
case
that
that
the
user
geo
code
could
be
inferred
from
the
observed
recursive
ip
address,
and
I
and
I'm
not
sh,
and
I
don't
see
why
the
location
of
the
recursive
resolver
is
of
any
interest.
W
AA
So
the
I
guess,
if
we
talk
about
user,
then
essentially
we
are
in
ecs
territory
yeah,
which
is
a
different
thing
here.
The
case
is
many:
people
are
building
geo,
targeted
answers,
usually
using
some
kind
of
geodb
database,
and
they
will
say:
oh
I'm
getting
this
query
coming
from
a
resolver
from
that
country,
so
I
put
it
into
that
bucket
and
I'm
going
to
return
this
kind
of
this
specific
answer
to
that
specific
location.
F
Q
AA
B
Y
Y
Y
There's
no
chance
that
the
the
name
servers
for
net
know
where
I
work
can
can
provide
information
about
my
home
resolver,
and
so
how
can
I
convey
the
information?
So
I
would
argue
that
a
better
place
to
put
the
information
for
the
resolver
is
in
the
query,
going
out
from
the
resolver
as
an
extra
option
in
the
in
the
edns
or
something
along
those
lines.
But
I
mean
maybe
totally
off
the
track
of
what
you're
trying
to
do
so
I'll
offer
that
as
as
food
for
thought.
O
I
spent
a
few
years,
an
enterprise
dns
company,
and
while
I
was
there,
I
learned
many
horrible
things
and
one
of
the
things
was,
and
the
reason
for
ecs
to
exist
is
that
the
state
of
the
art
before
ecs
was
to
use
exactly
the
address
of
the
resolver
that
you
see
at
the
authority
server
in
order
to
infer
something
about
the
location
of
an
end
user
and
it's
not
a
good
cure
and
that's
why
ecs
exist
and
pcs
also
has
problems.
It's
also
not
universally
adopted.
O
So
this
need
to
try
and
identify
and
locate
exit
addresses
for
resolvers,
even
though
it's
kind
of
horrible,
it's
real,
and
there
are
lots
and
lots
of
queries
that
all
of
us
do
every
day
that
depend
on
this.
In
order
to
give
us
responses
that
match,
you
know
a
suitable
local,
cdn
cache.
That
means
we
can
actually
stream
video
that
otherwise
would
have
come
across
an
ocean.
O
So
it
is
real
and
so
one
anecdotal
piece
of
information
that
I
heard
from
a
resolver
operator.
It's
quite
substantial
one.
At
a
broadband
isp
in
the
uk
who
talked
about
how
their
resolver
cluster
basically
had
to
be
configured
throughout
200
different
exit
addresses
and
in
software
they
had
to
configure
a
different
exit
address
for
a
query
that
was
set
up
stream
to
an
authority
server
based
on
the
ip
address
of
the
client,
because
they
couldn't
rely
on
any
dns
client
subnet
existing.
O
So
it's
an
awful
awful
horrible
piles
of
hacks,
but
it's
absolutely
required
in
the
real
world.
So
I
thought
I
just
mentioned
that
and
and
one
other
comment
as
well
about
iota
codes.
We
discovered
when
we
deployed
el
root
that
there's
at
least
one
country
in
europe
doesn't
have
any
airports.
It
doesn't
have
any
ir2
codes
and
it
was
difficult
to
try
and
find
a
name
to
map
that
country
in
our
naming
scheme.
O
X
AA
E
Yes,
thanks
everyone.
I
agree
with
what
lehman
has
said.
We
shouldn't
overload
the
txt
record,
and
actually
there
are
two
things
that
that
would
make
that
book
fall
beautifully
into
place
because
there
is
rs2753,
the
uri
record
resource
record
and
there
is
rsc585870
from
your
2d,
which
is
a
geo
uri
type.
J
Z
Z
Yeah
I'll
quickly
go
over
the
recap
of
the
problem
and
then
the
comments
that
we
received
from
the
working
group
and
the
updates
we
did
to
the
draft
and
especially
the
updates.
We
did
to
the
security
considerations
to
address
the
threat,
threats,
threat
models
that
were
discussed
in
the
working
group
next
slide.
Please.
Z
Okay,
this
draft
is
introduced
to
introduced
because
of
the
problem
that
venus
filtering
is
done
for
several
reasons
by
various
types
of
networks,
for
security
reasons
for
enforcing
parental
control,
internal
organizational
security
policies
and
isp's
filtering
because
of
the
court
orders
or
law
enforcement
agencies
asking
them
to
filter
specific
domains.
Enterprise
networks
typically
do
dns
filtering
to
block
malware
and
phishing
types
of
domains.
Home
networks
nowadays
are
offering
very
similar
services,
including
parental
control,
a
manufactured
user
description.
Z
A
recent
standard
which
is
quite
adapted,
discusses
enhanced
acl
to
include
domains
to
white
list
specific
domains
to
an
iot
device,
because
I
would
use
a
certain
depth
of
fiber
device,
specific
purpose
and
only
certain
domains
they
visit
and
only
those
domains
will
be
permitted
and
isps
nowadays
offer
malware
filtering
service
and
may
block
certain
domains
because
of
a
court
order.
Next
slide,
please.
Z
Whenever,
whenever
any
specific
domain
is
filtered,
the
the
end
user
needs
to
know
the
reason
why
it's
filtered
probably
a
decade
back.
It
was
quite
easy
that
many
of
the
content
providers
were
using
http
and
there
would
be
a
http
server
that
would
be
deployed
and
it
would
throw
an
error
batch
back
to
the
user,
but
that
changed
with
for
good
that
the
most
of
the
content
providers
have
now
moved
to
https.
But
with
that
the
trouble
is
the
end.
Z
Z
Several
times
may
switch
to
untrusted
interfaces,
and
the
user
is
eventually
forced
to
install
local
root
certificate
and
has
to
reinstall
the
certificate
whenever
it
expires,
which
is
which
is
cumbersome
and
error
prone,
and
the
local
certificate
could
be
used
as
an
mitm
for
other
for
other
purposes
as
well.
Next
slide,
please.
B
B
Z
Crashed
and
it
restarted
so
sorry
for
that-
the
exact
reason
because
of
each
block,
for
example,
if
you
see
here,
the
categories
because
of
which
domain
could
be
filtered,
could
be
quite
different
and
could
be
vendor-specific,
and
the
reasons
are
also
quite
specific
and
further.
The
user
does
not
know
which
entity
really
blocked
this
domain,
whether
it's
enterprise
network
or
the
isp,
which
blocked
it
and
with
and
whom
to
contact.
Z
Z
So
the
last
session
that
we
presented
was
using
a
https
resource
resource
record
type
to
convey
the
uri
template
for
providing
the
error
page.
But
then
there
was
quite
a
good
feedback
from
the
working
group
that
https
resource
record
type
was
not
the
right
or
resource
check,
record
type
to
use,
and
it
was
registered
to
pick
and
use
and
edn
is
option.
So
we
changed
the
draft
to
use
in
error
page
ets
option.
Z
So
if
you
see
we
have
an
uri
template
which
will
be
conveyed
in
the
edns
option,
I'll
come
and
talk
to
you
about
in
the
next
slides
about
the
signature
and
the
signature
algorithm
for
their
data
original
authentication,
especially
to
deal
with
the
problems
of
an
attacker,
injecting
this
uri,
for
example,
to
cause
a
phishing
attack
to
the
end.
Point
next
slide.
Please.
Z
A
simple
example
would
be
an
uri.
This
is
an
uri
that
the
dns
filtering
server
would
provide
and
the
client.
If,
if
let's
say
an
access
to
example.com
is
blocked,
then
it
would
use
a
base64
url
encoding
of
example.com
would
send
this
https
url
to
the
server
http
server
and
get
the
reason
exact
reason
why
access
to
that
domain
was
being
blocked
next
slide.
Please.
Z
Yeah-
and
this
was
this-
was
a
very
important
feedback
that
we
got,
that
how
do
you
handle
error,
page
uri
injected
by
a
non-path
attacker?
So
for
that
we
have
added
a
specific
section
to
talk
about
the
processing
rules
for
processing
these
error
uri
18s
option.
There
are
several
ones
so
I'll
list,
the
most
important
ones,
which
is
to
say
that
encrypted
dns
is
mandatory
for
this
to
make
sure
and
an
onboard
attacker
does
not
inject.
This
error.
Z
Uri
strict
privacy
profile
is
mandatory
if
opportunistic
privacy
profile
is
used,
which
means
that
to
say
that
either
the
client
could
fall
back
to
clear
text
or
may
ignore
the
server
certificate
validation.
In
those
cases
there
are
page,
url
has
to
be
ignored
any
any
any.
There
has
to
be
only
one
error,
page
uri.
They
can
never
be
more
than
one
error,
page
url,
because
it's
the
server
which
is
filtering
and
there
is
no
need
for
it
to
help
provide
multiple
url
options.
Z
It
could
only
provided
when
there
is
an
extended
error
code,
which
shows
whether
it's
insert
block,
filter
or
forced
it
has
to
only
come
with
https
url
scheme.
To
avoid
any
any
attacker
modifying
the
https
response
and
if
let's
say
nowadays,
many
browsers
have
pre-configured
resolvers
and
if
they
know
that
the
pre-configured
resolver
does
not
perform
filtering,
then
they
can
discard
this
uri
option
next
slide.
Please.
Z
The
other
important
change
that
we
did
to
the
draft
was
to
add
the
data
origin
authentication
because
it
cannot
be
dnsx
signed.
So
what
we
do
is
we
basically
because
the
and
tls
based
connection
is
mandatory
liquid,
either
dot
or
doh.
The
signature
is
generated
by
using
the
private
key
of
the
encrypted
dns
server
and
the
client.
Z
All
that
it
has
to
do
is
use
the
dns
servers
public
key
to
validate
the
signature,
and
it
would
know
that
this
adns
option
is
indeed
coming
from
the
dns
dvd
or
dvd
server,
and
it
is
not
coming
from
anybody
else
upstream,
and
it's
pretty
much
that
the
signature,
algorithms,
that
the
client
uses
for
tls
has
must
match
the
signatures
that
it
uses
in
the
dns
client
to
validate
these
signatures
next
slide.
Please.
Z
Yeah,
the
last
update
was,
with
regard
to
the
security
considerations,
to
say
that
encrypted
dns
is
mandatory,
data,
origin
authentication
is
mandatory,
and
how
do
you
handle
if
all
the
provisions
in
case,
if,
if
you're,
indeed
talking
to
a
malicious
dvd
server?
How
do
you
handle
a
phishing
attack?
In
those
cases,
we
followed
the
principles
that
a
captive
working
group
has
taken
where
the
page
would
be
loaded
as
an
untrusted
page.
The
client
browser
does
not
send
any
cookies.
Z
A
private
browsing
mode
could
be
auto
enabled,
and
the
error
page
could
be
loaded
in
and
contained
as
container
isolated
from
other
activity
to
prevent
from
malicious
uri
pages.
But
we
believe
this
would
solve
any
corner
cases
of
an
endpoint
using
a
malicious,
doh
or
duty
server.
Next
slide.
Please.
Z
Q
One
thing
you
didn't
mention,
though,
is
that
the
extended
dns
errors
draft
already
has
support
for
free
text
that
will
be
shown
to
the
user.
So,
given
all
of
the
restrictions
that
you
have
imposed
on
the
web
page
here,
why
is
it
important
to
have
a
web
page
as
opposed
to
just
making
use
of
the
extended
dns
error
code
text.
Z
Yeah
thanks
for
the
for
the
comment
ben.
So
if
you
see
the
extended
information
option
that
we
have
in
explanatory
errors,
it
does
not
impose
any
of
these
errors.
I
mean
it
could
basically
come
from
any
any
attacker.
So
if
you
look
at
extended
dns
error
page
option
today,
it
just
allows
even
allows
clear
text
dns
to
throw
those
error
error
options,
but
this
makes
it
quite
secure
and
through
a
lot
more
details
back
to
the
user.
Q
Z
Yeah
with
this
signature,
they
would
reject
that
because
it's
not
originating
from
the
server
it's
talking
to,
for
example,
consider
dns
forwarder
simply
forwarding
this
option
from
an
upstream
server
and
because
the
tls
connection
is
not
established
with
upstream
one
and
the
upstream
server
sends
this
option
back
the
dns
forwarder
simply
forwards
it.
The
client
would
detect
that
it's
not
coming
from
the
dns
forwarder.
It
is
talking
to.
AB
B
AB
B
O
I
assume
it's
working
I'll,
just
talk,
okay,
but
the
requirement
for
encrypted
secure
transport
was
kind
of
an
afterthought
to
deal
with
another
issue,
but
fundamentally,
like
eds
options
are
hot
by
hop.
I
I
don't
see
anything,
maybe
I
missed
it.
I
don't
see
anything
in
the
draft
that
describes
how,
for
example,
a
forwarder
that
receives
a
code
like
this
from
a
resolver
would
then
pass
that
back
and
what
signaling's
available
to
do
that
or
whether
there
are
chains
of
combinations
of
forwarders
and
resolvers.
O
I
think
in
in
general,
you
know
outside
of
the
the
narrow,
centralized
dot,
doe
type
application.
We
don't
expect
end
users
to
be
talking
directly
to
the
resolver.
That
would
be
during
the
blocking
usually
intermediaries,
and
I
so
I
think
it
makes
sense
that
the
dot
this
is
not
an
issue
that
works
with
centralized
dot
doh,
but
perhaps
the
draft
could
be
more
clear
that
this
is
only
a
solution
for
those
environments
and
not
a
solution
where
there's
something
further
upstream
than
the
resolver
graph.
That
is
actually
doing
the
filtering
and
providing
the
signaling.
R
So,
just
really
quickly,
following
up
on,
I
think
joe
and
actually
more
and
to
ben,
but
also
to
the
author
in
general.
You
know,
looking
back
at
the
discussion
we
had
with
ede
in
the
first
place
when
we
discussed
where
the
extra
field
the
extra
text
field
went
in
the
past,
we
didn't
really
come
to
consensus
on
how
it
would
ever
be
displayed
to
a
user.
R
In
fact,
I
think
the
general
consensus
was-
and
it's
even
written
in
there-
that
it's
for
operators
to
take
that
and
log
it
and
do
things
you
know
it's
not
intended
for
user
either
display.
So
this
draft
significantly
differs
from
that
in
many
ways,
and
one
of
the
reasons
that
to
highlight
joe,
we
did
not
come
to
conclusion
on
well.
How
do
you
deal
with
these
forwarding
and
hopping
kind
of
things,
and
how
do
you
deal
with?
You
know
messages
that
are
crossing.
You
know,
barriers.