►
From YouTube: IETF-ADD-20220126-1700
Description
ADD meeting session at IETF
2022/01/26 1700
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
And
how
many
we
have
51
participants,
okay
and
we've
got
the
very
chairs-
are
here-
looks
like
it
and
we've
got
ben
is
gonna,
be
our
one
set
of
slides
for
today.
So
let's
get
started
welcome.
This
is
a
joint
intern
meeting
between
80d,
dsl
and
deep,
be
aware.
This
is
this
is
and
then
I
gotta
change
this
slide
here.
A
A
C
A
The
agenda?
Oh
perfect,
that
was
the
goal.
I'm
glad
I'm
glad
I
achieved
it.
Let
me
bring
it
over
here,
so
welcome.
I'm
glendi,
I'm
one
of
the
co-chairs
of
add,
along
with
david
lawrence.
This
is
joint
server.
Also,
we
also
have
the
chairs
of
dns
op
and
gprive
and
I'll
give
everybody
a
chance
to
speak
in
a
minute
along
with
our
error
directories.
Warren
kumar,
who
I
see
I
misspelled
warren's
name,
my
apologies
to
warren
and
eric
the
goal
today.
A
D
A
A
Thank
you.
Thank
you
very
much.
Okay,
so
the
agenda's
been
posted
for
about
a
week.
Do
we
have
any
bashes
for
the
agenda
things
that
people
want
to
add
or
remove?
This
is
the
first
part
the
reading
about
the
background
on
this
discovery.
The
topic,
then
we're
going
to
break
into
a
discussion
with
initial
presentation
by
ben
schwartz,
talking
about
a
proposed
approach
on
a
few
of
the
issues
around
the
split
dns
and
discovery
for
it.
A
This
is
a
a
presentation,
light
discussion,
heavy
session,
so
it
is
going
to
be
essentially
focused
around
the
mic
line
and
the
topics
we
we
put
up
here
are
going
to
be
to
prompt
you
to
have
conversations
around
these
topics.
If
there's
additional
topics
feel
free
to
bring
them
to
the
mic
line.
This
is
a
open
discussion
for
us
to
move
forward
on
the
on
the
the
mind,
thinking
here,
the
consensus
building.
A
C
C
C
This
is
one
of
these
topics
that
didn't
split
so
yeah
we're
looking
forward
for
the
participation
of
between
the
talk
participants
or
the
participant
members
or
sorry
dinosaur,
members
and
yeah
give
their
perspective
and
their
clue
on
the
topic
being
discussed
today.
That's
it
from
the
dinosaur
series.
D
Yep,
that's
me.
I
was
actually
going
to
add
to
that.
The
discussion
around
split
dns
is
kind
of
it's
definitely
more
of
a
dns.
You
know
it's
a
topic,
that's
near
and
dear
to
a
lot
of
the
dns
folks
and-
and
I
think
some
of
the
stuff
that's
going
on,
especially
with
what
you're,
using
to
try
to
key
on
things
or
or
flag,
things
definitely
sort
of
falls,
there's
definitely
some
deprived
pieces
here
or
or
they
could
over
they
they
do
seem
to
overlap.
D
E
Forget
yeah
so,
basically
very
short,
glenn.
So
first
thank
you
for
all
the
chairs
to
come
together
and
all
the
participants
of
the
working
group.
It
really
means
to
believe
that
we
may
need
to
see
whether
a
dns
directory
could
be
useful
at
some
point
of
time
to
gather
the
interest
and
the
other
part
is
more.
Like
a
logistic
warren
told
me
he
will
be
late
by
15
20
minutes.
So
don't
expect
him
into
the
beginning
of
the
meeting
and
let's
do
have
a
nice
meeting.
B
A
A
Let
me
introduce
a
little
bit
about
the
background
for
this,
and-
and
this
is
largely
for
maybe
people
that
haven't
followed
the
the
add
list
very
closely,
so
adb
has
been
working
on
the
discovery
mechanisms
for
encrypted
dns
servers,
whether
they
be
do
or
dot,
and
we've
got
a
couple
of
mechanisms.
Now
that
are
one
is
really
well
suited
for
the
open
internet
and
it's
uses
the
the
records
and
publish
the
url
within
the
dns.
A
I
encourage
people
to
go,
read
that
draft
and
then
they're
linked
here
at
the
bottom.
The
draft
number
one
and
two
discovery
designated
resolvers
and
then
dhcp
and
runner
advertisement.
So
this
the
dnr
is
an
approach
for
how
you
do
it
in
in
environments,
whether
you're,
either
using
ghcp
or
weather
advertising,
and
their
documents
are
fairly
mature
along
along
the
way
we
in
the
discussions
of
the
group,
came
hit
a
bit
of
a
bottle
or
not
bottleneck
a
bit
of
a
wall.
A
We
as
a
group
have
decided
that
the
problem
of
doing
discovery
in
split
dns
environments
is
important.
Oh
it's
an
important
one
to
solve.
One
of
the
worries,
of
course,
is
that
if
we
do
nothing
in
that
environment,
knowing
that
the
environments
of
themselves
very
prevalent
in
operational
spaces
in
enterprises,
organizations
all
many
other
places.
A
If
we
do
nothing,
then
ultimately
that
community
will
figure
out
how
to
do
their
own
discovery.
Mechanisms
and
there'll
be
a
bunch
of
ad-hoc
ones,
not
standards-based,
and
once
you
get
that
genie
out
of
the
bottle,
it's
very
hard
to
put
it
back
in
and
come
up
with
a
discovery
mechanism
that
is
standards-based,
and
so
the
group
has
said
it's
important
as
a
use
case
to
solve.
A
But
we
had
a
document
which
came
up
pretty
well
written,
very
mature
document
as
well,
but
that
which
failed
to
get
adoption
through
a
consensus.
The
consensus
call
for
working
group
adoption
I'll
note.
However,
the
group
didn't
reject
that
documents,
approach
and
hasn't
said
this
is
a
terrible
document.
A
There
is
even
discussion
about
the
potential
role
and
use
of
dns
sec
in
some
of
this
problem
space,
and
so
we
realized
there
was
a
bunch
of
these
topics
which
were
very
much
out
of
scope
of
add,
which
was
only
focused
on
the
discovery
question
you
know,
how
do
you
do
discovery?
These
other
topics
were
beyond
us,
and
so
this
is
sort
of
the
the
genesis
of
this
discussion
of
well.
What
is
the
indigenous
environment?
A
Okay,
so
hopefully
that
sort
of
tease
us
up
for
the
conversations
come
forward.
Moving
on
so
acknowledging
that
split
dns
is
widely
deployed.
We're
not
here
to
discuss
how
to
get
rid
of
that
environment.
We're
not
here
to
do
a
referendum
on
the
practice.
Some
people
hate
it.
A
lot
of
people
love
it
a
lot
of
people
hate
it
too,
but
accepting
that
it's
there
and
if
we
do
nothing.
This
is
a
genie
that
we'll
get
out
of
the
bottle
on
how
to
do
discovery.
A
F
F
F
There
are
a
lot
of
different
ways
to
define
this
I'll.
Just
give
you
the
the
one
that
works
best
for
me,
which
is
that
the
network
provided
resolver
gives
you
answers
that
are
meaningfully
different
from
the
answers
you
would
get
if
you
just
went
and
asked
any
other
general-purpose
resolver
meaningfully
different
is
not
an
objectively
defined
phrase,
and
so
it's
not
always
clear
whether
you're
doing
split
horizon
dna.
F
F
People
do
this
to
have
a
domain
that
exists
on
both
sides
of
the
network,
but
behaves
differently
depending
on
you
know,
resolves
to
a
different
version
of
that
domain,
or
sometimes
it's
just
an
optimization,
but
it's
a
very
a
very
pointed,
optimization,
like
putting
a
high
traffic
server
physically
inside
the
network
and
making
sure
that
that's
the
result
you
get.
If
you
try
to
resolve
the
domain
from
inside
that
network,
so
this
is
used
in
many
different
kinds
of
networks.
F
F
Let's
also
talk
about
dns
hijacking,
which
is
kind
of
the
the
dark
side
of
split
horizon
dns.
So
dns
hijacking
here,
we're
saying,
is
answering
queries
for
a
name
when
you
do
not
have
authorization
to
do
so
from
the
zone
and
again
authorization
here
is
not
meant
to
be
a
technical
term.
This
is
a
human
term,
and
so
whether
something
is
dns
hijacking
might
depend
on
the
social
nature
of
your
relationship
with.
G
F
So
the
obvious
example
here
is
answering
for
a
domain
that
exists
when
you
don't
have
permission
from
the
zone
that
contains
that
domain
legitimately,
but
there
are
also
interesting
variations
on
this.
One
of
them
is
nx
domain
hijacking.
So
that's
in
injecting
an
answer
for
a
domain
that
would
be
nx
domain
if
you
actually
resolved
it
to
the
to
the
authoritative
owner
and
a
version
of
that
is
inventing
new
fake
top-level
domains
that
don't
actually
exist.
F
F
One
of
those
is
the
nature
of
trust
relationships,
because
sometimes
devices
are
connected
to
networks
and
they're
managed
by
different
entities
that
don't
have
a
high
degree
of
mutual
trust.
When
that
happens,
each
of
those
parties
is
going
to
have
its
own
policies
that
it's
going
to
apply
to
the
systems
that
it
controls.
F
H
Hi
ben,
I
I
I
wanna.
I
think
this
is
a
very
important
slide
and
very
important
thing,
and
I
think
that
one
of
the
the
things
often
is
that
people
think
that
they
have
compatible
security
assumptions
because
actually
their
terminology
is
is
overloaded
and
incompatible.
So
they
both
think
they
have
a
banana.
F
So
how
do
we
make
progress?
In
my
view?
The
way
we
can
make
progress
here
is
by
looking
for
situations
that
are
technically
interesting,
so
we
can
think
about
the
effects
of
different
policies.
We
can
look
for
combinations
of
policies
that
might
exist
and
then,
when
those
policies
happen
to
apply,
then
there's
a
technically
interesting
problem
to
solve.
So,
for
example,
if
the
client
is
always
going
to
use
the
networks
resolver,
then
it's
always
going
to
see
split
horizon
names.
F
If
the
client
never
uses
the
networks
resolver,
it's
never
going
to
see
those
names.
These
are
boring
cases
there's
just
not
much
technically
interesting
to
do
in
either
of
these
cases.
In
my
opinion,
although
I'm
you
know
after
the
the
slides,
we
can
certainly
talk
about
talk
about
that
if
people
disagree,
but
I
think
there
might
be
an
interesting
technical
case
for
clients
that
sometimes
use
the
network
provided
resolve.
B
F
F
So
we
have
these
different
building
blocks.
Things
like
asking
a
dns
question,
providing
an
answer,
sending
a
query
or
an
answer
over
a
response
over
the
network,
accepting
a
a
query
over
the
network
and
parsing
out
the
question
taking
a
question
serializing
it
into
a
query
sending
that
over
the
network
and
then
the
very
complicated
business
of
iterative
resolution
with
multiple
network
paths.
So
let
me
this
will
become
clearer
on
the
next
couple
of
slides.
F
That
is
what
we
call
a
dns
forwarder
if
we
accept
queries
over
the
network
and
then
turn
those
into
questions
and
then
perform
iterative
resolution
to
resolve
the
answers
to
those
questions
that
together
is
called
a
recursive
resolver.
If
we
just
answer
them
locally,
that's
an
authoritative
server.
This
is
my
my
mental
map
of
dns
functionality.
F
Why?
Why
am
I
giving
you
these
building
blocks?
Because
I
want
to
introduce
a
new
one,
the
idea
of
a
question
dispatcher-
or
you
can
think
about
this
as
a
question
policy
that
takes
in
a
question
a
dns
question
and
potentially
does
something
different
with
it.
According
to
some,
local
policy
has
at
least
two
different
behaviors
that
it
might
apply,
and
so
I
submit
to
you
that
hybrid
resolvers
are
actually
everywhere.
F
Almost
all
of
the
things
that
we
call
stub,
resolvers
or
recursive
resolvers,
or
at
least
a
large
fraction
of
them,
are
actually
a
little
more
complicated,
they're,
actually
hybrid
resolvers.
Here's
some
familiar
examples.
If
you
have
a
posix
style,
stub
resolver
that
sometimes
answers
dns
questions
directly
out
of
etsy
hosts
without
ever
serializing
a
query,
but
sometimes
it
actually
most
of
the
time
it
forwards
that
the
queries
to
to
some
upstream
resolver.
F
I
submit
that
this
is
a
hybrid
resolver.
It's
not
strictly
a
stub,
because
sometimes
it
answers
the
question
locally,
and
I've
sometimes
heard
the
term
authoritative
resolver
to
describe
this
if
you're
running
a
dns
server.
So
it
accepts
an
incoming
query
over
the
network
and
maybe
it
answers
it
locally
out
of
a
zone
file,
or
maybe
it
actually
performs
iterative
resolution
and
asks
other
authoritative
servers
again.
I
would
say
that
this
is
a
hybrid
resolution
behavior.
F
So,
with
these
concepts
we
can
now
put
together,
I
think
a
clearer
definition
of
what
the
interesting
case
is
here,
and
that
is
the
case
where
both
the
client
and
the
network
provided
resolver
are
actually
hybrid
resolvers.
So
network
has
to
be
a
hybrid
resolver,
because
otherwise
it's
not
doing
split
dns.
It's
essentially
a
hybrid
network
resolver
that
sometimes
serves
answers
locally,
like
out
of
a
zone
file.
F
To
me,
that's
sort
of
the
definition
of
split
horizon
dns
and,
as
I
mentioned
earlier,
for
this
to
be
for
there
to
be
something
interesting
to
talk
about
here.
I
think
that
we
need
to
talk
about
clients
that
sometimes
run
their
queries
through
the
network
resolver
and
sometimes
are
able
to
answer
query
some
other
way,
maybe
by
another
remote
answer,
behavior,
that
forwards
queries
to
a
different
upstream
resolver
or
maybe
even
local
iterative
resolution.
F
F
So
the
easy
part
of
just
conveying
those
names,
we
actually
have
a
lot
of
good
tools
for
this
already
provisioning
domains
defines
an
extension
for
this
to
be
clear.
Provisioning
domains
doesn't
authenticate
the
contents
of
this
in
any
in
any
way
what
they,
what
provisioning
domains
does
offer
is
identification
of
the
source
of
the
provisioning
domain
claim.
F
F
There's
a
standard
for
split
dns
configuration
for
ikev2,
that's
vpn
configuration
and
the
nice
thing
about
vpn
configuration
is
that
there
is
actually
usually
a
pretty
close
relationship
between
the
client
and
the
tunnel
operator.
There's
a
usually
not
intrinsically
a
certain
amount
of
trust
there
that,
and
so
this.
This
draft
actually
allows
a
lot
of
affords
a
lot
of
power
to
the
to
the
tunnel
operator.
F
It
even
lets
them
override
dns
trust
anchors
for
the
client,
but
it
also
assumes
that
there's
a
certain
amount
of
user
confirmation,
some
sort
of
not
very
clearly
specified
white
list,
but
so
that's
that's.
The
state
of
the
art
for
vpn,
split
dns
and
finally,
even
the
old
dhcp
search
option
is
actually
very
close
to
what
pvd
offers
you
know.
Really.
This
is
just
a
the
problem
of
distributing
a
list
of
domain
names
to
clients
on
the
network.
F
Is
is
not
that
hard
to
solve
and
it
maybe
is
already
solved,
but
the
hard
part
is
how
to
confirm
authorization
of
those
names.
So
what
would
the
client
need
to
confirm
that
that
local
resolver
is
authorized
to
serve
a
given
dns
zone?
So
here's
my
my
personal
view
of
what
it
would
take.
The
client
needs
an
identity
for
the
local
resolver
and
normally
in
classic
dns
configuration.
F
F
And
finally,
we
would
need
a
secure
transport
to
that
resolver
so
that
we
actually
know
that
we're
talking
to
the
entity
that
was
authorized
by
that
assertion
in
classic
dns.
We
didn't
have
any
of
these
four
things,
and
so
it
was
kind
of
a
lost
cause
to
to
try
to
do
authorized,
split,
dns
or
maybe
we
could
call
it
authenticated,
split
dns,
where
the
client
actually
confirms
that
authorization.
F
F
So
I
hope
that
gives
you
a
tour
of
what
some
of
the
ideas
that
we've
been
batting
around
about
how
to
deal
with
split
horizon
dns.
Mostly.
I
want
to
emphasize
that
there
are
some
new
opportunities
here,
because
dns
security
is
changing
and
improving.
We
have
new
opportunities
to
improve
the
security
of
split
horizon
dns,
but
we
do
have
to
focus
on
use
cases
where
a
solution
is
actually
possible
and
we're
not
going
to
be
able
to
solve
this
problem
in
a
way
that
works
for
every
network
and
every
client.
F
A
You
one
comment
before
we
open:
the
mic
line
is
the
draft
that
was
in
add
we
sort
of
structured
this
session,
not
to
be
a
major
discussion
on
that
draft.
It
has
ideas
which
ben
has
presented.
That's
pretty
laid
up,
so
the
request
is
that
let's
focus
on
the
ideas
and
not
debate
the
draft
itself,
the
draft
will
be
covered
at
itf
113
during
the
agd
session.
So
let's
stick
to
the
ideas
versus
the
particulars
of
that
particular
match.
A
I
I
I
F
Sure
so
the
chair
should
tell
me
when,
when
this
section
is
done-
and
I
should
stop
answering
trying
to
answer
all
the
questions
that
come
in
but
I'll
tell
you
tommy
I'll,
tell
you
my
my
perspective,
which
is,
if
your
name
doesn't
exist
in
the
global
dns
and
so
can't
be
delegated
to
you
in
any
secure
fashion.
Then
you
are
doing
dns
hijacking.
G
F
So
I
think
that
this
topic
of
of
how
to
handle
how
to
handle
split
horizon
with
dns
hijacking
is
absolutely
in
scope
for
us.
We
should
think
about
how
we
want
to
handle
it
and
respond
to
it.
But
my
personal
answer
to
that
is
that
I
think
we
should
respond
to
it
by
making
clear
that
it's
not
something
we
can
support.
Really
it's
not
compatible
with
a
global
dns,
and
what
we
can
do
is
is
essentially
guide
people
toward
architectures
that
are
more
supportable
and
sustainable.
B
B
Well,
I
think,
for
as
long
as
people
are
addressing
things
that
have
come
up
in
your
proposal.
I
think
it's
great
or
your
framework
here.
That's
not
really
the
right
word,
but
I
hope
you
understand
what
I'm
trying
to
say
that
that
this
is
still
a
useful,
that
this
is
facilitating,
useful
discussion
to
have
you,
okay,
addressing
just
what
you
brought
up
and
if
tommy,
if
you
were
done
or
no,
I
I
was
just
gonna
respond.
I
Quickly
to
ben
okay,
as
far
as
you
know,
when
we're
talking
about
the
things
that
are
easy
or
possible
to
solve,
I
I'm
skeptical
that
we'd
just
be
able
to
tell
people.
Oh
yeah,
you
know,
hijacking
a
name
on
your
local
walled
garden
is
bad.
You
shouldn't
do
it
like
that.
That
will
just
make
them
stop,
and
you
know
in
practice
because,
as
as
we
have
for
products
like
private
relay
tried
to
handle
the
case
where
we're
now
doing
some
encrypted
dns,
that's
not
on
the
local
network.
I
The
case
of
saying
all
right,
I
can't
find
this
name
externally.
I
can
fall
back
to
just
trying
locally,
it's
actually
quite
easy,
and
so
like
we
could
say.
Essentially
you
know,
there's
this
whole
category
of
things
where,
if
you
can't
resolve
it
on
the
public
dns
and
you
can't
get
anything
else,
all
right.
Try
some
local
fallback.
I
If
that's
within
your
policy
that
could
solve
a
huge
swath
of
cases
both
for
cases
where
it's
a
dns
hijacking
or
even
if
you
do
have
permission
for
the
internal
domains,
they're
just
not
publicly
accessible
and
really
what
I
think
remains
as
the
very
tricky
technical
problem.
If
we
think
that
other
solution
is
acceptable
is
dual
facing
resolution,
where
I
have
a
name
that
is
in
the
public
dns
and
also
wants
to
resolve
differently
on
this
one
network
because
of
some
enterprise
policy,
and
that's
the
one
where
we
need
some
extra
assertion.
I
J
Excellent,
so
I
did
reconnect.
So
I'm
sorry.
If
I'm,
I
might
be
saying
something
that
tommy
my
co-author
on
the
split
dns
for
ipv2
has
already
said,
but
I
just
wanted
to
make
sure
we
had
a
lot
of
site
meetings
with
with
the
ad
and
the
tls
working
group,
chairs
and
acker
and
other
people
when
we
did
the
the
ip2
version
and
specifically,
even
in
that
situation,
where
both
the
client
and
the
server
are
authenticated
and
they
have
a
trust
relationship.
J
J
It's
allowed
to
be
overwritten
when
it
talks
to
the
server
people
are
really
afraid
that
having
this
sort
of
blanket
approval
of
like
well,
you
have
a
trust
relationship,
so
you
can
send
us
any
list
of
domains,
including
gmail.com
and
we'll
do
it
was
too
dangerous,
and
I
see
that
so
so
so
yeah.
So
so.
If
you
look
at
that,
there's
no
authentication,
it's
not
really
true.
Your
authentication
was
based
on
provisioning
right,
which
is
authenticated.
C
J
Vpn
case
there
is
no
authentication,
there
is
no
trust
relationship
between
the
network
and
the
client
possibly,
and
that
is
where
the
real
promise.
I
think,
if,
if
there
is
a
trust
relationship
with
the
network,
you
can
do
something
like
what
the
ikv2
rfc
did
with
an
authentication
list
and
you'll
have
to
provision
it.
But
that's
fine
because
there's
a
trust
relationship
to
provision
with.
J
If
you're
talking
about
coffee
shop
networks
and
things
like
that
or
hotels,
then
obviously
there
is
no
trust
relationship
there
and
people
in
general
don't
want
any
domains
to
be
overwritten
and
then
unfortunately,
I
it
becomes
really
like
you
know:
do
you
hide
this
from
the
user?
Or
do
you
let
the
user
make
a
decision
and
either
of
these
decisions
are
going
to
be
working
badly
and
I'm
not.
J
For
this
space,
in
that
sense,
and
just
one
last
one,
the
public
zones
of
something
like
example.com
externally
and
internally,
having
compexample.com
or
just
example.com,
also
internally,
these
are
really
common
scenarios
where
they're,
different
and
a
solution
really
needs
to
support
all
of
them.
If
we're,
if
we're
going
to
limit
that,
based
on
assumptions
that
the
internal
and
the
external
network
have
to
in
some
way,
synchronize,
then
I
think
that
the
solution
will
just
not
work.
F
Yeah,
I
I'll
just
add
that
you
know
we've
had
a
long
mailing
list
throughout
the
addi.
Some
people
here
maybe
aren't
on
the
ad,
though
so
paul,
and
I
have
had
a
long
discussion
on
the
add
list
about
the
question
of
of
cooperation
between
management
of
internal
and
external
name
spaces,
and
what
that
would
require
I'll,
just
know
that
the
you
know
this
also
talks
about
the
need
to
authenticate
the
identity
of
the
network
resolver
right.
So
that's
that's
not
the
only
interesting
technical
problem
that
this
this
brings
up.
F
K
Marino
hats,
so
I
mean
I'm
somewhat
concerned
that
a
lot
of
this
views
much
of
the
dns
sort
of
as
a
spherical
cow
right
like
this,
is
how
the
dns
is
described.
This
is
how
we
think
it
all
works,
and
so
we
can
just
do
these
things
and
there
are
a
lot
of
things
that
are
a
lot
more
messy.
For
example,
dns-64
dns-64
you
have
resolvers,
which
generate
answers
with
the
ipv4
address,
mapped
into
an
ipv6
one,
and
it's
not
in
any
way
clear
that
they
would
count
as
sort
of
authorized.
K
K
So
there's
a
lot
of
things
which
it
feels
like
is
being
proposed
here
but
doesn't
have
doesn't
address.
All
of
the
problems
and
sort
of
feels
into
the
hijacking
is
bad.
If
we
tell
people
not
to
hijack
or
create
some
process,
so
we
can
tell
when
they
will,
they
will
just
stop
doing
that,
and
I
don't
think
that
that's
true.
I
also
think
that
a
fair
bit
of
this
needs
sort
of
wider
discussion
serving
dnsop,
for
example,
could
have
more
of
the.
K
G
If,
if
I
think
it
was
tommy
that
suggested,
you
maybe
check
externally
first
and
then
I
only
look
to
the
so
local
resolver
if,
if
in
the
event
of
failing
with
an
external
resolver,
and
then
that
does
risk
leaking
names,
which
will
be
a
a
concern,
as
I
say,
for
some
enterprises,
perhaps
a
more
substantive
point.
If
to
validate
the
the
the
the.
G
The
that
that
this
isn't
hijacking
that
this
is
done
in
an
agreed
way.
You
you've
that
the
client
needs
to
have
access
to
a
second
dns
resolver
again
in
some
enterprise
environments.
I
think
they're
actively
trying
to
not
allow
access
to
alternate
resolvers-
and
I
think
that's
recommended
practice
from,
amongst
others,
the
nsa
in
the
enterprise
environments,
to
with,
for
example,
encrypted
resolvers
to
only
provide
access
to
a
corporate
encrypted
resolver
and
block
access
to
third-party
encrypted
resolvers.
G
L
Fortunately,
okay
ecker,
please
yeah
hi
sort
of
three.
I
think,
hopefully
not
two,
not
two
hundred
virtual
points,
maybe
the
last
one
won't
be.
The
first
is
that
on
the
fallback
thing,
but
we
do
it
as
as
as
tommy
suggests,
when
you
you
know,
if
you
can't
resolve
a
name,
you
you,
you
fall
out
to
local
resolver.
L
It
is
not
a
deal
for
both
the
reason
andrew
indicated,
which
is
that
it
leaks
internal
names
which
actually
I'm
somewhat
less
concerned
about
you've.
Seen
my
seatbelt,
see
my
previous
commentary
about
about
about
the
trust
in
the
resolver,
but
also
these
external
names,
which
I
am
more
concerned
about.
L
Even
if
you
don't
trust
it
to
have
an
assertion
from
the
print
local
resolver,
the
names
that
it
allegedly
controls,
so
that
you
can
filter
out
those
for
like
for
fallback
resolution,
so
you
know
if,
for
instance
like
I
knew
that
you
know
if
there
was
a
way
to
tell
you
know
the
browser,
for
instance,
that
the
local
network,
only
you
know
only
attempts
to
control
things
that
end
in
corp.example.com,
then,
when
I
you
know,
didn't
resolve
g
still,
I
wouldn't
even
try.
So
that
would
be
helpful.
L
The
second
point
is
to
warm,
as
mentioned
the
captain
portal,
that's
actually
a
special
case
that
everybody's
special
cases.
So
I
really
wouldn't
worry
about
that
too
much
the
standard
procedure
for
people
for
things.
For
I
don't
know
how
probably
relay
works,
but
you
know
how
firefighters
power
network
works.
I
know
how
a
firefox
doe
works
is
to
do
capture
portal
attachment
prior
to
like
doing
anything
else.
L
I
think
the
the
the
last
you
know
a
thing
that
I'm
going
to
say,
which
may
be
slightly
more
controversial,
is
I
do
agree
that
in
principle
you
know,
if
I,
if
I
decide
to
you,
know
advertise
names
for
ecker
that
I'm
hijacking
the
root,
but
in
practice
there's
a
a
difference
in
that
there's.
You
know
one
might
think
of
there
being
where
there
actually
is
or
there's
not
authenticated,
dial
existence
of
dudacker.
L
You
know
from
from
the
root,
and
so
it
is
possible
to
determine
in
general
whether
or
not
this
is
a
a
domain
name
which
does
not
even
exist
in
principle
versus
one
versus
one
which
which
I'm
merely
overloading,
and
so
we
might
imagine
having
that
differently.
It
does
feel
a
little
different,
at
least.
L
L
If
the
name
cannot
be
resolved
in
any
case,
then
I
might
as
well
trust
the
local
resolver
about
a
status
because,
like
that's
all
the
information
you're
ever
gonna
have
so,
I
think
that's
probably
has
more
controversial
opinion,
but
I'm
less
bent
out
of
shape
like
that
one.
It
seems
like
a
policy
question
with
a
touch
of
a
question.
M
M
I
wanted
to
represent
a
use
case
that
is
not
compatible
with
one
of
the
models
I
heard
discussed
and
that
model
was
first
check
the
global
dns
to
find
out.
If
there's
an
answer
and
then
if
there
isn't
an
answer,
do
something
maybe
go
ask
that
question
of
some
locally
advertised
resolver
so
that
names
that
aren't
in
the
global
dns
will
then
be
locable
uppable.
M
I
recognize
this
as
a
strict
definitional
implementation
of
the
split
dns
problem
as
it
has
been
described.
The
the
pr
the
in
practice,
definition
of
split
dns
is
more
subtle
and
it
includes
the
idea
of
filtering
results.
So
not
just
the
ability
to
say
hey.
I've
got
some
names
which
aren't
in
the
global
dns.
M
M
G
B
A
A
Documents
that
come
out
of
add
on
this
topic
we're
going
to
need
to
be
very
clear
in
the
materials
in
those
documents
on
what
use
cases
to
narrow
them
down,
so
that
it's
understood
what
is
being
addressed
and
what's
not
being
addressed,
because
this
is
a
this,
isn't
a
a
large
elephant.
We
have
to
tackle
this.
The
herd
of
elephants
they're
all
slightly
different,
so
that's
sort
of
a
takeaway.
A
I'm
really
pulling
out
of
this
as
sort
of
a
big
picture
thing
that
we
and-
and
it
would
be
really
awesome
if
somebody
were
to
document
all
these
potential
use
cases,
because
I
think
that
the
dns
rule
could
really
benefit
from
the
long
term
from
having
that.
But
that's
definitely
on
the
scope
of
the
add.
In
our
mission,
there.
A
All
right
there's
the
general
agenda
so
as
soon
as
the
my
cues
settle
down,
let's
move
on
then
to
sort
of
the
this
general
open
mic
line,
and
here
are
some
seed
issues
to
get
the
conversation
started,
feel
free
to
pick
up
a
different
topic
and
and
may
ask
yes.
The
way
to
do
this
is
is
to
state
what
your
topic
is
up
front.
A
If
you
do
it
a
different
topic
and
then
go
with
it,
but
that
way
we
all
know
what
the
comments
are
coming
in
about,
but
here
are
three
seed
issues.
Is
the
validation
resolvers
a
resolver's
authority
to
answer
queries
for
domains
needed
in
general?
Does
this?
It's
not
something
we
have
today
in
other
environments,
sort
of
is
answer
validation
needed
in
these
split
dns
environments
and
then
getting
over
to
the
dns
sect
discussion.
A
Well,
you
know,
generally,
today,
dns
is
not
being
used
in
the
53
environments
is,
is
you
know,
is?
Is
this
different?
Is
there
you
know
since
we're
now
in
this
environment,
where
we've
got
these
other
features,
as
ben
noted
available
to
us
now.
Is
this
time
to
you
know,
say
I
say
yeah
yeah:
it
needs
to
have
a
role
here
and
and
needs
adoption,
and
that,
of
course,
would
you
know
trickle
down
to
things
like
clients,
doctors,
supporting
the
nsx
stuff,
so
those
are
starting.
B
J
So,
okay,
hi
paul
vogt
speaking,
one
thing
I
I
kind
of
find
missing
so
far-
is
that
I
would
really
like
to
see
a
sort
of
way
where
you
can,
where
a
network
can
present
a
list
of
domains
and
some
sort
of
authorization
over
it,
that
it
can
give
to
the
client.
And
then
the
client
can,
via
whatever
method,
valid,
tried
to
validate
that
list,
and
and
that's
that
I
don't
think,
there's
a
document
that
tries
to
do
something
like
that.
N
N
Am
I
doing
that
on
the
public
internet
in
a
way
that
everybody
can
do
it?
Or
am
I
doing
that,
because
I
am
connected
either
directly
to
the
enterprise
network
or
through
a
vpn,
because
if
we
reduce
the
problem
to
making
split
dns
work
for
internal
host
or
vpn
with
host,
then
we
probably
have
a
much
simpler
problem
to
solve.
N
L
L
If
these
people
should
also
deploy
dns
for
those
domains,
and
then
there
is
a
sort
of
set
of
like-
I
guess
I
would
say-
non-corporate
or
sorry-
non-default
resolvers
like,
for
instance,
transfer
cursors
over
that
we
use
or
private
relay
or
things
like
that,
where,
if
you
just
start
the
public
resolver,
then
you
get,
then
you
get
an
answer.
Doesn't
work
for
the
local
enterprise,
so
are
there
other
k,
like
what
other
cases
are
there?
L
That
like
where,
like
that
like?
This
is
now
a
concern
that
it
was
not
pretty
concerned,
because
I
say
you
know
I
wasn't
previously
concerned
basically
at
all
so
like
what
other
cases
are
that
need
to
be
resolved,
and
it's
not
clear
to
me
that
those
cases
will
need
the
same.
You
know
have
the
same
answer
so
in
particular,
like
I
think
that
the
you
know
the
answers
I
saw
being
floated
around
for
for
for
the
dns,
you
know
exception.
L
I
All
right
so
going
to
one
of
the
questions
on
this
on
the
slide.
That's
coming
up,
you
know,
is
validation,
results
authority
to
answer
queries
needed.
I
don't
think
it's
always
needed
as
an
answer
to
that.
Ecker
earlier
mentioned
a
case
where
just
having
a
hint
is
actually
sufficient
to
do
something
interesting
as
a
way
to
fall
back.
I
I
I
think
that
clearly
translates
to
the
vpn
case,
which
is
one
of
the
cases
that
we
actually
already
have
solved
and
in
the
vpn
case.
I
trust
this
list
because
I
trust
the
vpn
authentication
based
on
whatever
local
configuration
or
certificates.
I
got
from
my
enterprise
and
because
I
have
that-
and
it
tells
me
the
list
I
I
use
it
so
you
know
if
we
could
have
the
list
that
I
get
from
the
local
network
be
signed
by
some
enterprise
cert
that
I
trust
because
of
a
configuration.
I
I
I
would
argue
that
those
cases
you
know
just
having
a
hint
list
about
what
things
this
local
network
is
authoritative
for
without
any
proof,
and
we
just
try
it
publicly
and
we
fall
back.
That
may
be
enough,
because
these
aren't
going
to
be
sensitive
domains.
It's
like
all
right,
you're,
you
know
you're
accessing
some
movies.airline.net,
that's
not
going
to
be
something
that
people
are
going
to
be
really
concerned
about.
Leaking
of.
You
know,
corporate
internal
secrets.
K
Another
thing
which
I
think
we
need
to
be
careful
we
don't
end
up
doing,
is
falling
into
the.
When
I
join
the
network,
the
network
can
tell
me
what
things
it's
authoritative
for
you
know
is
allowed
to
do
this
behavior,
for
which
is
one
of
the
easy
ways
we
could
get
out
of
this,
because
then
we
run
the
problem
of
you
know.
I
join
company
x's
network
and
they
immediately
tell
me
that
they
can
do
interception
or
blocking
or
rewriting
or
hijacking
or
do
we
want
to
call
it.
K
For
you
know:
company
y
companies,
e
etc,
but
I
mean
the
main
part
is.
I
think
that
we
need
to
make
sure
that
whatever
we
are
designing
is
actually
something
that
solves
the
use
cases
that
people
who
are
going
to
want
to
deploy
this
actually
need
to
solve
and
that
we
don't
ignore
the
use
cases
which
are
just
kind
of
icky
or
hard.
G
Yeah
hi
well,
I
was
covered
most
of
us
gonna
say
so.
I
agree
with
that.
I
won't
repeat
it
and
I
guess
I'm
reminded
of
the
those
of
us
involved
in
add
where
I
think
initially
there
was
a
view
not
to
worry
about
the
sort
of
private
ip
address
sort
of
issue,
because
that
wasn't
terribly
common,
whereas
it
turned
out
that
if
we
ignored
it,
I
think
that
was
85
percent
of
traffic.
G
B
Yes,
thank
you
andrew,
and
I
just
wanted
to
observe
that
there
is
a
discussion
going
on
in
the
chat
about
whether
things
filtering
in
particular
is
in
scope.
I
think
part
of
the
issue
that
we're
experiencing
here
and
why
this
you
know
expanded
beyond
the
scope
of
add
itself,
is
you
know
we're
looking
at
how
the
ietf
handles
this
issue
of
the?
B
I
feel
like
I'm
stumbling
over
myself
a
little,
but
the
overall
point
is
to
say
is:
the
purpose
of
this
very
meeting
is
to
understand
how
different
uses
of
the
dns
are
being
done
out
there
and
so
to
the
extent
that
split
dns
was
not
particularly
in
scope
directly
for
add
or
for
deprive,
or
for
dnsof
we're
trying
to
figure
out
how
to
accommodate
that.
In
all
of
our
discussions
of
our
ongoing
protocol
work
ben,
please.
F
F
I
do
think
it
could
be
helpful,
and
maybe
the
right
first
step
here
would
be
to
try
to
map
out
all
of
the
different
tricky
sub
cases
of
things
that
call
people
call
split,
horizon,
dns
and
and
try
to
identify.
You
know
what
kinds
of
solutions
might
fit
for
which
cases
I
don't
think
you're
going
to
see
a
blanket
solution
and
I
don't
think
we're
going
to
be
able
to
solve
the
current
majority
case.
F
One
example
I
want
to
bring
up
here
is
the
idea
of
http
transparent
proxies.
So
in
the
1990s
it
was
common
to
have
caching
http,
transparent,
proxies
inside
your
network,
so
that
people's
people's
content
could
be
cached
locally
and
reduce
the
you
know,
get
better
performance
reduce
upstream
traffic.
F
It
became
clear
that
that
practice
was
not
really
compatible
with
https,
and
so
as
https
usage
grows
grew
that
practice
fell
away.
It
didn't
happen
immediately
after
tls
1.0
was
defined,
but
it
happened
over
a
period
of
10
or
15
years,
and
you
know,
I
think
that
we
may
be
seeing
a
transition
like
that
with
the
rise
of
encrypted
dns.
Some
other
assumptions
about
things
you
can
do
in
the
network
are
going
to
have
to
change.
B
Right-
and
that
goes
perhaps
it
was
a
better
way
of
saying
what
I
was
trying
to
get
to
with
regard
to
scope.
Is
it's
in
scope
to
discuss
these
as
problems,
but
the
answer
to
discussing
it
in
scope
might
be
to
say
it
is
not
a
problem
we
have
to
solve.
We
just
have
to
recognize
that
this
is
going
to
break
this
particular
form
of
usage,
but
you
still
have
to
recognize
that
it
exists
paul
dixie,
please.
M
That
is,
I
think,
an
overbroad
assertion
when
someone
is
being
tracked,
whether
for
commercial
or
political
or
other
reasons,
the
queries
that
they
make
are
of
interest
to
an
audience
who
does
not
have
their
best
interests
at
heart
and
to
the
extent
that
that
kind
of
leak
into
the
global
dns
can
be
correlated
towards
someone
who's
being
tracked.
It
is
a
very
important
leak,
and
this
leads
me
to
the
point
about
it's
not
just
about
filtering.
G
M
I
think
that
whatever
solution
comes
out
of
this,
you
know
whatever
we
end
up
recommending
whatever
ends
up
getting
deployed.
If
our
recommendation
is
successful
in
that
way,
I
think
everyone
is
going
to
agree
that
it
has
to
be
done
with
some
kind
of
transparency,
ideally
rising
to
the
level
of
consent,
because
if
you're
in
a
coffee
shop
or
an
airplane
or
a
hotel
room-
or
you
know
whatever-
and
your
network
provider
wants
to
hijack
some
of
your
traffic
and
answer
it
differently
for
reasons
of
their
own,
we
can't
necessarily
agree.
M
Should
there
should
be
a
transaction
there
in
an
information?
Transaction
of
this
is
what's
going
to
happen.
If
you
use
this
network,
I
do
or
do
not
agree
to
those
terms.
I
will
or
will
not
use
the
network
on
that
basis
and
that
transparency
element
has
been
notably
absent
from
the
decades
of
abusive
position
by
on
path
actors
which
have
led
us
to
this
conference
call.
M
So
you
know
if,
if
there
isn't
universal
agreement
on
this
call
about
the
virtues
of
transparency
of
whatever
it
is,
the
network
wants
to
do
ought
to
be.
You
know
made
made
apparent
to
the
end
user,
so
they
can
decide
consciously
explicitly
whether
they
they
want
to
to
whether
they
accept
those
terms.
M
Then
I'd
like
to
see
that
discussed,
but
I'm
going
to
proceed
with
the
assumption
that
that
transparency
is
a
universal
and
I'm
going
to
suggest
that
the
filtering
thing
fits
the
category
that
warren
was
talking
about
earlier,
which
is
this
is
the
way
the
network
works,
and
you
know
with
regard
to
ben
schwartz's
follow-up,
which
is
sometimes
the
network
has
to
work
differently
and
it
might
take
a
while
for
that
to
catch
on.
But
you
know
it
doesn't
we're
not
always
shackled
to
the
way
the
network
is
used
today.
M
Some
things
that
people
have
been
doing
will
eventually
stop
working.
For
you
know
various
reasons.
Maybe
the
cost
of
supporting
that
use
case
was
simply
too
complex,
and
so
we
had
to
abandon
something
so
that
went
over
the
side.
I
believe
that
that,
in
this
case,
where
we're
talking
about
signal
diameter,
where
your
dns
questions
go,
is
a
matter
of
huge
importance
for
both
political
and
commercial
surveillance
activities.
G
M
M
I
want
everything
to
come
to
me
and
I
think
that
that
is
objectionable
to
various
people
who
are
working
on
this
authoritative
list
of
local
names
proposal
and
that,
if
we're
not
going
to
have
that,
then
this
is
again,
as
I
said
earlier,
either
a
non-solution
or
a
making
worse,
and
we
should
be
discussing
that.
I
know
it's
painful
to
discuss
it,
but
we
should
be
discussing
that
because,
as
warren
said,
this
is
how
the
network
works
and
the
people
who
have
to
deploy.
This
are.
G
B
B
O
O
One
is
the
question
of
whether
there's
something
useful
we
can
do
here
and
provide
an
applicability
statement
to
make
it
clear
to
the
community
exactly
what
that
useful
bit
is
and
what
it
doesn't
cover,
because
I
think
what
we've
described
so
far
is
a
way
of
providing
a
signal
that
a
certain
set
of
authorizations
have
occurred
and
a
potential
signal
that
allows
you
to
discover
both
local
and
and
global
dns
resolvers.
That
say
hey.
This
is
what
I'm
I'm
authorized
to
talk
about,
based
on
dns,
sec
or
or
similar.
O
If
we
say-
and
this
doesn't
help
you
if
you're
doing
x,
y
or
z-
let's
say
this
is
how
you
do
it.
If
this
is
what
you
are
doing,
I
think
we
do
get
a
little
bit
forward
on
what
was
argued
for
by
a
previous
speaker
that
there
are
certain
things
we
can
do
and
as
long
as
we're
not
claiming
that
we're
solving
world
hunger
with
those
things
but
write
down
what
the
applicability
is
and
understand
that
this
does
not
change
that
people
may
configure
both
their
networks
and
their
devices
differently.
O
I
think
that
is
still
progress
right,
because
we
have
written
down
a
set
of
methods.
We've
agreed
to
those
set
of
methods
for
those
use
cases,
and
I
don't
think
that
that's
necessarily
clear
in
in
my
mind
whether
that's
40
60
50,
50,
80
20,
but
at
least
we
can
be
clear
about
what
we
can
do
and
I
think
that
would
be
useful.
O
I
don't
think
it's
useful
to
be
honest,
to
try
and
lay
out
all
the
different
things
people
do
with
split
dns
and
to
map
the
problem
space,
because
some
of
it
is
very,
very
idiosyncratic
like
there
are
people
who
have
different
dns
answers
based
on
the
port
you're
connected
to
that's,
not
normal,
it's
possible,
but
it's
not
common
mapping.
All
of
that
out
isn't
very
useful.
O
Similarly,
I
think
trying
to
to
take
the
case
where
filtering
and
other
aspects
of
how
people
use
the
dns
or
kind
of
being
worked
into
the
the
same
conversation
as
split
dns
is
is
a
bit
of
a
problem,
and
I
think
we
should
continue
our
focus
on
the
discovery
problem
and
continue
our
focus
on
saying
when
you
discover
it.
This
is
what
you
get
and
that
doesn't
tell
you
anything
about
other
things
that
you
may
configure
or
other
ways
in
which
people
may
behave
thanks.
B
F
Quick,
so
I
joined
the
cube,
maybe
about
half
an
hour
ago,
and
the
discussion
was
on
validation,
resolvers
and
cases
where
that
might
not
be
useful
and
stuff.
I
think
that
ties
really
directly
into
the
80d
charter,
scoping
against
client
and
server
policy.
I
think
yeah.
There
are
cases
where
clients
may
have
policy
where
they
either
have
direct
knowledge
of
certain
configuration
or
certain
use
cases
where
they
might
not
want
validation,
and
there
are
other
cases
where
clients
might
want
it.
F
So
I
think
it's
a
clear
case
where
there
clearly
are
cases
where
it
is
useful.
So
let's
provide
those
technical
solutions.
Let's
provide
ways
to
say:
here's,
the
here's,
the
proof
of
the
authority
behind
the
name,
that's
being
applied,
splittiness,
here's
a
way
to
prove
authority
behind,
like
some
name
that
you
might
trust
for
your
network
configuration.
F
B
A
Thank
you.
Everybody
great
comments
and
great
comments
in
the
comments
chat
session
too,
by
the
way,
so
logistics
wise
moving
forward.
We're
gonna
get
these
notes
out
because
we
got
a
lot
of
chairs
here.
We're
it's
gonna,
take
us
a
little
bit
longer
than
normal.
We
have
a
lot
of
hands
that
need
to
go
in
and
take
a
look,
but
so
expect
the
notes
to
be
available
early
next
week.
A
This
session,
of
course,
is
recorded
and
we'll
get
that
with
the
secretary
up
and
published,
so
you
can
go
back
and
re-watch
all
the
exciting
conversations
we've
all
had,
and
with
that
I
will
say
thank
you
for
participating
and
we'll
see
you
at
itf
113.
Hopefully
in
person
you
never
know
take
care.
Everyone.