►
From YouTube: IETF101-DOH-20180322-1330
Description
DOH meeting session at IETF101
2018/03/22 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
A
A
E
D
F
D
B
B
G
D
Yep,
okay,
okay,
so
the
AV
crew
is
working
to
actually
Hotwire
the
presentation
laptop
directly
to
the
projector,
which
will
mean
that
you
people
who
are
on
remotely
wouldn't
be
able
to
see
the
slides,
but
they
are
all
uploaded
to
the
data
tracker.
And
so
you
can
follow
them
there.
And,
while
still
looking
for
a
minister,
mr.
Aaron
Falk
I
see
you
sitting
in
the
audience
and
apologies.
H
D
D
And
so
as
we
are
getting
closer
to
starting,
although
the
note
well
is
not
up
on
this
screen,
you
are
all
at
this
point,
no
doubt
very
familiar
with
it
and
as
usual
for
ITF
working
group
meetings.
It
applies
here,
I,
don't
think
if
anybody
has
any
agenda
bashing
items,
we're
happy
to
discuss
them,
but
the
main
plan
right
now
is
to
start
with
Stefan's
report
on
how
the
hackathon
went
and
then
listen
to
Paul
and
Patrick
give
their
update
on
the
current
status
of
the
draft
and
the
future
direction.
D
And
then
we
will
have
a
brief
discussion,
hopefully
of
the
possibility
of
retarding
reach
our
turing.
If
we
could
have
more
if
we
were
to
have
more
work
group
items
and
then
finally
Daniel
con
Gilmore
will
talk
to
us
about
the
general
issue
of
how
do
you
trust
your
DNS
data
Stephan?
Would
you
like
to
start
even
without
slides,
I.
I
I
J
I
My
slide
so
it's
okay,
Stefan
BOTS,
may
have
a
sneak
so
at
the
cuttin
that
were
around
the
six
people
working
on
the
Doty
and
it's
a
very
TPS,
which
is
a
lot
hope
for
the
economy,
shows
that
there
is
a
lot
of
interest
about,
though
we
have
today,
five
public
doe
service,
while
three
are
more
or
less
in
production
and
two
are
very
experimental,
meaning
they
work
from
time
to
time
interesting
things
that
they
all
use
a
different
server
software.
So
there
is
already
a
lot.
A
variety
of
software
for
fall.
I
On
several
libraries,
while
you
will
see
everything
if
you
want
on
the
get
above
the
IETF
Academy
nice,
so
basically
the
reasons
are
very
good
because
everyone
is
able
to
talk
to
each
other.
I
cannot
say
that
I'm
surprised,
because
dough
is
something
which
is
very
simple.
We
already
know
the
DNS
file
format,
just
put
it
in
HTTP,
not
not
a
big
deal,
so
I'm,
not
surprised
that
it
works.
When
you
want
scuze
me
Topanga.
Are
you
aware
that
there
are
no
slides
on
the
screen.
I
So
that
it's,
but
a
bit
was
difficult
when
you
want
to
integrate,
though
in
some
libraries,
not
because
there
is
some
specific
problem
with
door
with
the
draft,
but
many
DNS
driver
ways
well
return
with
some
assumptions
about
how
the
transport
will
work,
for
instance,
assuming
that
there
is
a
socket
available
and
you
can
just
pass
a
socket
to
as
an
Ender
to
a
transport,
so
this
libraries
will
have
to
be.
We
organized
for
supporting,
do
other
possible
Ahnold.
I
So
are
we
have
as
we
seen
if
you've
read
the
mailing
list,
many
things
are
not
perfectly
specified.
There
may
be
obvious
for
some
people,
but
not
for
others.
For
instance,
people
who
come
from
an
HTTP
background
for
them.
Some
of
possible
status
code
are
obvious,
but
they
are
not.
If
you
come
from
the
DNS,
so
I
will
not
repeat
all
the
things
that
were
discussed
on
the
mailing
list
on
these
rules
that
were
very
apparent
at
the
occasion.
The
problem
of
forget
post
option,
for
example
yeah
Suzanne
from.
I
Okay,
so
the
problem
with
Messer,
the
HTTP
methods,
for
instance,
nobody's
thought
about
options
when
we
discovered
that
by
default,
a
JavaScript
client
try
the
options
method.
Also
some
servers
report
only
post
some
clients
were
written
with
the
assumption
that
you
could
always
use
get
so
this
sort
of
problems.
There
was
also
the
problem
of
catching
one
of
the
existing
servers.
Sender
expires,
other
others
and
back
cache
control.
Some
with
max-age
deduced
from
the
DNS
TTL.
Some
are
lazy
and
just
return
no
cache
on
what.
So.
I
There
is
a
more
general
problem
when
there
is
something
wrong.
What
do
you
report
on
the
HTTP
side,
for
instance,
if
there
is
a
DNS
problems
such
as
we
fused
cetera,
do
you
translate
it
into
a
DNA
to
HTTP
response
code,
or
do
you
return
to
Android
unless
the
DNS
client
passed
the
wizard
so
that
basically
the
the
things
that
we
discovered,
but
that
well
important
during
the
occasion?
Of
course,
it's
not
the
complete
list
of
problems.
Next,
don't
think
there
was
the
next
one.
Okay,
any
questions,
remarks
contradictions.
A
Paul
Hoffman
I
want
to
emphasize
that
we,
the
document
authors,
learned
a
heck
of
a
lot
from
the
implementations
over
the
hackathon.
Unfortunately,
we
were
learning
them
during
the
hackathon
I
thought.
I
was
actually
going
to
see
London
over
the
weekend,
and
that
was
wrong
because
the
hackathon
was
very
useful
for
us
elucidating
some
of
the
questions
that
came
up
on
the
list,
and
hopefully
you
will
see
the
answers
to
those
in
the
next
draft,
but
just
as
a
general
thing
for
people
who
go
to
hackathons.
H
D
M
Togusa
Terry,
so
I
posted
a
link
to
a
github
project,
but
basically,
when
you
send
a
post
with
that
mime
type,
it
will
do
a
pre-flight
request
to
try
and
decide
if
it
should
service
should
respond,
and
so
it
sends
the
options
first
and
if
the
server
doesn't
respond
to
the
options,
or
in
this
case
it
responds
with
a
404.
Then
the
post
never
gets
in,
and
then
you
can't
get
the
response.
I.
I
M
N
Pat
McManus
Mozilla
I
can
elucidate
a
little
bit
I'm.
Actually
don't
think
this
is
a
problem.
I
think
this
is
a
successful
execution
of
a
feature
and
an
explicit
goal
of
the
document.
One
of
the
goals
of
the
document
was
to
enable
JavaScript
based
content
based
applications
to
be
able
to
participate
in
dough
right,
consistent
with
the
the
web's
same
origin
and
cross-origin
security
policies
right
and
that's
exactly
what
we're
seeing
here,
which
is
which
is
real,
which
is
really
great.
N
So
what
you're
seeing
is
more
or
less
a
side
effect
of
applying
those
security
policies
in
a
JavaScript
content
and
someone
deploying
a
server
that
anticipates
cross-origin
traffic
from
a
javascript
application
needs
to
understand
that,
and
that
is
all
actually
encapsulated
a
lot
more
like
above
do'
and
once
you've
cleared
the
pre-flight.
You
know
the
data
specification
was
then
in
effect,
and
the
purpose
of
the
pre-flight
is
to
actually
make
sure
that
you
don't
speak
any
other
specification
until
the
pre-flight
is
cleared.
So
it
actually
is
a
separable
concept.
M
O
There's
been
a
bit
of
discussion
on
little
mosaic.
Sorry,
it
might
work
okay,
Tony
Finch.
The
there's
been
some
discussion
on
the
mailing
list
about
maybe
some
non-normative
advice
to
implementers
about
how
to
do
HTTP
right
in
this
context
and
I
think
we've.
So
far,
we've
been
talking
about
response
code
to
status
code
ami
and
extending
that
to
cover
options
as
well
would
probably
be
worth
doing.
P
Q
N
N
No
2
came
out
of
that
fairly
quickly.
Thanks
to
the
feedback
we
received
in
the
room
a
couple
months
after
that
enough
felicitous
session,
and
it
happened
to
trigger
a
no.3
which
is
mostly
what
folks
have
been
implementing
and
talking
about
until
the
hackathon,
which
is
really
good,
which
to
have
a
lot
of
new
feedback.
N
Mostly
you
know
mostly
non
normative
in
nature,
maybe
completely
not
normative
in
nature
actually,
and
we
put
out
a
no
for
last
night
to
capture
those
changes
because
they've
been
a
substantial
number
and
we
wanted
to
make
sure
that
we
were
all
talking
about
the
same
thing
with
a
check
point
in
this
presentation:
I'm
not
going
to
assume
that
you've
read
over
forgiven.
That
I
came
out
in
last
24
hours,
and
it
is
my
my
dearest
hope
that
we
meet
our
milestones.
The
working
group
has
a
milestone.
N
It's
April
2018
to
submission
to
iesg
of
this
protocol
document.
You
know
people
like
to
say
they
told
me
it
couldn't
be
done
and
when
they
say
that
they
usually
like
air-quote
the
day,
it's
not
clear
like
I
know
who
you
are,
who
told
me
it
could
not
be
done
and
we
can
do
this.
So,
let's
not
you
know,
grab
defeat
from
the
jaws
of
victory
here.
We
can
pull
this
off
so,
regarding
you
know,
for
like
I
said
last
night,
an
important
thing
to
know
is
that
is
why
you're
compatible
with
o3.
N
That
is
certainly
not
a
requirement
for
internet
drafts
that
we
not
change
anything
but
I
always
view
it
as
a
really
good
sign
that
we
are
not
fussing
with
the
protocol
components
as
much
as
we
are
fussing
with
the
descriptions
of
those
protocol
components
so
I'm
heartened
by
that
hackathon,
really
awesome,
hey
hackathon
was
really
awesome,
see
when
you
cut
off
my
thank
yous.
Thank
you
right.
N
So
it
did
create
a
real
big
burst
of
mailing-list
traffic
and
paul,
and
I
sat
down.
We
tried
to
sort
through
it
all
and
we
tried
to
capture
that.
As
of
24
hours
ago
into
the
document,
you
know,
obviously
some
judgments
have
been
made
there,
so
you
know
read
it
and
see
if
we,
you
know,
captured
the
essential
items
in
a
way
that
you
can
live
with,
because
obviously
there
were
some
times
disagreeing
viewpoints
on
the
mailing
list
as
well.
N
N
Okay,
so
details
in
North
or
I
mean
generally,
it
is
much
more
succinctly:
guarding
applicability,
I
see,
Martinus
and
the
polar
quest
since
the
meeting
started,
making
it
yet
more
succinctly
regarding
applicability.
You
know-
and
this
is
I
think
this
is
generally
a
worthy
goal
that
reflects
a
tension.
The
working
group
has
been
having
about
whether
you
know
more
or
less
text,
it's
interesting
so
where
we
had
cases
that
enumerated
a
few
use
cases
and
enumerated
a
few
positive
properties.
There
was
often
feedback
of
saying
you
know,
that's
all
true,
but
what
about
you
know?
N
R
N
The
other
direction
we
can
to
generalize
those
concepts
to
say
it's
good
for
the
following
broad
classes
of
problems,
period,
write
it
down
and
you
know
15
words
or
something
I
have
a
suggestion
that
if
folks
are
interested
in
finding
a
venue,
it
may
be
the
dough
working
group.
But
though
not
this
document,
you
know
documents
surrounding
applicability
and
interactions
with
the
rest
of
the
broader
ecosystem
that
may
be
well
defined,
but
not
necessarily
elucidated
on
at
length.
N
You
know
might
be
an
interesting
piece
of
work
to
take
on,
but
just
separate
us
in
a
vertical
definition.
In
any
event,
there
is
more
clarity,
around
error,
handling
and
DNS
HTTP
interaction.
Again
I
would
prefer
not
to
enumerate
all
the
status
codes
already
enumerated
by
7230
X,
but
the
basic
questions
around.
Do
you
report
errors
which
kind
of
errors
get
recorded
in
which
layers
and
what
does
the
success
code
versus
a
non
success
code
mean
with
respect
to
your
age,
to
your
DNS
query
that
seemed
critical
enough.
N
That
I
think
we
try
to
address
that
head-on
and
obviously,
if
you
don't
think
that's
true
again,
you
know
feedback
would
be,
would
be
great
clarity
around
caching,
there
is
actually
perhaps
some.
This
is
a
little
less
editorial.
I
think
there
are
actually
some
good
rules
applied
here
to
what
you
do
in
failure
cases
that
weren't
previously
there
it
is
very
helpful
media
formats.
N
An
important
goal
of
this
work
is
to
support
multiple
media
formats,
but
the
document
was
using
a
hypothetical
one
to
help
represent
some
of
this
negotiation
that
could
go
on
and
using
a
hypothetical
format,
probably
created
more
confusion
than
clarity.
So
it
no
longer
does
that,
but
it
does
stress
to
point
out
that
there
is
a
content
negotiation
mechanism
available
in
HTTP
and
media
formats,
not
defined
by
this
document,
are
still
fit
into
this
ecosystem
and
there's
a
bunch
of
you
know:
capitalization
changes.
N
All
right,
so
what
I
want
to
do
with
time
here
on
the
next
two
slides
we've
got
the
the
two
issues
that
were
open
last
night
when
I
submitted
these
slides
very
late
thanks
to
the
chairs
for
being
kind
about
that,
but
there's
a
lot
of
late
moving
action,
so
I
think
we
should
discuss
those
two
slides.
One
is
this
issue
about
which
you
know
which
methods
are
involved,
and
one
is
an
issue.
N
Maybe
it'll
be
easy,
now,
they're,
all
a
little
more
comfortable
with
the
protocol
about
whether
the
one
media
type
that
is
defined
in
the
document
is
mandatory
to
implement
or
not,
and
then
I
think
we
have
some
time
to
open
the
mics
to
tell
us
what
people
think
needs
to
be
addressed
before
we
could
put
this
thing
into
working
group
last
call
because
I
would
hope
to
do
that
within
the
next
couple
weeks.
Okay,.
N
Issue
of
82
we've
really
opened
82
issues
on
this
document,
more,
it's
like
102,
or
something
oh
yeah.
To
be
fair.
Some
of
those
are
polar
Chris,
not
not
issues,
method
restrictions,
so
the
current
state
in
the
document
it
defines
what
get
means
and
how
one
replies
to
it
defines
what
post
means
and
how
one
replies
to
it.
It
does
not
tell
you
which
of
those
you
need
to
implement.
N
N
There
are
valid
use
cases
forget
and
for
posts
that
the
other
method
cannot
satisfy
so
they're,
not
strictly
over
overlapping
supersets
of
each
other,
but
in
not
all
of
those
use.
Cases
apply
to
all
environments,
and
so
I
will,
like
summarize
this
post
is,
is,
is
more
concise,
uses
fewer
bytes
because
it
avoids
the
URI
encoding
issues.
It
doesn't
have
a
limit
length
of
the
encoding,
which
is
often
a
problem.
N
N
Specifically
HTTP
to
push
does
not
know
how
to
push
a
post,
but
it
can
push
again.
So
if
you
were
interested
in
that
functionality,
you
would
need
to
get
method.
I'm
sure
others
will
have
comments
on
pros
and
cons,
but
that
is
my
high
level
sketch
on
you
know
what
is
valuable
about
each
of
those
approaches.
N
N
So
that
may
be
one
answer
to
this
problem
is
that
our
discovery
question
does
not
merely
a
URI
is
a
URI
and
method
combination.
On
the
other
hand,
mandatory
to
implement
is
indeed
a
very
valuable
property
which
I
will
argue
for
strenuously
when
we
get
to
the
next
issue.
So
I
don't
want
be
totally
hypocritical.
N
H
A
L
H
A
H
I
I
guess
you
know
you
get
to
interesting
places
where
theoretically,
a
server
could
be
using
like
let's
say
you
deploy,
go
through
a
CDN
or
reverse
proxy
and
the
server
really
really
really
wants
to
use
an
HTTP
cache.
Do
they
redirect
to
a
you
know
resource
which
they
can
do,
which
is
incredibly
inefficient,
but
you
know,
maybe
if
they
bang
it
into
the
head
of
the
client
enough,
then
they'll
get
the
idea.
H
M
J
Peaks
at
its
discretion,
which
means
that
the
client
gets
to
choose
whether
there
are
things
cashable
which
is
yeah
suboptimal.
There's
no,
like
he's
gonna,
be
able
to
cache
the
push
the
post
response,
even
though
they
are
cacheable.
If
you
put
the
right
header
files
in
here,
but
that's
a
terrible
idea.
T
Mark
Jenner,
Khan
Gilmore,
so
I
want
to
so
I
think
that
both
also
makes
sense
and
I
think
both
make
sense
both
for
the
server
and
for
the
client,
and
let
me
explain
why,
in
the
event
that
the
server
decides
to
redirect
a
post
request
to
a
get
request,
because
they
feel
more
comfortable
serving
a
get
request.
If
we
expect,
though,
to
be
a
reliable
DNS
delivery
mechanism,
then
what
you're
basically
saying
is
that
a
client
that
only
implements
post
is
gonna,
see
this
redirect
and
be
like.
Oh
I,
don't
know
what
that
was.
T
Therefore
it
didn't
work,
and
so,
if
the
expectation
is
that
we
want
doe
to
be
like,
if
we
want
someone
to
be
able
to
opt
in
to
doe
as
their
only
DNS
delivery
mechanism,
then
you
need
to
require
that
the
client
does
both
as
well.
If
that's
not
the
expectation
of
of
doe,
then
I
don't
care
about
what
my
client
can
obviously
ignore,
whatever
it
wants
to
ignore,
because
clients
can
already
ignore
whatever
they
want
to
ignore.
T
C
N
Want
these
semantics
I'm
saying
a
server,
might
do
these
semantics
yeah,
so
I!
This
is
intriguing.
I
haven't
really
thought
about
this,
but
when
I
do
think
about
this,
my
inclination
is
your
redirection.
The
scope
of
it
is
for
a
single
transaction
you're
not
going
to
be
able
to
like
essentially
say
this
is
a
new
server
over
here
start
using
it
you're
just
gonna,
say
you
can't.
You
can
find
the
answer
to
the
exact
question
you
asked
over
here
and
that's
probably
not
a
mechanism
that
one's
like
really
that
interested
in
doing
right.
H
I'll
just
say
old
service,
mark
Nottingham,
old
service
I
think
that's,
probably
a
horrible
abuse
of
alternative
services,
but
sure
why
not?
H
H
N
H
N
H
Right
can
I
finish
thanks.
I
think
what
this
is
going
to
do
is
is
that
some
people
are
gonna
configure
those
patterns
in
their
serving
infrastructure.
You
know
in
CDN,
backend
servers
and
they're,
not
gonna.
It's
not
gonna,
be
as
easy
for
them
to
extend
those
benefits
to
other
parties.
So,
for
example,
the
client
cache
or
another
intermediate
cache
is
that
the
in
the
world?
J
Yep
maaan,
Thomson
I
think
there's
a
little
bit
of
a
confusion
about
what
actually
happens
in
the
case
that
you
get
this
redirect
I
mean
it's.
It's
not
a
scenario
that
I
expect
anyone
to
encounter,
because
it's
just
to
write
round-trips
for
the
price
of
one.
But
what
happens
is
you
get
the
URI?
You
need
and
you
make
it
yet
request.
This
is
just
what
you
do
when
you
implement
HTTP.
It's
not
anything
that
we
need
to
talk
about
in
this
document,
especially
I.
J
Think
this
is
the
point
of
confusion
here
where,
yes,
you
will
be
making
a
doe
request,
maybe
so
that
you
think
that
there's
it's
not
necessarily
even
in
the
form
of
a
get
request
that
we're
talking
about
it
might
not
have
this
DNS
equals
base64
in
it.
It
might
just
be
some
random
URL,
so
the
server
has
already
given
everything
given
the
client
everything
it
would
need
to
to
act
upon
this
and.
N
Sorry
I
think
for
our
you
know,
combined
cultures
here
in
this
room.
What
I've
tried
to
describe
that,
as
is
a
302
or
307?
It's
actually
a
non
successful,
a
she
B
response
code.
It's
just
not
fair!
The
DNS
answer
to
the
question
you
asked
correct.
You
could
call
this
a
failure
instead
of
non
successful
with
that
and
so
harsh
and
it
provides.
You
is
not
a
terminal
failure
because
it
provides
you
a
location
response
that
says.
N
D
My
observation
seems
to
be
that
we
are
reaching
or
have
reached
consensus
on
making
well
well
I
understand
in
the
room,
so
perhaps
as
a
term
of
art.
Yeah
it's
not
suitable,
but
that
getting
posts
for
the
server
would
be
MTI
and
for
the
client
would
be
either
and
if
anybody
would
like
to
argue
against
it
here,
we'd
like
to
hear
your
comment
right
now.
Otherwise
we're
going
to
move
on
to
the
next
issue.
N
You
know
obviously
I've
summarized
issue
48,
but
it
says
that
the
document
describes
a
reference
to
DNS
UDP
wire
format
as
a
media
type,
and
the
issue
essentially
asks
you
know:
should
this
be
mandatory
to
implement,
because,
obviously
you
know
wire
format
from
RFC
1035
might
not
be
like
the
most
friendly
minimal
set.
One
could
provide
to
a
JavaScript
developer.
For
example,
the
draft
says
this
is
fully
expressive
of
what
we
want
to
be
able
to
do,
and
it's
important
that
we
have
something.
N
V
V
In
those
messages,
I'd
argued
for
saying
we
should
lashka
calling
it
the
UDP
Y
formats
just
wire
formats,
because
there's
no
reason
why
you
couldn't
put
a
4k
5k,
whatever
message
and
I,
think
we
needed
this
instrument
between
UDP
Y
formats
and
TCP
Y
format,
because
ultimately
they're
saying
that
the
TCP
forum
has
a
little
bit
of
framing
on
it,
which
we
don't
need.
I
mean
there
is
still
a
wire
format
which
TCP
is
an
extension
of.
N
A
J
W
L
A
W
N
A
doubt
it
does
indicate
maybe
not
strongly,
but
but
the
attention
of
the
mandatory
implement
format
would
be
that
if
the
client
were
to
receive
one
of
these
packets
I
mean
you
can't
force
it
to
send
much
of
anything,
but
it
receives
one
of
these
packets.
It
should
need
you
to
interpret
it
so
you're,
probably
looking
at
like
the
content
negotiation,
except
in
the
different
and
the
different
ways.
That's
done
right.
Yes,.
W
X
N
So
if
the
server
is
unable
to
respond
like
this,
just
HP
rules
I'm
sure
if
the
server
is
unable
to
respond
with
one
of
the
content
media
types
that
was
enumerated
in
the
request,
it
has
the
choice
of
throwing
for
mumble
mumble
error
that
indicates
that
yeah
or
giving
the
answer
it
knows
how
to
give
like
it
is
allowed
to
do.
That's
the
part
that
I
didn't
know.
Man
I
wish.
We
had
this
in
DNS.
N
P
P
U
Yeah
I
think
the
wire
format
without
the
UDP
should
be
mandatory
to
implement
I
would
also
love
to
have
a
minimalistic
Jason
for
light
weight.
Applications
that
want
to
talk
to
this
and
I
think
therefore
mother
Google
has
today
is
perfectly
acceptable
for
all
of
those,
especially
in
the
case
when
the
application
trusts
the
resolver,
whether
we
want
to
have
another
JSON
format.
That
is
then
all
encompassing.
That
will
take
us
a
few
years
to
agree
on,
but
would
be
good
too
yeah
I
agree.
That'd.
N
C
K
A
J
So
the
current
format
basically
says
that
you've
got
this
content
type
header
for
your
content
type
parameter,
that's
in
in
the
query,
and
you
use
that
to
switch
what
the
rest
of
the
query
parameters
mean.
Presumably,
if
you
wanted
to
go
to
something
decomposed,
you
could
have
multiple
query
parameters
or,
as
it
is
currently,
you
have
a
single
one.
J
Dns
equals
blah,
and
then
you
don't
have
to
pay
what
a
roundtrip
to
get
your
answer,
because
the
server
that
supports
the
new
stuff
can
look
at
the
new
stuff
and
the
server
that
supports
the
old
stuff
can
look
at
the
old
stuff
Johnny
risk.
There,
of
course,
is
that
you've
made
two
requests
and
they
might
not
be
the
same
request.
So
go
ahead.
A
So
there's
two
issues
with
what
you
just
said:
I'm
sorry,
what
that
was
Martin
Thompson's
two
issues
with
what
you
said.
One
is
that
the
the
answer
that
comes
back
might
not
have
the
same
security
properties
if
the
response
type,
for
example,
doesn't
support.
Dns
SEC,
which
is
very
common
in
the
JSON
things,
so
might
still
be.
Okay,.
A
J
Might
be,
for
instance,
you
might
say
I
just
want
and
a
record
for
the
following
name
and
if
you
devised
a
way
of
packing
that
into
the
query
parameters.
That
would
be
a
very
easy
way
to
make
that
make.
Even
though
you're
saying
that
you
would
understand
the
full
wire
format
right
right,
yeah
I
mean
oh
I'll,
take
all
of
the
extra
RSS
you
want
to
throw
at
me
and
all
the
a
DNS
options
and
the
DNS
SEC
and
what-have-you.
But
it's
right.
Sorry,
it's
shiny.
It's.
N
N
I
think
there
probably
is
some
complexity,
particularly
in
the
description.
I'm
curious.
How
well
like
the
room
was
able
to
follow
what
was
going
on
there
right
and
that
yeah
I'm
just
trying
to
decide
like
the
value
in
doing
that
versus
what
we
have
I
mean.
Do
you
agree
that
what
we
have
answers
the
minimal
question
and
that
we
enable
new
media
formats
that
aren't
you
scrapped
in
the
shop
commit.
J
S
C
So,
yes,
it
it
seems
like
again
so
far
we
within
the
room,
we
have
consensus
on
this,
and
we
will
confirm
that
on
the
mailing
list
and
authors,
please
consider
alternative
ways
to
structure
the
query.
I
would
also
advise
you
to
consider
the
implications
of
different
query
structures
on
the
types
of
Vienna
registries
that
are
going
to
be
required.
A
J
Z
Kirsti
pain,
I
wanted
to
plug
something
about
section,
8
security
considerations
just
regarding
enterprises
that
want
to
defend
themselves
from
malware
that
perform
DNS
lookups
on
the
external
Internet
and
I
can't
see
anything
in
the
draft
as
it
is
about
that,
since
the
DOE
traffic
will
be
indistinguishable
from
report
four
for
three
normal
TLS
traffic
lose
control
over
what
DNS
lookups
they
use
could
perform,
might
be
much
harder
to
block
or
scam
DNS
lookups
of
dodgy
domains
for
users
and
the
mitigation
to
that
would
be
TLS
proxy.
Z
Everything
which
is
far
more
invasive
than
currently
just
proxying
DNS,
as
allowing
your
TLS
rapid,
pass
end-to-end.
So
as.
N
A
T
The
draft
of
the
draft
at
this
is
the
Daniel
con
Gilmore
from
they
tell
you.
The
draft
actually
says
filtering
or
inspection
system.
In
the
security
consideration
section,
it
says
filtering
or
inspection
systems
that
rely
on
unsecured
transported,
dns
will
not
function
in
a
DNS
over
HTTP
environment.
So
I
believe
that
addresses
the
concern.
I'm,
not
sure
what
what's
missing
from
that
or.
K
C
So
if,
if
this
draft
goes
through
last
call
and
and
is
completed
and
we
find
the
working
group
without
any
drafts,
we
will
immediately
close
the
working
group.
So
if
you
have
anything
else
that
you
want
to
talk
about,
you
must
submit
a
draft
before
that
time.
Additionally,
it
we
would
note
that
the
deadline
for
asking
for
a
working
group
slot
is
the
1st
of
June.
C
So
if
we
don't
have
any
evidence
that
we're
going
to
have
anything
to
talk
about
in
in
Montreal,
then
we
will
not
have
a
session
in
Montreal
and
and
the
working
group
will
be
closed.
So
if
you
wanted
to
write
a
draft
for
dough,
that
would
be
a
good
thing
to
know
now.
And
if
you
want
to
write
a
draft,
then
we
should
consider
whether
your
death
is
within
the
current
Charter
or
whether
it
would
require
reach
our
during
the
working
group.
C
X
T
D
AB
Something
where
you
wanted
to
have
it
be
cache
more
based
upon
that
would
probably
require.
Is
there's
not
a
straight
for
an
obvious
way
to
do
that
within
HTTP
semantics,
so
we
would
likely
want
to
have
something
either
here
an
HTTP
this.
If
that's
something
that
the
one
would
have
a
support
mechanism
for.
C
D
And
I
just
want
to
again
address
Adams
point.
The
reason
for
my
assertion
was
at
the
very
first
sentence
of
be
charter,
for
the
wedding
group
is
that
this
working
group
will
standardize
encodings
for
DNS
queries
and
responses.
So
it
seems
to
me
that
encoding
a
responses
JSON,
would
be
right
there
in
the
first
sentence,
but
I
again
he's
our
area
director
and
we
would
review.
N
My
HTTP,
this
co-chair
hat
on
because
that
was
speculated
on
for
the
last
offer.
That's
really
not
suitable
over
there
that
that
would
be
more
about
how
a
content
server
like
a
doe
server.
You
know,
interprets
the
content
so
yeah.
We
need
a
different
venue,
I'm,
not
exactly
sure
which
one
that
is,
but
it's
not
HDTV.
This.
U
No
comment
all
are
two
things:
yes,
I'm
interested
in
seeing
a
charter
PB
in
charter
that
two
people
can
specify
Jason
media
formats
and
are
to
the
prior
gentleman's
about
electic
about
the
client
subnet.
Just
don't
do
it
don't
use
that
if
you
have
any
further
questions.
What's
the
video
of
Bert's
presentation
at
the
end
of
software
group
about
the
clock,
Campbell's.
D
But
for
a
lot
of
you
that
may
have
missed
the
NS
up.
Quite
understandably,
the
vertebra
of
power
DNS
gave
a
presentation
on
essentially
how
there
is
a
lot
of
straw
on
the
camel's
back
and
arguably
has
already
been
the
last
one
that
has
broken
it,
and
so
the
added
complexity
of
the
DNS
might
be
something
that
you're
really
trying
to
avoid.
D
The
one
thing
I'll
ask
for
explicitly
is
that
the
topic
of
discovery
came
up
a
lot
both
in
the
github
and
on
the
mailing
list
over
the
past
several
months,
and
so
that
seems
to
be
one
that
were
especially
interested
in.
If
somebody
wants
to
work
on
it,
if
nobody's
gonna
work
on
it,
that's
totally
fine,
but
to
be
clear
that
is
within
scope,
and
if
it's
not
getting
addressed,
then,
if
it's
going
to
be
addressed,
we
really
need
to
see
something
by
June
and
then
in
case.
The
word
discovery.
A
Interest
in
coming
to
the
mic
at
the
moment,
you
gave
us
actually
more
than
a
week
to
do
this,
and
some
of
us
need
to
think
about
which
of
those
we
want
to
do
in
specific
I
might
do
a
discovery.
One
I
have
an
interest
in
it,
but
I
also
got
the
crap
beat
out
of
me
when
I
brought
it
up
the
last
time.
So
I
have
to
decide
whether
I
want
to
or
not
yeah.
C
It's
it
to
be
clear:
I,
don't
think
we're
not
talking
about
closing
the
Working
Group
until
the
current
draft
has
completed
all
of
the
various
Massa
nations,
so
not
just
starting
last
call
not
just
completing
last
call
but
but
the
whole.
The
whole
process
for
which
the
working
group
may
be
required.
W
Is
there
any
interest
in
the
working
group
and
working
on
that,
because
I
think
you
know
that
might
inspire
somebody
to
work
on
the
draft
if
there's
interest,
but
if
everybody
says
no
tomatoes,
then
I
I
can't
imagine
that
anybody's
gonna
be
that
interesting.
I
think
we
heard
that
a
little
bit
in
what
Paul's
reaction
was.
It's
certainly
my
feeling
as
well.
T
This
is
Daniel
and
Gilmore.
My
understanding
is
that
a
doe
endpoint
is
defined
by
a
URI
currently
and
if
we're
talking
about
a
discovery
mechanism
that
goes
from
a
IP
address
to
a
URI
or
from
a
domain
name
to
a
URI.
This
does
not
strike
me
as
any
sort
of
rocket
science,
and
if
someone
wants
to
spend
a
little
bit
of
time
doing
that
to
define
this
particular
thing
is
we
have
a
very
clear
input.
We
have
a
very
clear
output.
C
So
so
my
my
my
personal
assessment
is
that
there
is.
There
is
quite
a
bit
of
interest
in
the
working
group
in
in
solving
this
problem.
There
are
also
quite
a
few
people
in
the
working
group
who
who
don't
particularly
have
interests
in
this
problem
and
there's
quite
a
bit
of
opposition
to
specific
approaches
and
mechanisms,
so
whether
there
exists
a
mechanism
that
that
would
resolve
the
issue
for
the
people
are
interested
and
which
would
not
encounter
significant
opposition.
I,
don't
know.
D
The
main
point
of
this,
as
we
wrap
up
this
I
mean
the
agenda,
was
just
to
indicate
that
it's
now
or
never.
If
you
have
more
work
for
the
working
group,
it's
going
to
be
the
time
they
decide
to
do
it.
We
don't
expect
you
to
commit
right
now
in
this
meeting,
but
the
deadline
is
visible
and
so
that
wouldn't
bring
up
a
dkg
to
give
us
a
presentation
on
getting
your
dns
off
a
back
of
a
truck.
C
T
Yeah
so
so
I
actually
presented
the
set
of
slides
at
the
hot
RFC
earlier
earlier
this
week.
I
really
can't
tell
if
this
mic
is
on
or
not
but
I'm,
not
gonna,
assume
it
is,
and
people
will
tell
me
if
it's
not
so
so
I
want
to
talk
about
opportunistic
use
of
use
of
DNS
packets,
discovered
opportunistically.
T
So
the
thing
that
excites
me
about,
though,
is
not
so
much
that
you
can
deliver
DNS
traffic
over
HTTPS
by
choosing
your
own
preferred
HTTP
over
identity
over
HTTP
endpoint,
but
that
maybe
we
could
get
some
DNS
packets
delivered
when
we
weren't
otherwise
expecting
them
and
there's
some
opportunities
there.
So
can
next
slide
please.
So
currently
we
have
a
whole
bunch
of
different
mechanisms
here.
Right
that
you
can.
You
can
just
blindly
accept
that
your
network
is
giving
you
good
DNS
resolver.
You
can
pre
configure
a
standard
resolver
which
is
not
very
privacy-preserving.
T
You
can
pre
configure
your
DNS
over
TLS
resolver
or
you
can
pre
configure
your
DNS
over
HTTP
resolver.
Those
last
two
are
privacy-preserving,
but
the
common
factors
there
are
either
I
trust
my
network
and
hope
that
it's
not
spying
on
what
I'm,
querying
or
I
trust.
My
my
my
pre-configured
DNS
resolver
and
so
I
want
to
ask
well
what,
if
what
if
there
was
ways
that
we
could
get
this
stuff
without
having
to
trust
anything
pre-configured.
T
So
next,
please,
because
pre
configuration
is
kind
of
a
pain
and
we
don't
know
how
to
do
that
very
well
and
it
means
getting
the
user
involved
there
you
go
so
the
question
I
want
to
ask
is
like:
would
you
accept
a
DNS
record
from
this
guy
right?
So
somebody
what?
If
somebody
just
offers
you
DNS
records
at
arbitrary
times,
and
maybe
there
are
some
circumstances
where?
Actually
it
might
be
okay
to
use
a
record
from
this
guy
right
this
this
this?
T
Then
there's
no
privacy
loss
right.
So
next
slide.
Please!
So
there's
this
idea
of
an
opportunistic
DNS
over
HTTP
that
I
find
personally
exciting
because
I
like
quest
to
a
server
I,
didn't
configure
anything
about
the
server
the
server
says
to
me:
here's
your
HTTP
response
and
then
via
some
sort
of
push
mechanism.
You
know
I
I'm
waving
my
hand,
sir,
because
I
haven't
written
this
down
in
detail.
It
says
by
the
way,
here's
some
other
DNS
records.
T
You
might
like
to
know
and
I
look
at
those
DNS
records
and
I
have
an
option
now
as
a
client
right.
My
option
is:
here's
DNS
records.
I
can
throw
them
on
the
floor
like
I
would
if
they
were
say,
advertisements
because
I
run
a
head,
Locker
or
I
could
bring
them
into
my
cache,
because
I
think
they
might
be
useful
or
I
could
inspect
them
or
I
could
think.
Oh,
maybe
they're
in
a
special
part
of
my
cache
anyway.
I
want
people
to
start
thinking
about.
T
Where
can
you
use
opportunistically
delivered
DNS
records
next
slide,
please
the
reason
I'm
like
I'm
happy
about
this
is
because
you
get
this
privacy
win
where,
where
the
the
client
doesn't
need
to
ask
right,
it's
like
it's
like
the
library
shipped
you
a
box
of
books
for
free
and
you
can
read
any
of
them.
You
like,
and
the
library
doesn't
even
know
which
one
you
wanted
right.
So
your
library
records
art
there's
no
records
in
the
library
of
like
what
records
you
requested.
So
you
get
a
privacy
win.
T
T
Perhaps
we
provide
an
incentive
for
zone
zone
operators
to
assign
their
DNS
SEC
zones,
so
we
might
actually
be
if,
if
this
mechanism
exists
and
clients
are
incentivized
to
use
records
that
are
signed
and
more
likely
to
throw
away
records
that
are
not
signed,
then
maybe
we
actually
provide
a
little
bit
of
an
incentive
to
shift
the
ecosystem
towards
DNS,
X
and
zones.
So
there
are
not
a
lot
of
opportunities
at
the
IETF
to
work
on
projects
that
actually
have
three
wins.
Instead
of
pitting
one
of
these
various
advantages
against
one
another.
T
T
But
if
they're
not
signed
that
I'm
not,
but
maybe
it
depends
on,
if
I'm,
an
HTTP
browser
or
if
I'm,
a
SSH
client
or
something
like
that,
there's
there's
different
risks
for
me
for
using
them,
and
so
I
think
that
this
kind
of
work
I'm
presenting
this
here
at
doe,
because
I
think
this
work
is
sort
of
a
follow-on
from
doe.
But
I.
T
Don't
think
that,
though,
is
the
right
place
to
do
this
work
because
I
think
the
right
place
to
do
this
work
is
going
to
be
in
the
working
groups
that
represent
the
context
that
were
interested
in
so
so,
if
we're
talking
about,
should
an
HTTP
client
choose
to
accept
these
requests,
these
opportunistically
delivery
records,
or
not
that
maybe
belongs
in
the
HTTP,
this
working
group,
or
or
maybe
in
the
what
WG
or
some
potentially
some
other
place.
But
I
want
us
to
think
about
the
opportunities
that
this
that
this
brings.
T
Another
question
that
that,
hopefully,
would
be
asking
there
is
I
mean
I've
got
what
are
the
risks
for
bad
data
up
there
right?
That's
that's
how
you
make
the
decision
about
whether
these
records
are
acceptable
to
be
used
right?
We
don't
want
arbitrary
cache
poisoning
to
just
be
accepted
next
slide.
Please
I
think
you've
got
one
more,
so
I
just
want
people
to
start
thinking
about
different
clients,
so
the
web
browser
is
the
obvious
one.
There
are
other
HTTP
clients,
the
TLS
DNS
SEC
chain
extension
is
an
opportunity
for
any
sort
of
TLS
based
client.
T
That
chain
extension
can
ship
a
bunch
of
records
to
you
again.
They
kind
of
fell
off
the
back
of
the
truck
because
they
came
in
via
the
TLS
handshake
or
maybe
there's
other
users
of
the
DNS
that
might
be
interested,
and
so
my
I'm
here
as
an
inspirational
speaker
to
encourage
you
to
think
about
where
else
in
the
in
the
IETF.
T
You
do
work
that
could
potentially
make
use
of
these
and
think
about
whether
you
want
to
start
to
define
ways
to
accept
these
things
just
but
like
just
because
they
didn't
come
in
off
of
your
pre-configured
thing.
On
port
53
doesn't
mean
that
they're
not
necessarily
about
it,
and
we
have
an
opportunity
to
get
all
of
those
wins
at
once.
So
there's
a
mic
line
forming
already
and
I.
Think
that's
it
for
my
presentation.
My.
AC
Thanks
so
like,
how
do
I
distinguish,
like
maybe
I
trust
responses
from
you
signed
or
not,
but
maybe
I,
don't
trust
responses
from
some
other
XYZ
website
which
I
am
visiting
over
HTTPS
and
is
sending
me
trying
to
poison
poison.
My
my
cache
in
in
some
way
and
like
as
a
user,
maybe
he's
like
I
either
way,
is
a
bad
option.
AC
T
Leave
it
to
the
user
is
we're
back
in
the
pre
configuration
suit
right?
We
have
to
ask
the
user
some
complicated
question
that
they
really
don't
understand
and
that
they
can't
answer
so
I
agree
with
you
that
that
would
be
problematic.
My
question
is:
can
we
think
about
situations
where
you
might
as
well
try
these
try
these
packets
anyway
right?
Well,
you
might.
T
Data
anyway
and
I
agree
with
you
that
cache
poisoning
is
a
real
risk,
so
I
don't
want
to
encourage
just
promiscuous
use
of
optically
delivered
DNS
traffic.
But
if
you
know
that
you're
going
to
as
an
example,
your
an
HTTP
client,
you
get
an
opportunity
delivered
DNS
sex
signed
record,
so
you
can
tell
that
it
actually
comes
from
the
correct
zone,
and
you
know
that
you're
only
going
to
visit
that
site
over
HTTPS,
so
you're
going
to
validate
that.
T
Whoever
has
the
control
of
that
site
has
a
peek
exert
in
the
first
place,
then
why
do
you
care
where
you
got
the
record
from
like
there's
a
situation
where
you've
got
this
validation
over
here
and
you've
got
this
other
validation
over
here
and
the
path
by
which
the
record
was
delivered
to
you
doesn't
maybe
doesn't
matter
now?
Maybe
we
can.
Maybe
we
can
shave
off
one
of
those
constraints
and
you're
still
okay
with
using
it
or
maybe
we
can't.
T
AD
AD
T
I'm
using
a
web
browser
and
I
visit
a
visit
example,
calm
and
example.com
says:
I
would
like
you
to
fetch
a
sub
resource,
from
example
dotnet
and
by
the
way,
here's
the
IP
addresses,
for
example,
dotnet,
okay,
and
maybe
Leslie-
did
that
for
now
right
so
now,
I
don't
need
to
do
another.
Dns,
lookup,
gotcha,
right,
okay,
I!
Don't
need
to
have
anything
pre-configured
I!
Don't
need
to
talk
to
my
local
network.
I
can
just
I've
got
an
IP
address
and
I
know
it's
going
to
be
an
HTTP
sub
resource,
so
maybe
I'll
just
go.
T
W
Hi,
my
name
is
Sandra
Sullivan
I
think
this
is
an
incredibly
good
back
to
the
future'
moment
because,
of
course,
in
the
old
days
before
I
could
spell
IETF
the
DNS.
Just
just
did
this
for
you
right
it
would
it
have
data
and
then
he
kind
of
stuff
it
into
the
additional
section.
Hey
here's
the
thing
that
I
know
you
might
as
well
take
this
too,
and
we
learned
I
think
pretty
early
that
that
was
called
poison.
It
was
game.
W
W
The
point
at
which
the
camo
from
DNS
off
the
other
day
has
has,
you
know,
collapsed
and
entered
the
tent
and
every
other
camel
analogy
that
you
can
think
of,
because
because
really
what
you're
talking
about
now
is
a
new
kind
of
protocol,
a
new
naming
protocol
and
identify
a
thing
that
has
the
properties
necessary
in
order
to
do
this
and
and
and
grafting.
You
know
we
figured
out
okay,
we're
gonna
shove
DNS
into
this
HTP
thing,
and
now
we're
gonna
make
it
do
a
bunch
of
extra
DNS
stuff
in
the
backend.
T
A
brief
response
on
that,
so
so
in
the
example
that
I
just
gave
to
Dan's
question
I,
don't
think
we
need
any
other
machinery
beyond
What's
in
DNS
and
dough
today
to
do
that.
No
no
there's
a
there.
We
have.
We
have
a
specified
DNS
chain,
query
that
says
how
you
say
and
I
would
like
the
chain
with
with
the
response.
Ric
like
those
pieces
are
there
now?
Maybe
the
camel
is
staggering
under
them,
but
the
pieces
are
there.
N
T
D
Patrick,
if
I
can
just
also
address
there's
also
besides,
you
know
the
HTTP
mechanism,
where
you
also
in
order
to
do
this
type
of
pushing
down
data,
you
would
have
to
associate
a
question
with
the
data,
but
mostly
if
we're
looking
at
a
doe
server
as
a
resolver.
This
is
already
something
you're.
Trusting
your
resolver
to
do
on
your
behalf,
you're
trusting
that
you're
going
to
ask
the
same
source
that
you
just
asked,
for
example,
comm
that
it's
going
to
give
you
an
answer,
for
example,
that
net
as
well.
N
So,
thank
you
for
this
presentation.
So
I
call
this
concept
still
looking
for
a
pithy
name,
I
call
this
out-of-band,
DNS
or
out
of
and
naming
and
yeah
for
the
non
HTTP
nerds
in
the
room.
Acb
actually
has
a
few
mechanisms
that
do
request
routing
in
ways
that
you
might
think
we're
traditionally
reserved
for
the
DNS,
but
HTTP
defines
for
itself,
and
those
definitions
tend
to
be
restricted
to
the
origins
that
produce
them
or
the
connections
you've
already
a
step
stripe.
So
we
have
origin
frame.
We
have
alternate
services.
N
We
have
some
coalescing
rules
in
7540
that
do
things
to
your
routing,
if
you
think
you
know
that
an
HTP
client
always
results
the
DNS
name
and
connects
to
the
the
IP
address
that
pops
out
of
that
chain.
That's
not
like
always
what
happens,
and
this
is
a
in
many
ways.
A
natural
extension
and
I
think.
The
use
case
that
you've
drawn
up
here
is
actually
something
they
should
be.
N
That
should
take
a
look
at
right
because
it
is
about
how
HTTP
decides
where
to
get
its
information
and
I
think
is
super
powerful
for
the
reasons
you
illustrate
people.
For
me
to
kind
of
talk
about
this
in
the
past,
going
back
I
think
to
when
we
were
in
Seoul,
it's
clearly
out
of
scope
for
for
this
working
group
and
I.
N
Don't
think
this
working
group
would
be
right,
even
if
it
wasn't
out
of
scope
for
us
I
think
in
an
HTTP
context,
it's
an
HTTP
decision,
but
I've
been
planning
to
work
on
this
and
now
collaborate
with
with
TKG
going
forward,
so
I
would
love
to
hear
from
other
people
that
are
interested
in
that
you
know
the
timeline
we're
talking
about.
Was
you
know
something
quote
unquote
something
in
Montreal.
Now
that
something
could
be
a
bomb,
it
could
be
a
bar
buff.
It
could
be
a
ranch
at
a
plenary
microphone.
N
You
know
we'll
we'll
see
what
we'll
see
what
form
that
really
takes.
But
you
know,
if
you
want
to
be
part
of
that
process,
please
reach
out
and
then,
because
you
know
I'm
already,
grandstanding
I
will
say
the
two
major
technical
topics
I
look
at
when
I
look
at
this
other
than
the
fact
that
it
how
it
relates
to
h-2b
routing
our
first
kind
of
is
how
do
I
know
it's?
N
You
know
safe
to
use
this
address,
and
that
is
some
kind
of
a
signature
in
the
case
of
TLS
we
already
have
some
kind
of
a
signature
and
that
also
secures
the
transport
layer
which
is
in
between
issue
to
be
in
the
addressing
anyhow.
So
that's
like
a
feature
you
really
require,
but
the
second
carrier
stuff
is
trickier
right.
It
is
how
do
I
know
this
is
the
endpoint
that
this
name
would
have
wanted
me
to
use
if
I
had
looked
it
up
for
the
authoritative
for
this
name
right,
that's
harder,
I!
N
AD
David's
canaussie
Apple
I
find
this
cool.
I'm
gonna
make
two
points.
One
is
now
I'm,
gonna
start
with
the
negative
one.
So
first
off
this
is
cool.
I
think
the
really
benefit
would
probably
you
for,
like
a
social
media
site,
we're
kind
of
all
everything
they
post
is
web
sites
like
Reddit
or
something-
and
here
are
a
bunch
of
links-
and
here
are
the
dresses
with
them.
I
could
see
real
value
there
and
saving
the
latency.
If
you
click
on
a
link,
you've
already
pre-loaded
the
DNS.
AD
AD
Let's
take
that
aside
and
I'm
going
to
propose
something
crazy
of
using
this
without
any
signatures
and
hear
me
out
because
these
having
these
signatures
out
green
and
everything,
but
that
kind
of
requires
DNS
sex
support
everywhere,
how
many
recordings
the
clients
that
support
it
and
that
might
take
a
while.
So
how
could
we
do
something
useful
without
DNS
SEC?
And
the
answer
is
happy
eyeballs?
AD
What
you
can
do
is
you
feed
the
addresses
into
an
asynchronous
networking
API,
the
idea
being
once
the
user
clicks
on
that
link
to
example.com
it'll
start
doing
the
one
connection
to
that
IP
address
absolutely
requires.
Tell
us,
okay
and
as
it'll
also
kick
off.
50
NS
queries
to
its
usual
resolver
and,
as
the
addresses
come
in,
it
feeds
those
into
the
list
and
kicks
off
those
TCP
connections
in
those
TLS,
and
you
end
the
happy
eyeballs
once
you
have
one
established,
th
TLS
connection,
and
that
means
you
can
actually
use
this.
AF
Hi,
my
name
is
Shankar,
so
I
like
the
observation
that
well
I
believe
that
we
do
need
DNS,
SEC.
So
I
like
the
observation
that
when
you
have
DNS
SEC,
then
you
can
trust
a
lot
of
stuff
that
you
don't
currently
gain
access
to
sort
of
encrypt.
Oh,
we
trust,
and
actually,
once
once
we
got
DNS
SEC
how
you
got
the
data
all
of
a
sudden
became
irrelevant.
We
don't
need
the
root
server
system.
We
don't
need
the
hierarchy,
we
don't
need
any
of
it.
AF
We
just
need
the
data
all
right,
so
that's
kind
of
cool
I
think
it's
maybe
a
little
bit
optimistic
to
say
that
you
can
actually
trust
it.
Other
people
have
already
pointed
out
things
with
load
balancers
and
actually,
where
the
question
comes
from
may
matter.
Other
things
there
may
also
be
like
all
kinds
of
timing.
Attacks
that
may
be
possible.
I
can
pre-populate
someone's
cache
and
then
I
can
see
that
they're
coming
quicker
than
they
would
otherwise
and
be
able
to
identify
them,
and
things
like
that
so
interesting,
but
I
think
there's
there's
issues.
I.
AF
Statement,
I
guess,
which
is
that
yeah,
maybe
it's
time
to
reconsider,
that
we
just
hit
the
limitations
of
DNS
as
a
protocol
and
now
that
we're
looking
at
carrying
it
over
deep
HTTP,
we
can
all
of
a
sudden
find
out
all
this
freedom
and
all
these
errors
we
can
explore.
So
maybe
that's
what
we
need
to
do
right.
V
Well,
it's
I
see
I,
also
fully
believe
that
DNS
SEC
is
required
for
this
and
I
think
I,
believe
you
know
this
full
well
and
I
know,
but
those
it
wasn't
said
well
at
the
start,
you
can't
just
use
the
RR
sake.
You
got
to
have
the
entire
chain
of
trust.
Yeah
and
Ric
is
not
a
standalone
signature.
You've
got
to
have
the
whole
thing
and
if
you're,
four
or
five
levels
down
I
mean
it's
gotta
have
four
or
five
levels
of
DNS
keys
and
the
rr6
are
all
of
those
the
DSS
records.
V
All
of
those
that
prove
that
there
is
actually
chain
all
the
way
to
the
root
and
they
still
have
that
root
key
as
well
to
be
able
to
trust.
All
of
that,
and
as
far
as
I
know,
the
EGS
chain
option
is
not
yet
standardized
on
its
Delta.
It
is
actually
standing,
I,
think
I
believe
there's
an
RF
Silverthorne
RFC
for
that
right.
V
P
Thank
you
yes,
point:
okay
from
gondwana
I
when
I
joined
the
queue
back
there.
Obviously
conversation
had
gone
a
whole
no
way
down
this
part.
So
it's
a
bit
like
those
flat
threaded
forums
where
it's
hard
to
tell
what
you're
applying
to
poison
we
work
with
poison
all
the
time
chemists
work
with
poison.
All
the
time
you
contain
it
I
see
a
lot
of
cause
for
using
this
data.
For
that
particular
request.
P
I
don't
see
much
value
in
populating
your
local
cache
for
a
longer
term,
you're,
getting
back
in
your
example
a
web
page
that
contains
some
links
that
you
want
to
then
follow
the
DNS
lookups
for
the
only
reason
it
doesn't
contain.
The
IP
addresses
instead
directly
is
SNA.
So
what
you're
doing
here
is
getting
a
hint
that
changes
the
name
to
an
IP
address
on
the
links
that
are
in
the
content
of
the
page
you're,
looking
at
so
long
as
you're
using
this
data.
P
In
that
context,
only
and
not
caching
it
for
other
things,
your
poison
is
contained.
Your
poison
is
only
the
poison
that
you're
already
being
offered,
so
you
don't
need
just
for
apply
to
the
last
cup
of
people.
You
don't
need
all
these
signatures
if
you're
not
sticking
in
your
cache,
because
the
poison
doesn't
poison
anything
else.
P
AG
AG
But
I
also
want
to
new
it
another
use
case
about
this.
That
excites
me
a
little
bit,
so
we
have,
as
Patrick
alluded
to
alterative
all
services
in
HTTP,
and
we
have
a
new
draft
on
how
to
put
out
service
in
DNS,
which
means
now,
when
somebody
serves
you
a
link,
they
can
also
pre-populate
the
information
that
and
the
server
supports,
quick.
Y
Jim
and
I
have
our
own
correctly
sized
mic.
So
who
are
you?
Oh
sorry,
Warren
Kumari,
but
I
do
still
have
a
Jim
behind
me.
So
I
happen
to
think
that
this
is
a
grand
idea.
In
fact,
I
happen
to
think
it's
a
grand
enough
idea
that
waste
and
I
wrote
a
document
about
it
and
DNS
up.
However,
not
everyone
else
thinks
it's
a
particularly
grand
idea.
So
I
think
that
you
know
there
should
be
really
good
coordination
with
DNS
up
to
find
out.
T
So
I
agree
that
this
is
the
sort
of
thing
that
probably
requires
coordination
across
working
group
coordination,
but
I
will
observe
that
the
contextual
framing
that
I
have
here
for
it's
out
that
the
actual
authority
for
this
probably
resides
in
the
contexts
where
it
will
be
used
because
it
doesn't
actually
make
this
idea
doesn't
make
any
claims
about
how
the
DNS
itself
should
operate.
It
says
how
would
you
use
DNS
if
you
got
it
in
context,
X
or
context?
Why.
AA
Jim,
eat
Dino
lots
of
X
idea,
but
one
of
your
focus
on
potential
denial
of
service
attacks
that
this
would
expose
the
end
user
to,
for
example,
the
farmer
by
the
actor
as
the
server
I
could
be
sending
stuff
down
to
the
client
saying
validate
their
stuff
and
the
validation
just
gets
out
of
control
and
just
keep
punting
out.
What's
lots
of
convictive
DNS
data,
which
you
think
the
client
may
interest
and
then
what
all
you
really
do?
You
speak
in
life,
difficult
for
the
client
and
make
him
do
all
that
validation.
T
Totally
agreed
I
had
not
thought
about
that
particular
form
of
denial
service
attack,
but
like
anything
where
the
server
can
ask
you
to
do,
work,
I
would
hope
that
clients
would
implement
their
own
rate,
limiting
and
actually
yeah
Tello
servers
that
you
know
I'm
done
with
these
or
just
ignore
them
once
it
fit.
Obviously,
too
much.
AC
I
haven't
thought
this
through
completely,
but
I
wonder
like
what
happens
with
phishing.
Of
course
you
can
still
do
phishing
detection
on
the
client
side,
but
now
I
visit
some
website
and,
like
I,
already
have
the
address
of
all
the
fishing
websites
and
I.
Don't
even
have
to
look
them
up
anymore,
so
and,
and
they
are
still
signed,
you
can
still
register
them,
get
searched.
So
it's
and
everything
so
does
it
make
it
harder.
Somehow
that
will
be
something
to
look
at
at
least
so.
AC
T
Mean
I
haven't
directly
implemented
this,
so
I
haven't
put
the
kind
of
thought
that
I
think
is
warranted
into
implementation,
but
I
I
don't
do
the
implementation.
Is
the
real
cost?
I
think
that
the
additional
costs
are
the
issues
that
people
have
been
raising
here,
which
I'm
grateful
for,
in
particular
about
the
consequences
to
anti-phishing
mechanisms
that
rely
on
clear
text
DNS
and
the
cost
to
people
who
rely
on
the
DNS
for
load,
balancing
I
think
those
are
probably
the
biggest
concerns
may
be
that
that
Mister
drives
I.
Don't
actually
think
that
implementation
was.
AC
T
But
it's
not
clear
to
me
that
we
have
a
clear
model
of
what
that
separation
is
like
what
what
properties
it's
supposed
to
have
and
what
we
think
the
security
efficiency.
What
what
we
think
the
trade-offs
are
involved
in
that
so
I
would,
if
you're
someone
who
believes
that
that
separation
is
particularly
critically
important.
AB
Both
this
working
group
of
things
going
on
in
DNS,
often
and
it
should
be
based
in
between
and
if
we're
DNS
SEC
versus
P
kicks,
is
going
and
we're
all
service
versus
connection
coalescing
versus
this
discussion
versus
a
few
others
like
we're
quickly
seem
to
be
getting
point
where,
like
the
cable
standing
on
its
own
back-
and
it's
just
may
not
have
strong
yet
going
through
some
multi-dimensional
space
he's
like.
Is
there
a
point
at
which
the
we
need
to
start?
AB
Looking
at
this
kind
of
outside,
like
wondering
whether
they
working
group
boundaries
is
starting
to
become
a
problem
here,
we
need
to
take
a
step
back
and
say
architectural
II,
independent
of
kind
of
how
the
working
group
breakouts
are
going
on
for
this.
Where
do
we
want
to
go
to
on
this?
What
is
kind
of
our
operational
model
security
model?
AB
How
everything
ties
together
model
for
this,
so
that
we
have
something
that
people
come
understand
rather
than
this
really
complex
pile
of
all
these
different
things
could
happen,
which
is
going
to
be
really
fun
for
all
the
people
who
want
to
take
advantage
and
exploit
it,
because
then
we
lobster
I'm
sure
that
we
lots
of
bugs
in
there
and
whatever
gets
implemented.
I
was.
T
U
All
over
Amazon
so
dad
you
have
had
a
few
metaphors
thrown
at
you
here,
so
we
could
say
that
your
work,
if
we
say
you're
working
on
this
on
reliability
or
expediency,
your
you
have
to
deal
with
the
poisoned,
happy
I,
Paul,
but
but
the
the
thing
is
that
using
this
we
might
even
be
able
to
speed
up
development
for
the
applications,
because
the
traffic
can
be
posted
on
this.
So
yes,
I
think
this
is
interesting.
So
I'm
gonna
ask
the
room
a
question.
Instead
of
you,
anybody
willing
to
help
work
on
implementation.
U
L
Suzanne
again
is
myself
still
with
Janet
sobs
had
flung
into
the
corner,
but
if
you're
going
to
pursue
this
person
on
the
conversation
in
the
chat
and
at
the
microphone,
it
might
be
easier
if
you
concede
at
the
beginning
that
you're
not
really
talking
about
DNS.
This
is
context
sensitive
and
those
other
things
with
identifiers
in
ways
that
data
is
just
doesn't.
So
if
you
come
up
with
something
else
to
call
it
early,
it
might
be
easier
to
talk
about
it.
D
I'm
gonna
jump
right
in
from
the
mark,
just
to
observe
also
that
there
has
been
an
ongoing
effort
for
identifying
the
different
ways
we
use
names
on
the
internet,
to
identify
endpoints
and
how
to
connect
to
them,
and
so
there's
a
some
cross-pollination
that
goes
on
there.
That
if
we're
not
talking
about
the
DNS,
you
know
what
type
of
identifier
are
we
talking
about
and
and
the
connections
they're
from.
L
T
I
mean
there's
been
a
several
comments
saying
maybe
this
shouldn't
be
DNS
but
I
have
to
say
there's
a
lot
of
nice
stuff
in
DNS
and
it's
really
tempting
to
just
take
advantage
of
it.
So
I
mean
we're
talking
about
I'm
talking
about
piggybacking.
You
guys
talking
about
straw
on
the
camel's
back.
It
is
definitely
like.
H
Mark
Nottingham
it's
Thursday
afternoon,
so
I'm
hitting
my
IGF
week,
exhaustion
limit,
but
just
to
amplify
what
patrick
said
you
know
this
has
been
discussed
in
the
HP
working
group
on
and
off
for
a
long
time
ever
since
htv-2
has
started.
This
was
kind
of
a
back
thread
where
we
knew
this
was
an
area
we'd
want
to
explore
it
just
not
yet
not
yet
not.
Yet
it's
from
the
interesting
thing
to
me
was
the
hands
that
were
raised
in
the
room
when
you
were
asking
about
or
what
I
was
asked
about.
H
Input
and
interest
I
mean
if
you
want
to
ask
for
time
in
Montreal,
if
you're
come
to
Montreal
I
think
that's
entirely
justifiable.
I'd
encourage
to
do
a
barb
off
and
have
a
side
conversation,
and
you
know
that's,
let's
start
talking
yeah
well,
if
it's
in
the
age
to
be
working
group,
you
don't
need
a
buff
ball
for
that
plus.
A
A
Those
of
you
who
are
familiar
with
the
DNS
know
that
we
have
a
DNS
terminology
document
which
actually
is
now
trying
to
describe
the
Public
DNS,
that's
still
open
and
will
be
open
for
a
little
bit,
not
for
very
long
I
think
you
are
doing
the
DNS
here,
because
you're
using
if
assuming
that
you
are
using
the
reason
you're
here,
Indo
is
it
this
might
be
done
over
doe
that
uses
the
10s
wire
format.
It
uses
all
of
our
naming
and
you
might
stuff
this
into
a
local
DNS
cache
in
the
web.
That's
the
whole.
A
The
reason
why
you're
getting
these
records
is
not
so
you
can
use
them
immediately
and
then
forget
it,
because
there
isn't
any
immediately.
You
might
actually
cache
them,
so
you
might
cache
them
in
a
way
that
is
appropriate
for
a
DNS
cache,
golly
gosh,
there's
a
TTL
in
there.
You
might
follow
the
teacher.
This
sounds
a
lot
like
DNS
modulo,
no
port
53,
and
so
you
might
want
to
call
it
DNS,
plus
something
we
called
this
DNS
over
HTTP.
A
R
H
So
Paul
just
said
something
that
makes
me
want
to
take
the
big
circuit
breaker
and
switch
the
working
group
back
on
for
a
second.
You
said
that
Doe
could
could
populate
the
local
DNS
cache.
Is
that
in
scope
for
this
work,
because
that
that
seems
we
had
discussions
around
that
and
I
thought.
The
conclusion
of
that
was
no
that's
out
of
scope
for
our
use
cases.
I.
A
Don't
see
it
out
of
scope
for
the
use
cases,
I,
don't
think
it's
in
scope
either.
It
is
something
you
might
do
so
doe
according
to
the
Charter
and
to
the
document
lets
you
send
a
query
and
get
a
response.
It
doesn't
say
what
you
do
with
that
response,
and
so
there's
many
things
you
can
do
just
in
the
same
way
ignore
doe
for
a
second.
You
are
something
that
can
connect
over
port
53.
H
Okay,
so
there's
a
difference
between
I
want
to
use
dough
for
my
web
browser
and
I
want
to
use
dough
for
my
local
resolver
natively.
You
know
implements
dough
to
you
random
piece
of
software,
somehow
populates
the
DNS
cache
of
without
the
knowledge
of
the
DNS
resolver
with
dough.
That's
weird,
yes,
that.
L
T
I
think
that
we
need
to
think
about
this
specifically
in
terms
of
the
contexts
in
which
it
will
be
used,
in
which
case
caching
is
in
scope.
If
we're
saying
we're,
gonna
populate
a
random
DNS
cache
that
might
be
used
by
arbitrary
other
things,
I
think
that's
crazy
town
and
that's
where
the
poisons
dangerous
right.
N
This
isn't
what
the
reference
mark
was
worried
about,
wasn't
crazy
town.
It
was
the
recursive
resolver
case
where
you
are
obviously
trusting.
Your
recursive
resolver
in
the
application
may
cache
that
data
and
it
may
use
those
TTLs.
You
know
in
that
data
for
the
applications
own
purposes,
and
that
was
the
extent
of
the
scope
thing.