►
From YouTube: IETF106-DNSOP-20191119-1710
Description
DNSOP meeting session at IETF106
2019/11/19 1710
https://datatracker.ietf.org/meeting/106/proceedings/
B
D
C
C
A
Slackers,
so
we
are
three
minutes:
late.
Welcome
to
DNS
op,
the
last
meeting
for
Tuesday
I
am
Tim.
That's
Ben!
Oh
that's!
Susan
down!
At
the
other
end
Warren's
over
there
he's
our
area
director,
Paul's
doing
minutes,
hi
Paul,
poor,
Dan
York
didn't
make
it
so
Tim.
Where
is
Tim
I,
don't
see
Tim
the
other
okay
I
need
my
glasses.
There
we
go
Thanks
he's
gonna,
be
doing
Jabba
scribe.
So
the
note
well,
please
note
it
details,
etc,
etc,
etc.
A
A
There's
only
like
three
or
four
different
talks.
Since
our
last
meeting,
we
believe
it's
been
kind
of
sad
guess.
We
haven't
had
a
great
fall
capture
format.
Finally,
got
done
obsolete,
vlv
is
in
the
end
of
the
queue
I
tell
you
for
moving
something
historic,
that's
a
lot
of
work.
You
know
I.
What
did
I
actually
spend
way
too
much
energy
on
that.
So
when
they
say
the
output
of
the
IETF
is
is
documents.
It's
like
it's
like
it's
a
One
Direction
thing,
so
I
do
think.
A
We
somehow
need
to
fix
that
the
poor
camel
was
suffering
on
that
one.
So,
but
that
should
be
done
soon.
We've
got
two
things
in
the
is
GQ
serve
sale
which
looks
like
berry
released
this
morning
and
the
no
response
issue
which
I
pushed
out
we
have
two
write-ups
going
on
and
I
am
committing
I
had
to
apologize
to
Ben.
Oh
like
three
times
yesterday,
because
I
want
2845
biz
done
this
week.
A
We're
gonna
push
that
along,
and
so
that's
our
commitment
to
you
that
will
have
that
Shepherd
write-up
done
and
probably
7706
biz
there
is
that
one
update
that
I
believe
the
authors
did
and
as
long
as
that
addresses
it
will
do
the
same
there.
So
hopefully,
by
the
end
of
the
week,
Friday
that'll
be
all
moving
along
because
we
have
two
things:
oh,
we
have
extended
error
which
is
coming
up
today.
That's
good
times
the
multi
provider
Dean
has
sex.
A
We
believe
it's
it's
a
good,
solid
document.
We
just
need
to
hear
some
more
stuff,
so
either
way
kind
of
thing.
Please
folks,
send
some
emails
do
something.
Maybe
the
authors
can
leverage
them
their
goodwill
on
people
and
ready
for
working
group.
Last
call
and
we've
been
sitting
on
these,
mostly
because
we've
been
trying
to
get
the
other
document
son
and
they
just
don't
want
to
go
as
fast
as
we
want
them
to
the
zone.
A
Digest
I
can
it
with
which
Dewayne
will
talk
about
briefly
and
the
TCP
requirements
that
he's
gonna
talk
about
briefly
on
Thursday
and
we
don't
think
they
need
a
lot,
but
we've
been
really
just
trying
to
get
that
backlog
going.
So
we
can
start
pushing
these
out
because
we
got
stuff
going
on
and
we
finally
adopted
that
yang
document
the
Cheras
wanted
to
send
it
to
the
ops
area
and
then
Warren
said
well,
that's
where
drafts
go
to
die
and
I
was
like
that's
what
I
thought.
A
A
We've
got
a
couple
other
documents
that
we're
not
going
to
talk
about
the
7816
biz,
which
expired
that's
kind
of
sad,
so
we'll
have
to
find
Stefan
and
see.
What's
going
on
there,
they
ain't
named
document,
it's
actually
gonna
be
discussed.
What's
that
did
I
get
that
wrong.
Oh,
is
that
in
D
Prime,
no.
E
E
E
Know,
7816
basis'
q
name
minimization
and
the
miss
will
be
both
to
possibly
put
on
standards
track
but
to
mostly
to
show
what
has
been
found
out.
You
know
in
in
deployments,
and
we've
got
some
interesting
research
articles
and
such
like
that.
So
last
I
heard
you
were
waiting
until
things
sort
of
settle
down
here,
because
we
weren't
in
a
rush,
we're
happy
to
try
and
Ralph
said
that
he
would
co-author
we're
ready
to
do
it.
Do
you
want
us
to
go
ahead?
Yeah.
A
I
figure
because
you
should
get
your
chairs
a
little
bit
more.
No,
we
missed
that.
No
yeah,
okay,
no
right
the
a
name
draft,
there's
actually
part
of
the
discussion
on
the
Ben
and
Eric's
draft,
actually
sort
of
covers
some
stuff
in
there.
There's
some
actually
some
interesting
stuff,
some
good
slides
in
there.
A
These
we
aren't
actually
gonna
really
cover
the
terminology
turf
and
we
figured
some
stuff's
gonna
come
up
from
that
ABCD
buff.
That
happened
earlier
today
and
some
other
stuff.
So
who
knows?
Probably
the
next
meeting
will
be
in
shape
to
do
something
and
the
resolver
information
people
seem
to
be
implementing
it,
but
they're
just
not
talking
about
it,
so
those
which
cannot
be
named
but
there's
actually
deprived
documents
that
seem
to
be
referencing
it.
A
So
that's
why
I
was
kind
of
wondering
where
that
status
was
so
that's
kind
of
else,
and
there
isn't
stuff's
going
to
be
talked
about
either
today
or
Thursday.
Most
of
it's
all.
Today
and
that's
you
know,
in
the
data
tracker
or
on
our
github,
we
have
an
adopted
a
bunch.
We
haven't
seen
a
lot
that
people
seem
to
be
sort
of
thrilled
on
that
may
change
after
they've
bought
this
book
this
afternoon.
A
C
More
practical,
well,
this
ITF
this
hackathon
as
usual,
a
group
of
Venus
software
engineers
gathered
around
the
table
and
also,
as
usual,
other
than
other
groups.
Actually,
we
didn't
have
a
plan,
one
single
plan.
We
had
a
number
of
plans,
so
each
software
developer
worked
on
an
ID
and
most
of
these
IDs
are
directly
relevant
to
the
needs
of
working
group
or
deprived
working
group.
C
C
So
recently,
all
the
network
code
has
been
refactored
out
of
the
DNS,
well
separated
from
the
dns
codes
in
by
nine
so
and
with
this
new
design,
the
new
network
design
do
H
as
been
can
be
easily
or
more
easily
fitted
in
in
by
nine,
so
Andre
words
on
that
and
about
timelines
I'm,
not
sure,
somewhere
early
next
year,
Dinah's
over
hb3,
quick
bene
in
senti
works
on
a
proof
of
concept,
implementation
based
on
the
clouds,
flare,
Kish
library.
It's
also
working
progress.
C
It's
good
bristles
here,
Dena's
protocol
improvement
villain
will
tell
Willam
worked
on
it
together
with
Andre,
and
it
was
interesting,
it's
kind
of
finalizing
the
draft,
but
also
testing
IDs.
So
if
the
draft
we
specified
this
way,
it
can
be
implemented
in
this
is
performance.
So
it
was
interesting
and
so
forth
between
specification
implementation
and
said
it
was
very
worthwhile.
Villain
will
tell
more
about
this
later.
Extended
error.
The
draft
will
also
be
presented
later.
There
was
already
some
code
in
unbound
and
Tim
Rotenberg
and
low
Gordon.
C
He
were
worked
on
well
on
update
in
the
couch
in
in
what
in,
according
to
the
latest
draft,
also
working
progress
was
not
completed
yet
during
the
hackathon,
the
service
provisioning,
so
Ralph
Norman's
words
on
an
update
of
his
implementation.
In
the
last
hackathon
last
in
Montreal,
Roth
implemented
the
HTTP
HTTP
VC
as
SVC.
C
The
draft
has
been
updated,
so
Rolf
also
updated.
The
implementation
inbound,
including
the
SVC,
be
records
and
not
everybody
has
tested,
but
there
are
some
similarities.
So
it's
good
work
here
going
on
and
there
will
be
some
feedback
to
the
document
specifically
for
the
implementation,
details,
Dina's
monitoring,
Paul,
Hoffman
and
violent,
or
worked
together
on
a
tool.
So
the
project
is
about.
C
Well,
the
project
is
more
than
only
this
tool,
but
the
project
is
about
the
kind
of
the
performance
performance
indicators
of
the
root
system
and
that
there
has
to
be
hundred
percent.
So
one
of
the
things
is
they
want
to
test
the
the
DNS
responses
from
the
past,
so
Phila
dating
a
root
zone.
You
have
something
like
filadyne
s
or
Aldean
s
35
zone,
but
that's
the
zone
file.
C
It's
not
the
response
from
a
name
server,
so
vilem
and
Paul
worked
together
to
build
a
tool
to
do
some
well
to
store
queries
from
the
past
or
to
store
queries
for
later.
Do
the
chain
validation,
the
DNA,
SEC
validation
of
answers.
So
to
summarize
it
correctly.
Thank
you.
Good
code
is
on
the
github
hackathon
website.
C
C
That's
it.
Maybe
some
questions
follow-ups
otherwise
go
directly
to
the
to
the
to
the
hackers
to
the
software
developers
for
more
questions.
That's
it
that's
my
part.
Ok
I
think
Duane
is
next
up,
but
just
as
a
really
rap
rap
rap.
Oh
sorry,
it
seemed
it
is
really
really
useful.
This
hackathon-
and
we
see
much
if
we
make
quite
some
progress
during
this
interaction
with
group
of
people
two
days
around
the
table
and
discuss
IDs.
It's
not
only
coding.
It's
also
a
lot
of
talking
about
good
ideas
and
how
to
for
go
forward.
H
All
right
so
I'm
doing
this
is
a
just
a
few
minutes
about
the
status
of
the
the
message
digest
for
DNS
zones
draft.
So
for
a
while.
Now
this
this
draft
has
supported
the
idea
of
algorithm
agility
that
this
is
a
change
from
the
variance.
So
now
there
is
the
idea
of
having
multiple
zone
MD
records
in
the
zone
after
after
that
change
was
published.
There
was
some
some
good
feedback
from
a
couple
of
people
who
pointed
out
some
some
issues
with
sort
of
forward
and
backward
compatibility.
H
So
an
important
change
in
the
very
last
version
is
that
the
the
digest
type
field
and
the
formerly
called
the
reserved
field
now
called
the
parameter
field.
Sort
of
the
interpretations
of
those
has
changed
previously,
the
their
interpretations
were
independent
from
each
other,
but
but
in
the
current
version,
the
the
inter
meaning
of
the
parameter
field
depends
on
on
the
digestible.
So
please
take
a
look
at
that.
That's
that's
that's
an
important
change.
H
H
There
are
currently
two
interoperable
implementations
of
the
zone
digest,
so
that's
that's
very
cool
and
we
think
it's
ready
for
working
group.
Less
call
and
I
would
also
like
to
ask
the
working
group
if,
if
so
previously,
there
was
a
little
bit
of
I
think
reluctance
on
the
working
groups
part
to
adopt
it
as
proposed
standard.
So
it's
currently
marked
as
experimental
and
I
would
like
to
ask.
If
people
have
maybe
changed
out
the
feel
about
that,
and
if
we
could
consider
going
back
to
proposed
standard.
I
J
To
go
a
little
bit
more
into
what
that
means,
as
far
as
the
intended
status
there's
a
section
in
the
document
now
that
describes
what's
experimental
about
the
the
proposed
deployment
and
I
think
that
the
question
that
we
really
have
to
consider
is
whether
people
are
comfortable
that
it's
deployable
as
as
written
you
know
it's
at
scale
or
the
suggestions,
good.
The
the
the
issues
called
out
in
the
section
about
the
experiment,
which
is
I,
believe
section
5,
you
kind
of
have
to
figure
out.
Do
we
need
more?
G
L
H
So
a
lot
of
the
discussion
earlier
on
was
about
how
you
would
support
large
dynamic
zones
with
something
like
this
and
and
so
that's
that's
also
the
nature
of
the
experiment.
So
if
you,
if
you
sort
of
restrict
this
right
now
to
smaller
or
stable
zones,
it's
it's
quite
easy
to
deploy
that
the
complexity
comes
from
from
the
other,
and
so.
L
But
for
me
the
obvious
use
case
is
downloading
the
root
zone
and
making
sure
and
validating
the
glue.
You
know
so
I
think
I
think
even
do
even
good
for
yeah
for
assigning
a
static
zone
isn't
necessarily
super
huge
I
mean
I.
Think
the
use
cases
are
already
really
obvious.
Yes,
you
know
so
please
move
it
ahead.
Okay,
thanks.
H
C
L
L
The
existing
signing
thing
is
technically
simple
enough
that
it
makes
sense
to
be
proposed
standard
if
people
want
to
do
experiments
with
funky
trees
for
updates
like
like,
and
that
can
be
an
experiment
and
and
I
guess:
I
will
defer
to
the
to
management
whether
that
needs
to
be
like
this
say
this
is
an
experiment
or
carbon
off
and
it
was
into
a
separate
document
or
or
more
likely
just
like
do
the
experiment
and
come
back
and
say
hey
this.
This
way,
this
way
of
signing
update
seems
to
work.
Okay,.
D
M
N
J
It
seems
to
me
that
unless
there's
strong
support
for
putting
this
out
as
experimental
PS
makes
sense,
just
because
experimental
is
kind
of
a
commitment
to
come
back
later
and
reevaluate
and
if
folks
don't
feel
that's
necessary,
I,
don't
know
I'm,
not
sure
we
should
commit
to
the
future
work.
Well,
I'll.
H
Be
a
little
bit
I!
Guess
more
talk
more
about
my
rationale
for
wanting
to
do
because
you
know,
as
John
said,
I
see
this
being
very
useful
for
the
root
zone
and
I
would
like
to
see
it
deployed
there
and
I
think
that
as
a
proposed
standard,
it
has
more
chance
of
of
getting
to
that
point
where,
as
people
may
be
reluctant
to
put
something
experimental,
you
know
on
the
root
zone.
J
I
O
C
C
C
K
But
if
we
go
really
fast,
we
can
go
to
the
social
okay,
I'm
Wes
Parker
I
was
going
to
talk
today
about
the
extended
error
conclusions
and
some
non
conclusions
from
the
working
group.
Last
called
number
two
I
will
say:
well,
there's
a
bunch
of
other
authors:
I
should
have
listed
them
and
I
didn't
my
apologies
to
all
of
them.
K
K
So
the
the
conclusion
that
I
think
was
fairly
easily
resolved
was
registry
changes
that
previously
there
was
three
different
sections
at
the
registry
and
we've
removed
that
and
changed
it
to
just
this
about
the
simplest
there's.
You
know,
there's
sixty-five
thousand
two
hundred
and
eighty
entries,
so
we
allocated
the
first
most
of
the
the
first
ones,
the
first
forty
nine
thousand
one
hundred
and
fifty-two
technically
as
first-come
first-serve.
K
If
anybody
has
a
beef
for
this
versus
requiring
technical
expert
or
anything
like
that,
but
there's
so
many
entries,
it
doesn't
seem
necessary
to
require
expert
review
or
anything
out
of
a
higher
string
and
then
the
last
one
there's
a
bunch
of
people
of
a
few
people
that
said,
they'd
still
wanted
a
private
use
space
going
once
going
twice
alright.
So
that
was
the
end
of
the
easy
ones.
K
So
now
there's
two
sort
of
major
issues
that
came
up
after
that
and
there
they
were
worth
discussing
enough
to
bring
here
today,
as
opposed
to
trying
to
resolve
them
on
a
mailing
list,
and
so
the
first
is:
what
do
we
do
out?
Udp
overflow
issues
so
overflow
happens
all
the
time,
especially
with
things
like
glue
and
the
normal
thing
that
we
do
is
we
set
the
TC
bit
a
truncated
bit
in
order
to
say
hey,
some
important
information
has
been
excluded.
K
K
K
So
here's
the
options
going
forward,
and
this
is
where
I
think
we
need
feedback.
We
could
don't
specify
anything
clearly
that
was
wrong
and
I
think
nobody
wants
that
option.
So
I
already
crossed
it
out.
We
need
to
drop
Edes
first
right
if
we
I
think
everybody
agrees,
it's
probably
the
least
important
information
at
this
point.
The
question
comes:
do
we
set
the
TC
bit?
K
Do
we
don't
set
the
TC
bit
and
just
leave
it
as
is,
or
do
we
create
a
new
bit
that
it
says
supplemental
information
was
dropped,
I'm
sort
of
on
the
fence?
I
would
love
lots
of
opinions
of
what
other
people,
especially
implementers,
that
actually
want
to
deal
with
this
and
do
stuff
based
on
it
excellent.
P
P
P
K
Got
it
so
so.
Thank
you
remember
that
these
can
be
included
with
any
sort
of
response,
and
that
even
includes
no
error
responses.
In
fact,
I
think
there's
some
examples
of
that
in
the
draft
of
when
you
might
so
you're
right,
so
that
it
might
be
unusual
for
this
to
actually
occur
in
the
wild,
but
it
still
absolutely
so.
R
Mike
hi
Mike,
st.
John's.
You
said
something
interesting
where
the
data
retrieved
on
TCP
might
not
be
the
same
day
that
you
have
gotten
under
UDP.
You
know
the
error
that
okay,
the
the
error
response,
and
that
means
that
if
you
set
any
bit,
there's
no
reason
to
go
to
hit
TCP
because
all
you're
gonna
get
you
may
not
get
what
you
were
trying
to
get
right.
So
you
need
either
to
make
that
data
the
same
or
carry
it
over
and
say
well.
R
K
G
This
is
Andre
I
see
so
from
the
implementers
point.
Don't
do
anything
special,
so
GC
bid
is
perfectly
fine
because
it
will
happen
only
in
one
of
million
and
switching
to
TCP
is
the
thing
we
are
going
to
do
anyway.
So
just
set
the
tcp
if
it
doesn't
fit,
don't
care
about
there.
That
is
not
in
the
tcp.
That's
fine.
There
is
over
behind
late,
but
a
reasonable
code
will
not
handle
yet
another
option
and
yet
another
different
handling.
So
please
don't
treat
it
and
especially
just
just
use
the
normal
code
math
for
it.
G
K
H
Eric
or
chrome
DNS
I
want
express
support
for
the
creating
a
new
bit
option,
just
because
I
can
see
lots
of
cases
where
you're
doing
some
debugging
up
and
you're
gonna
want
to
get
that
extra
info
if
it
was
dropped,
but
in
the
case
of
Chrome
I,
don't
think
we're
gonna
want
to
make
another
request
to
get
it.
It's
good
enough
without
the
error
info,
we're
not
going
to
want
to
make
another
round
trip
to
do
that.
H
S
T
Robert
Robert
story
is
I,
I'm,
gonna,
say
the
opposite,
but
everybody
else
is
saying
and
you
didn't
consider,
leaving
ete
and
maybe
shortening
the
the
glue
records.
Because
people
are,
you
know
if
you
say:
you're
gonna
set
truncation.
If
you
don't
have
enough
glue,
but
you
only
have
ete
if
it
was
specifically
requested,
so
they
asked
for
a
needy
response
so
throwing
it
away
and
keeping
to
fit
in
some
extra
glue
records.
T
K
U
R
K
So
be
careful
there
right,
because
the
TC
bit
is
a
hint
that
you
should
retry
over
TCP
and
hopefully
you
will
get
everything,
because
the
dns
is
a
flexible
system.
There's
no
guarantee
that
when
you
ask
again
that
something
won't
have
changed,
so
it's
not
a
guarantee
at
all.
It's
a
strong
indication.
G
More
opinions
would
be
good
because
we're
a
andrey
again
so
I
just
want
to
support
what
you
said
best,
because
when
you
send
a
query
via
UDP,
you
might
hit
a
different
server
in
a
cloud
or
any
cost,
and
then,
when
you
connect,
50
CB
might
get
be
hitting
at
completely
different
server.
That
will
give
a
completely
different
answer,
so
the
state
between
the
UDP
or
TCP
never
existed
in
Deanna's,
and
it
should
not
not
be
introduced,
especially
not
in
this
minor
draft
yeah.
Now
that's
a
very
good
point.
C
K
K
K
So
discussions
with
a
couple
of
people
led
to
a
series
of
options,
so
I'm
gonna
list
them
all
here,
some
of
which
I've
already
struck
out
because
they
don't
seem
wise,
but
they're
all
listed
for
completeness
one.
We
could
mandate
that
no
forwarding
happens,
you
just
drop
it
all
on
the
floor.
I,
don't
think
anybody
wants
to
do
that
and
I
think
the
comments
on
the
list
clearly
indicated
that
we
could
mandate
the
resolver
and
forwarders
simply
copy
it
forward.
K
So
you
just
you
know
if
you're
generating
more
stuff
back
to
the
client,
then
you
just
you,
know
copy
it
all.
In
and
off
you
go
note
that
resolvers
may
have
been
talking
to
more
than
one
upstream.
You
may
have
been
talking
to
more
than
one
authoritative
server
that
may
have
given
you
some
ete
options
that
you
may
want
to
pass
them
all
back
to
the
client,
which
makes
it
kind
of
hard
to
figure
out
for
the
client.
Where
did
all
this
stuff
come
from?
K
You
could
just
copy
and
adjust
that
extra
text
field.
So
you
add
an
extra
bit
of
information
to
the
front
of
it.
Saying
hey,
you
know,
I
was
talking
to
somebody
else.
They
gave
me
this
error,
I'm
gonna,
augment
it
saying
where
I
got
it
from
this
doesn't
seem
like
the
most
wise
thing
to
do,
because
you're
modifying
somebody
else's
information
and
we'll
get
back
to
formatting
in
a
little
bit
so
options.
Four
to
seven
four,
you
could
add
some
tracing
elements
to
the
packet.
K
We
could
recommend
adding
source
indication
like
with
another
ete
supplemental
flag,
that
you
would
add
after
the
other
one
and
say
well,
I
got
this
previous
one
from
this
other
guy
and
that
actually
would
require
sorting.
That's
why
number
five
is
crossed
out,
because
there
is
no
requirement
right
now
that
resource
records
be
sorted
and
I
really
don't
think
we
want
to
insert
that
requirement.
In
fact,
some
implementers
said
no
I
wouldn't
do
that
of
course
number
six.
K
We
could
make
the
document
experimental
that
was
suggested
on
the
list
as
just
get
more
deployment
exercise
and
come
deal
with
it
later
and
number.
Seven
is
your
idea
here
which
Brian
will
fill
us
in
on
and
then
it
give
me
one
minute.
Brian
so
number
for
one
I
think
is
where
external
consensus
before
this
discussion
has
sort
of
come
to
a
conclusion
that
adding
a
single
source
to
the
ete
generating
by
the
e
de
generating
entity
and
then
passing
that
on.
So,
in
other
words,
the
is
sort
of
the
new
proposed
packet
format.
K
And
so
you
can
see
that
the
new
there's
a
new
flag
on
the
on
the
bottom
right,
there's
a
source
length
on
a
source
field
that
gets
added
and
then
some
indication
of
source
and
we'll
get
into
that
in
a
second
part
of
this
discussion
of
this
was
generated
by
8
me
by
some
definition
of
me
and
we'll
get
to
that
in
a
minute.
But
Brian
go
ahead.
I.
U
Was
gonna
insert
my
idea
here
saying
4.1
with
an
identity?
Identity,
for
this
is
gonna,
be
coming
from
another
thing:
if
the
ATD
working
group
or
ABCD
working
group
actually
forms
something,
I
was
gonna
hope
to
work
on
there
effectively
local
locally
generated
global,
unique
but
locally
scoped
name
to
be
usable
within
a
forwarding
chain.
That
would
let
you,
if
it's
an
upgraded
resolver,
actually
do
like
a
TCP
direct
DNS
trace
route
or,
as
a
minimum,
have
the
ability
to
a
generate
an
identity
that
is
useful.
K
P
N
It
on
the
floor
default
at
the
moment,
and
we
know
that
we're
not
good
in
DNS
to
kind
of
upgrade
stuff.
So
unless
all
the
kind
of
forwarders
in
the
past
implement
that,
then
well
we'll
drop
it
on
the
floor
anyway,
and
if
the
foreword
is
implemented,
I
think
they
can
make
an
informed
decision
to
give
back.
The
correct
error
I
mean
that
was
with
the
implementation.
Saying:
okay,
I
got
this
error
and
maybe
got
it
from
somewhere.
The
somewhere
might
actually
not
be
reachable
for
you
because
of
forwarding
change
of
private
space.
P
K
H
H
Actually,
the
more
information
it
can
include
the
better
it's
the
more
useful
it
can
be
for
debugging
the
more
it
can
help
whatever
the
next
hop
is,
but
because
there's
no
signal
here
in
the
query
that
requests
this
information
there's
essentially
no
choice,
but
to
do
this
all
the
time,
and
so
we're
proposing
to
essentially
include
potentially
a
very
large
amount
of
information
in
every
single
response
packet.
If
I.
H
H
H
F
H
B
K
G
I
see
so
Wes.
If
you
need
a
sentence
to
draft
I
would
say
forwarding.
They're
handling
of
EDD
forwarding
is
not
specified
by
Z
so
command,
and
it
is
implementation
specific.
There
may
be
like
thunderous
later.
It
doesn't
have
to
be
experimental.
It
could
be
unspecified
and
said
it
is
this
implementation
specific
and
just
deal
with
if
this,
until
one
we
have
more
experience.
So
this
is
like
sakes,
but
not
making
the
document.
K
That
is
because
so
trying
to
quote
some
of
the
the
people
that
brought
this
up,
it's
most
likely
a
resolver
that
would
get
some
of
these
errors
and
they
would
want
to
know
how
to
forward
it
to
the
client,
because
otherwise
the
resolver
is
gonna,
do
nothing
but
log
the
information
and
it's
not
as
it's
not
as
helpful
to
the
world.
If
the
end
client
and
the
end
thing
that
started
this
whole
chain
doesn't
get
that
chain
of
extra
information,
I'm
sort
of
pseudo,
quoting
other
people,
hi.
V
I,
don't
think
qualified
to
have
a
really
a
technical
pinion
on
the
various
options,
but
I
would
like
to
point
out
that
conceptually
at
least
for
the
more
application
oriented
codes
like
the
ones
on
filtering
at
least
a
need
for
them
to
get
forward
throughout
that
entire
chain.
Otherwise
they
are
completely
useless.
So
if,
if
there's
a
CP
doing
forwarding,
for
example,
it
does
the
need
for
they
call
Sweden
to
get
forward
at
10:00
today
to
the
client,
otherwise
it.
Why
do
we
add
them?
So
I
think
four
point
one:
okay,
thank
you.
Whatever.
J
K
J
P
I
see
again
sorry
to
pick
on
something
been
said.
This
goes
back
to
what
I
was
just
about
a
genus
and
hop-by-hop
yeah
when,
if
you've
got
a
folder
in
the
path,
it
will
already
strip
every
DNS
option.
That
comes
back
because
that
you
Denis
Eady
s,
options
have
no
semantic
meaning
whatsoever,
but
other
than
between
two
parties.
That
exchange
those
specific
messages.
So
if
I
could
send
a
query
to
a
folder
yeah,
whatever
any
dense
options
go
out
from
there
or
up
to
the
folder
I'd
have
liked
to
do
with
the
client.
P
Similarly,
what
comes
back
from
the
folder
are
irrelevant
as
far
as
the
clients
concerned,
that's
normally
units
behavior
and
that's
why
I
have
concerns
about
this
whole
idea
of
sending
stuff
back,
because
even
this
just
doesn't
work
that
way.
It
is
exclusively
for
use
between
an
individual
client
and
the
machine
is
talking
to
it's.
H
P
That
there
is
lots
of
specific
ITAT
I
mentioned,
that's
in
68,
sorry,
well,
a
common
phenomena
for
the
revised
e
was
50
because
of
my
pretty
long
5625.
If
all
you're
doing
is
that
forwarding,
then
there's
an
expectation?
Yes,
you
can
you
basically
treat
the
DNS
packet?
Is
almost
sufism
opaque
blob,
so
what
goes
out
goes
through
than
that?
It
goes
up
to
the
upstream.
Server
comes
back
again,
but
if
you're
in
the
DNS
path
actually
process
the
Nunez
packet,
then
eagerness
has
no
semantics
through
that
forwarding
path.
That
makes
sense
to
me.
U
Maas,
so
I'm
gonna
try
and
keep
it
short,
but
I
just
sort
of
a
heads
up
that
people
may
want
to
have
tomatoes
ready
to
throw
at
me,
because
I'm
gonna
suggest
something
which
is
basically
from
a
semantic
perspective.
I,
don't
think
forwarders
that
aren't
eating
ege,
upgraded
or
in
it
have
any
other
advanced
features
at
any
value.
U
So
the
fact
that
it
goes
through
forwarders
if
it's
able
to
determine
that,
there's
no
conflict
in
the
addressing
and
it's
able
to
directly
reach
the
true
resolver
if
it
can
find
its
name
somehow
and
address,
which
is
the
stuff
I'm
going
to
be
working
on
in
the
other
group.
This
may
make
most
of
this
moot
I
hope.
K
K
K
K
Three
minutes
all
right,
so
really
I'm,
probably
okay,
so
if
we
add
a
source-
and
that
remains
to
be
determined.
But
if
we
went
down
the
the
will
go
back
to
the
list
and
get
some
evaluation
of
other
people
at
this
point,
it's
interesting
to
see
that
the
discussion
has
turned
back
around
to
sort
of
what
the
document
says
now
in
in
a
lot
of
it.
K
K
Remember
that
this
would
be
added
by
the
entity
generating
the
option
so,
first
off
an
IP
address
a
URL,
a
IP,
colon
port,
assert,
subject:
name
right,
there's
lots
of
ways
that
a
host
might
be
identifying
itself
after
thinking
about
all
this
NS
ID
is
actually
very,
very
generic.
It
is
a
binary
blob
that
should
be
printed
via
hex.
If
you
go
read
the
NS
ID
description
and
it
can
accommodate
anything.
K
K
K
J
K
J
H
It's
also
intended
to
solve
version
of
the
cname
at
Apex
problem,
possibly
not
the
entire
cname
at
Apex
problem,
but
at
least
a
big
chunk
of
it
and
in
addition
to
SVC
B
itself,
there
is
HTTP
SVC,
which
is
an
HTTP
specialized
form
that
that
is
intended
for
use
with
HTTPS.
This
is
what
we
originally
presented,
so
ITF
105.
We
presented
HTTP
SVC
and
got
consistent,
or
at
least
repeated
feedback
that
people
would
like
to
see
a
solution
that
was
less
specifically
bound
to
HTTPS.
H
One
of
the
things
you
can
do
with
this
record
is
to
do
multi,
CDN
hosting
with
encrypted
sni.
This
has
been
one
of
the
trickiest
challenges
with
encrypted
sni,
where
there
are
multiple
IP
addresses
that
could
be
associated
with
your
domain
name,
corresponding
to
different
pools
of
servers
operated
by
different
parties.
Those
parties
have
different
public
keys,
and
so,
when
you
do
your
DNS
queries,
you
need
to
get
back
an
IP
address
and
the
public
key,
and
it's
fairly
important
that
that
IP
address
and
public
key
are
a
matched
pair.
H
That's
why
you
need
to
get
them
in
a
single
query,
instead
of
in
two
separate
queries,
which
potentially
could
give
you
the
IP
address
of
one
CDN
and
then
the
public
key
of
the
other
one,
so
that
in
presentation
form
in
a
zone
file,
these
records
have
two
possible
forms.
One
of
them
is
called
the
alias
form.
It
looks
like
this.
H
It's
it's
a
simple,
alias
of
a
name.
It's
essentially
only
intended
to
be
used
at
apexis.
If
you're,
not
at
the
apex
of
his
own,
you
should
probably
use
a
cname,
but
but
when
aliasing
and
apex
this
can
can
make
that
possible
and
the
other
form
is
called
service
form.
This
is
used
by
ESI.
In
fact,
it
is
now
referenced.
H
H
So
there
have
been
quite
a
few
changes
since
IETF
105,
most
notably
the
generalization
to
SVC
B
and
this
importantly,
a
change
in
syntax.
So
if,
if
you
look
at
the
example
in
this
slide,
we
have
the
in
red
this
key
equals
value
syntax
in
the
zone
file
that
is
no
longer
the
HTTP
alt
service
and
tax,
which
is
what
what
the
last
presented
version
of
this
had.
But
those
were
before
adoption.
So
hopefully,
people
have
seen
this
since
adoption.
There
have
been
smaller
changes
and
I
won't
go
through
all
of
them.
H
So
there
are
two
major
remaining
design
questions
in
in
my
view,
although
I
would
not
at
all
be
surprised
if
we
discover
some
more
in
the
course
of
implementations,
beginning
and
in
the
course
of
further
reviews
of
the
draft.
One
of
them
is
related
to
reliability,
fallback
and
yes
and
I.
So
it's
when
building
reliable
start.
It's
very
nice.
H
It's
very
convenient
if
your
clients
have
a
fallback
behavior
where,
if
they
attempt
a
connection
to
one
of
the
various
options
that
exists
and
that
attempt
fails,
their
clients
will
retry
down
some
sort
of
list,
but
with
encrypted
sni.
It's
very
important
that
your
clients
not
fall
back
from
an
attempt
that
used
encrypted
sni
to
an
attempt
that
did
not
use
encrypted
s
and
ims
revealed
the
thing
that
the
server
was
trying
to
protect.
H
H
So
the
question
is
how
many
times,
if
you
encounter
an
alias
how
many
times
should
you
keep
following
aliases
before
you
essentially
give
up
so
and
in
something
like
a
loop
detection,
I
want
to
point
out
in
case
you
haven't,
read
the
draft
that
these
aliases
intermix
freely
with
cname.
So
the
question
is
not
to
have
to
limit
the
question
is
not
how
to
limit
the
number
of
total
hops
or
in
the
inner
or
total
links
in
a
forwarding
chain.
H
The
question
is
in
a
forwarding
chain
which
could
potentially
can't
contain
some
mixture
of
these
records
and
see
names.
How
many
of
these
alias
form
records?
Should
we
allow
in
that
chain,
and
you
know,
do
we
need
to
enforce
something
like
if
you
have
an
alias
to
a
cname
to
an
alias?
Is
that
allowed
or
not
allowed
things
like
that?
H
There's
one
other
question
that
I
realized
after
making
these
slides,
that
I
think
would
be
worth
covering,
and
that's
just
to
say
that
the
current
description
of
the
required
server
behavior
at
least
that
the
recommended
server
behavior,
which
is
section
4,
really
could
use
some
review
from
server
implementers.
Both
authoritative
and
recursive
I
think
that
there's
we
could
use
a
little
bit
more
specificity
in
describing
exactly
what
additional
records
should
be
returned.
H
So
those
are
the
substantive
questions.
There
are
also
two
purely
bike
shed
questions
that
that
we
need
to
deal
with.
One
of
them
is
about
the
presentation
format
I
in
a
previous
slide.
I
showed
you
this
form
with
a
zero
here.
You
know
the
presentation
format
is
a
is
fairly
flexible.
If
we
want,
we
could
get
rid
of
this
zero
opinions.
Welcome
I,
guess,
and
the
other
thing
is
what
to
name
this
thing.
We
have
names,
of
course,
the
that
we've
presented
here.
H
S
P
Regulus
I
see
the
doctrine,
talks
about
cooperating
servers
and
saying
they
should
look
up
the
a
records
quad
a
record
so
whatever
just
from
point
of
view
of
our
our
type
allocation
with
that
level
of
conformance
requirements,
you
may
not
be
able
to
get
early
allocations
through
expert
review
if
it
was
a
May,
I
think
you'd
be
okay.
That
should
just
is
getting
to
a
point
where
it
exceeds
the
expectations
that
an
expert
reviewer
can
go,
because
if
there's
required
additional
processing,
then
it
has
to
go
to
a
full,
is
IHF
review.
H
Eric
or
Chrome
DNS
two
comments.
One
on
the
chain
length
chrome
is
very
sensitive
to
latency.
This
is
in
the
critical
path
for
loading
web
pages.
For,
however
many
users
we
have-
and
we
just
want
to
avoid
around
unnecessary
round
trips
as
much
as
possible.
So
unless
someone
has
real
concrete
use
cases
for
why
the
chain
lengths
should
be
eight,
we
should
be
reducing
that
as
much
as
possible
to
make
it
sure
everyone.
H
The
Gries
is
kosher
for
Lansing
sensitive
clients
like
chrome,
to
stop
doing
the
round
trips
as
soon
as
they
can
as
soon
as
it
becomes
clear.
This
is
an
unreasonable
use
case
to
try
anymore.
My
other
comment
is
I
hate,
HBS
services,
I'm,
surprised,
I
was
able
to
say
it
and
just
one
try
there,
it's
very
hard
to
say:
I
do
not
like
it.
Please
come
up
with
a
better
name:
okay,.
M
Alex
may
over
Nick
today,
tea
I,
admit
I,
haven't
I,
haven't
read
the
document,
but
a
question
came
to
my
mind.
That
is:
could
that
service
that
is
being
referred
in
that
record
also
be
the
authoritative
name
server
for
a
certain
domain.
So
would,
in
theory,
that
the
record
sort
of
like
create
an
alternative
delegation
structure
to
a
name
serve
for
domain,
and
could
that
record
in
that
case,
solve
the
problem
of
key
discovery
for
an
authoritative,
encrypted
DNS
server?
It's
just
like.
H
H
I
H
H
I
H
H
H
I
I
It's
just
like
so
I
found
it
somewhat
confusing.
Okay,
the
other
thing
is
like
from
you
know,
speaking
for
Claude
Fleur,
we
are
interested
in
this.
I
can
talk
with
the
with
the
DNS,
authoritative
server
people
and
see
like
if
they
have
comments
about
this,
as
well
as
the
the
resolver
people
I
guess
we're
both
I.
S
H
So
here's
a
have
an
additional
slide
that
might
be
relevant
to
that.
I
won't
go
through
all
the
details
here,
but
I
think
that's
essentially
right
until
some
very
hypothetical
and
distant
time.
We
will
not
be
able
to
rely
on
all
clients
implementing
this,
and
so
you
know
whatever
you
have
to
do
today.
You're
still
gonna
have
to
do
that
for
some
fraction
of
clients
all.
S
Right
in
a
second
one
point,
Peter
Sawchuk
expanding
on
chain
limits,
any
latency
would
be
introduced
by
site
owner
who
also
has
insensitive
not
to
do
stupid
things
to
his
own
side.
Also,
it
would
be
hard
to
implement
special
chain
langs
link
limits
for
just
2
RR
types.
Please
keep
the
usual
DNS
behavior.
U
Brian
Dixon,
Oh,
daddy,
plus
a
thousand
what
he
just
said.
I
would
even
go
so
far
as
to
suggest
in
the
metadata
for
this
to
say
that
it
updates
D,
name
and
C
name
and
to
make
them
all
play
well
together.
I,
don't
see
any
reason
not
to
in
regard
to
the
chain
lengths
chain
lengths.
Yes,
it
should.
It
should
support
any
arbitrary
ordering
and
number
of
processes
through
the
loop.
It's
it's
again.
It's
foot
gun
from
the
whoever
owns
the
zone.
Whoever
manages
it
it's
their
own
fault.
U
W
Costly
regarding
one
of
those
issues,
number
73
saying
that
yes,
ni,
has
its
own
secure
fallback
mechanism
that
uses
a
yes
and
I
retry
a
yes.
Now
you
try
message
so
I.
Don't
think
the
DNS
draft
needs
to
deal
with
that
and
regarding
Frick
versus
HTTP
I
agree
that
there's
a,
but
maybe
you
can
just
say
that
if
you
only
publish
quick
itv3
vehicles
and
then
you
DPS
our
interval,
it's
the
configuration
fault.
W
Well
so
there
I
my
PSN
eyes
are
this
format
problem
and
regarding
I
HT
3
3
vs
HTTP,
phobic
yeah
I
agree
that
if
UDP
is
unreachable,
then,
and
if
the
only
if
the
server
only
publishes
its
remapping,
then
it'll
be
clear
that
there's
a
irritability
problem.
So
maybe
you
can
just
say
that
I'll
leave
it,
as
is.
H
So,
just
to
explain
that
a
little
more
I
guess
the
assumption
here
is
that,
because
there
will
always
be
or
because
there
will,
for
a
long
time
be
clients
who
aren't
implementing
SVC
be
at
all,
you
should
you'll
likely
be
able
to
fall
back
to
a
non
SVC,
be
connection
or
you're
just
connecting
on
bare
IP
addresses,
except
if
you
accept,
if
you
have
ES
and
I,
if
you
started
with
the
s
and
I,
then
that
Avenue
will
fall
back
is
cut
off.
That's
why
these
things
interact.
N
N
Reiterate
what
all
my
fellow
resolver
opera
vendor
après
said:
I
mean
the
the
cname
chain
problem
really
is
solved,
there's
nothing
to
do
ender
and
the
they
were
usually
also
is
a
caching
of
these
kind
of
negative
events
when
beneath
when
the
change
exceeds.
So
there
is
really
not
much
latency
that
a
stub
resolver
will
get
if
if
there
is
a
consistent
problem
for
for
that,
the
other
thing,
the
hint
section
I
looked
at
that
text
and
maybe
I
mean
I-
think
it's
I,
don't
see.
The
hints
used
anymore
could
I
misread
that
yeah.
H
H
N
X
X
H
P
Comments
earlier
with,
with
my
expert
review
hats
on
so
you
actually,
you
need
basically
a
fully
stable
specification
clicking
at
early
allocation,
because
implementers
will
actually
in
fluent
at
that
point,
so
the
presentation
format
needs
to
be
fixed.
The
Wi-Fi
that
needs
to
be
completely
fixed,
I
just
had
checked
with
all
my
other
reviewers.
We
also
live
the
opinion
that,
if
it
says,
may
so
that
it's
truly
optional
processing
you'll
be
okay
for
expert
review.
But
if
you
say
should
that's
too
strong
the
requirement
to.
X
J
J
Y
H
Correct,
if
you
see
in
it,
if
you
see
an
alias
record
as
a
recursive,
you
have
to
you,
have
to
fire
three
queries.
If
you
don't
and
and
essentially
pass
it
to
the
client,
essentially
you
don't
implement
the
should
strength
recommendation.
Then
the
client
will
instead
have
to
issue
at
least
two
probably
three
queries
with.
Y
H
Y
H
But
that's
certainly
an
interesting
idea.
I
would
have
to
think
more
about
it.
Maybe
the
one
thing
I
would
say
is
it
creates
an
operational.
It
creates
an
operational
tie
between
the
alias
source
and
target,
and
so
it's
it's
a
little
bit
unpleasant.
For
that
reason,
if
a
CDN
changes
its
configuration,
you
wouldn't
want
to
have
to
tell
all
the
customers
that
they
also
have
to
change
their
configuration.
G
Andre
I
see
so
I'm
so
happy
that
we
are
finally
abandoning
the
a
name
and
moving
the
problem.
Early
should
have
been
from
the
beginning.
So
from
the
implementers
perspective,
I
see
no
problem
there
and
I'm
even
willing
to
buy
the
bullet
and
implement
the
IP
hints
if
it
helps
you
to
move
from
a
name
to
whatever
you
name
it
in
the
end
and
implement
it
in
the
clients
where
it
should
have
been
from
the
beginning.
Thank
you.
S
Relaying
for
Dan
York
have
developers
of
clients
expressed
interest
in
implementing
SVC,
B
or
HTTPS
VC
I.
Do
we
have
people
out
there
who
we're
excited
to
implement
this
I?
Think
Apple
said
this
earlier:
okay,
so
if
they're
clients
wanting
to
excited
being
excited
to
implement
this
there's
what
Dan
Erica.
S
J
Z
Y
H
U
Cool
so
I'm
sure
that
Brian
Dixon
/
GoDaddy
that
we're
very
interested
in
implementing
at
least
the
zero
case,
as
well
as
possibly
a
limited
amount
of
these
other
more
advanced
forms
as
soon
as
it
stabilizes
and
maybe
some
kind
of
label.
That
starts
with
an
H.
How
about
Hugh,
hu
e?
That's
a
generic
term
for
a
bike
shed
color.
H
Okay,
so
we
would
like
to
make
progress
as
as
fast
as
we
can,
of
course,
on
this
draft
in
particular,
this
draft
is
blocking
certain
is
one
of
the
things
that
blocks
the
widespread
deployment
of
es
ni.
So
there's
a
there's
a
certain
amount
of
pressure
to
move
forward
on
this,
but
it
also
sounds
like
we
should
be
able
to
make
good
progress.
I
want
to
especially
thank
people
who
started
prototyping
and
I
look
forward
to
the
feedback
from
the
prototyping.
C
C
Good,
so
please
continue
also
this
discussion
on
the
mailing
list,
blue
sheets
for
the
yeah,
so
we
already
heard
some
kind
of
commitments
on
the
Mike
for
early
implementations
from
different
organizations,
we're
quite
happy
with
that
so
and
also
before
working
last
call.
We
would
like
to
see
a
number
of
implementations
of
our
prototype
proof
of
concept
implementation
also
draft.
Okay,
then
we
want
thanks.