►
From YouTube: CoreDNS Deep Dive - John Belamaric, Google
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
CoreDNS Deep Dive - John Belamaric, Google
A close look at the CoreDNS extension points for developers. Learn how to customize build custom DNS applications based on CoreDNS, including: * Building a custom CoreDNS binary that includes external plugins * Building a specialized binary that uses CoreDNS as a library * Building your own CoreDNS plugin
https://sched.co/Uagj
A
All
right,
good
afternoon,
everybody
thanks
for
finding
your
way
down
here
to
the
dungeon
to
to
learn
about
accordion
s.
My
name
is
John
Bell
Americ
I'm,
one
of
the
maintainer
accordion
s
and
as
well
as
kubernetes
and
here
to
talk
about
specifically
the
extension
points
in
core
dns
for
developers.
So
this
is
the
deep
dive
I'm
not
going
to
go
over.
What
queer
DNS
is
other
than
very,
very
briefly,
but
really
gonna
jump
into
actual
things.
You
can
do
to
customize
it
and
make
it
work
work.
A
So
we
have
essentially
three
three
ways
that
you
can
customize
DNS,
that
people
with
customized
QWERTY
enough
that
people
would
typically
do
the
first
one
is
rebuilding
it
with
external
plugins
and
another
is
to
use
it
as
a
library
to
build
your
own
DNS
server
or
executables,
some
short.
And
finally,
it's
building
your
own
plugin,
which
allows
you
to
do
all
sorts
of
fun
stuff.
So
I
will
talk
about
all
three
of
those
today
and
well,
and
so,
let's
get
started
in
advance.
No
all
right,
all
right,
we'll
start
with
the
the
easiest
one.
A
Actually,
in
fact
it's
called
the
subtitle
is
extensions
points
for
developers,
but
this
one
you
actually
don't
need
to
be
a
developer
to
do
you
don't
need
to
go,
you
don't
need
anything
except
docker
and
a
shell.
So
what
what
this
is
sort
of
getting
at
is
that
core
D&S.
This
is
one
of
those
things.
I'll
talk
briefly
about
what
it
is.
It's
a
DNS
server,
but
but
it's
it's
architected
in
such
a
that.
A
Every
request
that
it
picks
up
goes
through
a
chain
of
plugins
and
each
plug-in
has
the
option
to
either
service
that
request
and
provide
a
response
or
to
modify
the
request
and
pass
it
on
to
the
next
plug-in
in
the
chain
or
to
simply
do
nothing
with
it.
Just
pass
it
on
to
the
next
plug-in
and
then,
when
a
plug-in
does
actually
do
something
with
a
request,
it
gets
passed
back
down
that
should
the
response
essentially
gets
passed
back
down
that
chain.
A
It's
got
a
call
stack
of
functions
and
you
can
actually
manipulate
the
response
on
the
way
back
out
if
you
want
so
that
plug-in
system
makes
it
really
easy
to
add
in
your
custom
behaviors
there's
a
bunch
of
third-party
plugins
available
when
I
say
it's
an
external
plug-in.
What
that
really
means
is
that
it's
not
it's
not
built
into
core
DNS,
the
one
you'd
pull
down
off
of
github
or
the
one
you'd
pull
down
off
of
docker
docker
hub.
Instead,
it's
it's
one.
You
have
to
build
in
yourself.
A
A
The
reason
for
that
is
that
core
DNS
is
completely
statically,
compiled,
there's
no
dynamic
loading,
it's
written
and
go,
and,
and
certainly
when
we
wrote
it
there
wasn't
you
you,
you
didn't,
do
that
and
go
you
couldn't
you
can
now
and
we're
versions
ago,
but
we
still
don't
do
it
we
instead,
we
control
it
with
a
simple
file
that
you
modify
and
rebuild
the
other
thing.
Well,
I'll
call
it
out
in
a
minute,
but
so
let's
actually
do
this
now
so
hopefully
our
network
connectivity
is
good
enough
that
it
works.
A
A
It's
running
that,
let's
see
if
it's
a
point
or
show
up,
probably
not
the
the
view
statement
essentially
is
just
saying
when
we
clone
this.
Normally
this
docker
container
is
going
to
run
as
root.
We
don't
want
all
the
stuff
that
gets
cloned
down
to
our
file
system
here
to
be
on
by
root,
because
then
we
can't
modify
plugins
CF
gene
without
so
you
know,
so
it's
just
a
convenience.
A
So
we
we
we
cloned
it
into
a
directory
and
we
CD
into
that
directory
and
we
check
out
a
particular
branch
I
just
do
that
in
slides,
really
and
you'd
want
to
do
it.
If
you
want
your
builds
to
be
repeatable,
but
you
know
all
of
the
dependencies
tend
to
progress
and
if
you
don't
check
out
a
particular
branch,
you
run
into
all
kinds
of
annoying
problems.
Alright,
let's
give
this
a
try.
The
setup
here
is
a
little
weird.
I
need
to
move
this
see.
A
A
All
right,
it's
a
really
simple
file.
It's
just
the
directive
and
the
go
module
so
in
the
core
file.
That
is
the
file
that
we
use
to
configure
or
DNS
you'll,
see
a
bunch
of
you
know
configuration
directives,
that's
actually
just
what
comes
right
out
of
here
and
then
the
the
go
module
normally
is
you
know?
Basically
we
don't
see
a
bunch
of
slashes
in
there.
We're
gonna
assume
it's
in
the
root
core
DNS
repository,
but
if
we
see
a
bunch
of
slashes,
then
we're
gonna
we're
gonna,
pull
it
from
wherever.
A
A
So
firewall
plugin
basically
will
allow
you
to
do
sort
of
advanced
blocking
of
queries,
and
so
it
fits
in
in
this
plugin
chain,
along
with
the
Akal.
So
so
the
plugin
CFG
actually
defines
the
order
that
the
request
will
be
processed
in
just
like
that.
Just
like
the
plug-in
they're
all
built
in
at
compile
time.
A
Actually,
the
ordering
of
processing
is
built
in
at
compile
time,
which
kind
of
sucks,
but
it's
how
it
is
right
now
and-
and
we
haven't
had
a
good
enough
reason
to
change
it,
because
it's
not
that
hard
to
rebuild
if
you've
got
some
really
crazy
requirements.
So
I
want
for
a
while
to
live
in
roughly
the
same
place,
because
it
does
roughly
the
same
thing:
alright,
cool,
so
that's
it.
We
edited
that
and
then
we
want
to
build
it
to
build
it.
A
I'm
also
gonna
use
docker,
and
the
reason
is
because
I
don't
want
to
have
to
install
go
on
this
machine.
Actually
I
have
go
111
on
this
machine,
but
it
doesn't
work
with
go
111
it
at
this
point,
all
right
that
is
gonna
build
the
next
thing.
I'm
going
to
show
you
after
we
do.
The
pulling
in
an
external
plug-in
is
the
way
to
sort
of
build
your
own
special-purpose
executable,
and
one
of
the
reasons
you
want
to
do
that.
So
then
you'll
have
to
deal
with
all
of
this.
A
So
here
we're
pulling
in
all
kinds
of
stuff.
A
lot
of
this
stuff
comes
in
from
all
the
plugins
that
are
already
part
of
core
D&S.
So,
for
example,
the
kubernetes
plugin
pulls
in
a
bunch
of
libraries
to
do
authentication
against
all
the
different
things
that
cube
config.
You
know
you
can
authenticate,
so
it's
got
stuff
from
AWS
and
imagine
for
Google
Cloud
and
all
of
that,
so
there's
tons
of
dependencies
that
get
pulled
into
an
ordinary
Korean
s.
A
A
Let's
see
if
I
can
talk
more
while
we
wait
for
it
to
bill
one
of
the
things
about
this
since
we're
using
docker
to
do
this
actual
build.
Even
though
I'm
building
this
on
this,
this
Mac
I'm
running
you
know
Linux
container
and
docker
the
build
so
the
executable
that
I
get
out
of
this.
It's
gonna
be
dropped
in
my
local
file
system,
but
it's
gonna
be
a
Linux.
Executable
I
won't
be
able
to
run
it.
A
So
when
we
go
to
run
it,
I
will
also
use
a
docker
command
and
what
I
will
run
is
a
very
simple
extraction.
Show
this
it's
a
very
simple
command.
That's
just
going
to
spit
out
the
list
of
plugins
that
are
used
that
are
installed
in
for
DNS.
So
whenever
you
come
across
a
strange
binary,
you
know,
and
you
choose
to
choose
to
run
it
for
whatever
reason
you
could
get,
you
could
do
plugins
and
see.
If
you
have
the
plug-in
you're
looking
for
is
actually
installed.
A
A
You
see
all
the
kubernetes
class
getting
compiled.
Let's
see
this
was
the
the
the
command
we
used
to
build.
It's
just
a
simple
make
through
make
file.
You
can
actually
also
use
go
build,
but
when
you
modify
the
plugin
C
of
G,
the
make
file
will
also
do
a
go
generate,
which
will
actually
change
a
bunch
of
imports
and
stuff.
So
you
want
to
do
that
and
then
that's
next.
A
Yeah,
oh,
my
goodness,
all
right,
it's
not
that
exciting!
So
why
don't
we
move
on
so
I?
Don't
know,
oh,
except
that
it's
done
all
right
yeah!
So
then
we
can
run
it
so
yeh
we
listed
all
the
plugins,
one
of
which
is
our
firewall
plug-in,
which
is
now
included
all
right.
So
the
reason
it
says,
DNS
dot
firewall,
is
cuz,
Cordy
and
ass
internally.
If
this
doesn't
collapse,
I
mean
Claudio.
A
Next
internally
is
built
using
a
product
called
caddy,
which
is
a
go
based
web
server
originally,
but
really
it's
just
a
server
framework
at
this
point,
and
so
you
could
actually
use
it
to
to
build
any
kind
of
server
and
we
used
it
to
build
a
DNS
server.
Alright
I
should
have
move
this
window
over
and
it
worked
to
where
I
can
see
it
before
alright,
so
that
is
including
an
external
plug-in.
A
And
I
need
my
notes.
Sorry.
The
next
thing
is
the
building
that
that
main
executable
replacing
the
main
go
and
that
that's
done,
for
example,
by
the
if
you've
heard
of
the
kubernetes
node
local
DNS
service,
so
that's
actually
based
on
core
DNS
it
it
runs.
It
builds
a
special
core
DNS
that
includes
only
a
few
plugins.
A
It
includes
like
the
the
forward
plug-in,
which
is
what
we
use
to
talk
to
the
upstream
accordion
on
us
or
upstream,
from
from
node
local
and
in
cash
of
course,
and
then
things
to
manage
or
DNS
like
health
checks
and
readiness
checks
and
things
like
that
metrics.
But
the
reason
it
does
it
this
way
is
that
one
it
makes
it
much
smaller.
A
A
The
other
reason
is
that
this
way
it
can
actually
hook
into
the
startup
code,
and
it
can
do
something
different
and
what
it
does
in
particular
is
it
does
some
fancy
tricks
to
steal
the
VIP
so
that
the
the
dns
traffic
goes
to
the
local
instance
of
it
instead
of
to
the
upstream,
and
it
also
in
particular,
really
nice
thing
it
does
is
turn
off
connection
tracking
for
those
unibit
calls
which
cup
events
a
lot
of
issues
and
avoid
some
bugs
in
certain
versions
of
Linux
panel.
So
that's
a
really
cool
project.
A
A
Basically,
it
just
runs
on
your
local
node
and
presumably
and
answers
queries
sending
them
upstream
as
it
needs
to,
and
they
can
run
it
and
and
don't
have
to
worry
about
how
to
write
a
core
file,
which
is
our
configuration
file
to
make
it
do
do
what
you
want,
because
you're
sort
of
taking
over
the
main
function,
you
can
change
the
command
line
flags
to
do
whatever
you
want.
I
can
show
you
what
that
looks
like
I.
Do
this
awkward
dance
again,
hopefully
not
bad.
A
A
Well,
there's
some
like
I
said
we
use
caddy
as
this
sort
of
framework,
so
there's
some
initialization
stuff.
You
need
to
do
in
order
to
to
get
the
caddy
to
behave
exactly
how
we
want
and
then
there's
a
very
simple
main
function.
This
is
all
does
it
it
parses
the
flags
that
come
in,
so
that
creates
this
structure
that
just
captures
the
configuration
and
the
way
I
did
this
one
is,
then,
that
object
that
captures
that
configuration
will
generate
a
core
file
which,
in
turn
gets
fed
into
the
caddy
start
routines.
A
So
when
we,
when
we
pull
in
the
individual
plugins
that
were
interested
in,
they
also
pull
in
pull
in
what
we
call
our
dns
server,
our
internals
being
a
server
function,
another
class
and
that
in
turn,
is
sort
of
registered
at
the
anit
function.
For
that
what
I
just
release
with
the
candy
framework,
so
that's
how
a
caddy
knows
to
start
up
a
DNS
server
and
not
to
start
up
a
HTTP
server,
because
it's
sort
of
through
this,
the
module
routines
in
in
that
DNS
server
function.
A
A
A
So
we
just
do
these
anonymous
imports
and
that
pulls
in
these
are
the
only
plugins
built
into
this
particular
executable
when
it
when
it
runs
so
then
we
parse
flags
and
finally,
those
flags
and
the
the
struct
that
results
from
that
are
just
used
to
actually
generate
trip,
train
a
core
file
that
just
like
you
would
do
for
an
ordinary
cárdenas
instance,
which
which
ends
up
instantiating
all
of
those
those
things
alright.
So
that
is
that's
number
two
for
number.
Three,
let's
go
back
here.
A
Number
three!
Is
writing
your
own
plugin?
So
writing
your
own
plugin
is
actually
super
easy.
You!
You
basically
write
four
functions,
we'll
talk
about
those
in
a
second,
but
one
of
the
things
that
as
a
sort
of
community,
we
want
to
do
with
core
DNS.
One
of
the
goals
of
it
is
simplicity
and
part
of
simplicity,
it's
sort
of
like
we
try
and
live
by
the
the
UNIX
philosophy.
A
little
bit
of
like
do
one
thing:
do
it
well
at
least
respect
for
our
plugins?
A
So
while
we
tend
to
categorize
plugins
into
three
different
categories,
I
tend
to
think
of
them.
As
these,
these
backends
backends
are
ones
that
will
pull
data
from
some
source,
so
kubernetes
pulls
data
from
the
community's
API
file,
pulls
data
from
a
zone,
file,
etc.
Those
those
do
that
that
function.
Another
category
are
what
I
call
Mutai.
So
these
are
things
that
operate
on
the
requests.
They
take
the
requests
and
they
do
something
with
it.
They
rewrite
it.
They
append
something
like
NS
ID
to
it.
They
are
they.
A
Maybe
they
block
it
and
echo
or
configurators
kind
of
a
weird
word:
I
mean
upward,
maybe
but
those
modified
internal
state.
What
IP
address
joy
behind
you
know
should
I
log,
this
I
guess
yeah
log
I
would
pick
on
it's
not
how
ready
so,
those
those
don't
do
anything
the
requested
per
se,
but
and
they
don't
provide
a
source
of
data,
but
they
they
change
the
way
for
DNS
behaves.
A
So
if
they're
gonna
write
a
plug-in
that
you
want
to
share,
then
I
would
suggest
that
you
follow
that
best
practice
and
you
may
want
to
break
your
plug-in.
You
know,
may
have
some
functionality.
You
want
to
break
it
into
several
different
plugins
in
order
to
follow
that.
But
that's
it
it's
it's
a
rough
model.
There's
nothing!
There's
nothing
in
the
code.
That's
gonna!
Make
that
happen.
It's
just
it's
just
philosophy.
A
Okay,
like
I,
said
for
functions
in
order
to
implement
a
plug-in
name.
The
name
function
literally
just
returns.
The
name
super
simple,
serve
DNS,
that's
the
meaning,
one
that
does
stuff
with
the
request
or
the
response,
and
then
in
it
and
set
up
in
it
is
just
what
registers
the
the
directive
with
the
it
registers
a
directive
with
caddy
and
points
it
to
the
set
up
function
that
has
Caddy's
parsing,
because
it
caddy
actually
is
what
parses
the
core
file
as
it
sees
that
directive.
A
It's
going
to
make
a
call
to
that
set
up
function,
whatever
set
up
function,
you
provide
it
at
an
it
time
and
then
the
set
up
is
the
thing
that
sort
of
gets
you
ready
to
go
so
I
have
another
example.
In
that
same
repository,
the
learning
or
DNS
repository.
That's
an
example
plug-in
that
does
something,
maybe
not
all
that
useful.
A
But
who
knows
basically,
if
you've
got
a
DNS
request
that
goes
out
and
returns
a
bunch
of
data,
then
it
will
actually
pick
one
out
of
the
many
repeat
of
the
many
instances
of
a
particular
type
of
data.
So,
in
this
case
it
would
take
these
3a
records
and
distill
them
down
to
one
really
just
there,
because
it
it's
sort
of
a
useful,
didactically,
useful
thing
all
right,
so
the
first
tips
would
fit
on
a
slide
just
return.
The
name
that's
used
when
we're
logging,
and
things
like
that.
A
A
So
by
convention
we
put
all
of
our
setup
stuff
inside
of
echo,
we
put
the
sort
of
main
meet
of
the
plug-in
in
only
one
that
go
so
please
follow
that
convention,
especially
if
you
want
it
to
be
accepted
as
a
primary
plug-in
without
without
us
telling
you
to
change
it
all
right.
The
setup
that
go
also
has
the
setup
function.
Shockingly.
A
All
it
does
is
call
this
parse
function,
so
the
Cadi
controller.
In
this
context,
it's
essentially
just
a
handle
into
the
place
in
the
in
the
core
file
where
your
directive
appears
and
it's
going
to
hand
you
it's
gonna
hand
you
sort
of
a
utility
class
for
parsing
that
out,
so
we
call
this
parse
function,
I'm
not
gonna,
get
into
that,
because
it's
long
and
hairy
and
not
useful,
not
relevant,
but
finally,
after
it
gets
back
the
the
struct
that
gets
parsed
out
of
there.
It
calls
this
add
plug-in
function,
so
DNS
server
get
config.
A
It's
the
deep
dive,
I
hope
you're
already
familiar
somewhat
with
a
core
file.
Core
file
has
a
bunch
of
stanzas
a
config
internally
in
the
code
kind
of
roughly
maps
too
directly
to
a
stanza
inside
of
a
server
block
for
a
particular
directive.
It's
not
a
one-to-one
and
there's
some
sort
of
subtlety
and
complexity
there
that
we
can
talk
about
afterwards,
if
somebody's
really
interested,
but
from
from
a
thinking
perspective,
you
can
think
of
it
as
almost
mapping
directly
to
his
own
and
hanging
off
of
that
config.
Is
that
plug-in
chain?
A
So
remember
that
any
request
that
comes
in
gets
routed
based
upon
these
stanzas
to
a
particular
or
gets
rerouted,
based
upon
its
its
labels,
com
example,
etc
into
one
of
these
stanzas
and
from
there
that
has
its
own
defined
plug-in
chain.
So
this
is
sort
of
the
mechanism
of
how
that
happens
is
through
these
these
configs.
So
what
we're
doing
here
is
we're
telling
we're
grabbing
the
config
and
we're
adding
this
plugin
when
we
add
this
plug-in,
actually
we're
adding
a
func
and
why
in
the
world,
are
we
doing
that?
A
Well,
the
reason
is
that
this
setup
happens
actually
during
parsing
time,
but
we
don't
build
that
plug-in
chain
actually
until
the
DNS
server
itself
is
spun
out
and
in
order
to
build
that
plug-in
chain.
We
actually
just
go
through
this
and
and
call
all
of
these.
These
add
plugins,
which
you
turn
call
these
functions,
so
it's
kind
of
like
a
delayed,
it's
the
instantiation.
A
So
when,
when
the
actual
server
is
starting
up,
its
gonna
send
an
event
to
each
of
the
those
who've
read
just
read:
just
get
a
callback
for
that
event.
So
if
you
need
to
know
about
the
other
plugins
in
your
chain,
you
need
to
use
the
on
startup
callback
for
that
all
right,
lots
of
details
all
right,
so
the
serve
DNS.
This
one
I
cannot
fit
on
a
slide.
So,
let's,
let's
actually
it
is
I-
have
seven
minutes.
I
want
to
leave
a
couple
minutes
for
Q&A.
A
A
The
DNS
message
here
is
the
actual
DNS
request
that
that
was
made
and
the
response
writer
is
essentially
a
strop
that
will
let
you
write
back
to
the
client
socket
directly
if
you
want
to
sometimes
okay,
so
the
typically
these
first
five
or
six
lines
here,
you'll
see
that
almost
the
same
thing
in
every
sort
of
DNS
you've
got
this.
This
sort
of
convenience
struct
called
a
request
that
we
create
and
for
some
reason
we
always
call
it
state,
and
then
you
have
this
check.
A
This
is
important,
so
in
in
your
in
your
in
most
plugins,
the
first
parameter
they
take
to
their
configuration
is
a
list
of
zones
so
that,
if
your
overall
stanza
say
maybe
handles
five
zones,
you
want
this
particular
plug-in
to
only
handle
one
of
those
five
zones.
This
is
where
you
do
that
check,
so
you
won't
even
get
here.
A
I'll
talk
more
about
that
in
a
second,
but
so
so,
assuming
that
we
we
actually
want
to
handle
this
request.
It's
something
that's
of
interest
to
us.
Then
then,
then,
there's
the
meat
of
the
function
did
this
particular
function.
As
you
recall,
what
it
does
is
it
looks
at
the
response
coming
back
and
modifies
it.
Well,
it's
not
a
back-end,
it's
a
mutator
as
a
mutator.
It
has
to
see
an
in
particular
a
response
mutator.
It
has
to
see
that
response
before
it
can
do
anything
with
it.
A
So
we
actually
have
a
special
kind
of
of
DNS
that
response
writer.
This
is
an
interface.
We
have
a
special
genus
that
the
response
writer
called
an
on
writer
and
what
an
on
writer
does
is
when
any
of
anybody
calls
the
write
function
on
it,
it
just
instead
stuffs
it
in
memory
and
doesn't
write
it
back
to
the
client
socket
otherwise.
You'd
end
up
writing
twice
back,
which
you
don't
want
to
do
so
we
create
an
on
writer
and
we
just
call
them
extra
failure.
A
Passing
that
new
response
writer
in
instead
of
the
original
one
we
got,
we
get
back,
maybe
an
error.
Maybe
not.
If
you
get
an
error
back,
we
just
you
just
go
along,
but
but
this
essentially
is
calling
all
of
those
plugins
in
the
chain.
So
now
we've
inserted
ourselves
in
the
processing
we
haven't
done
anything
yet
to
modify
it.
We've
just
said:
hey
we're
interested
in
the
result.
A
Go
figure
out
what
to
do
and
it
does
we
get
back
that
that
this
response
writer,
this
new
writer,
is
going
to
contain
whatever
message
the
up
that
the
the
later
plugins
in
the
in
the
chain
wrote.
So
then
we
call
this
trim
records,
which
is
does
the
actual
deduplication
in
this
case,
and
we
write
it
back.
So
you
can
see
how
we
are
one
mutator
and-
and
we
write
to
the
to
the
response
writer
that
we
got
in.
Actually
it
could
also
be
a
non
writer.
A
Alright
I'll
take
one
more
minute
and
I
will
talk
about
next
or
failure.
I
only
want
to
mention
this
because
you're
gonna
want
to
use
this
function,
it's
a
utility
function
and
it's
it
does
more.
You
know,
do
you
think
you
just
like,
like?
Oh
just
call
the
next
plug-in,
who
cares
and
it
does
a
little
bit
more
than
that.
What
it
does
is
in
fact.
A
What
is
this?
So
if,
if
the
next,
if
there
is
no
next
one
defined,
it
returns
a
sort
of
fail.
So
that's
that's
all
good
we'd
want
to
do
that
anyway,
so
it
does
a
little
error
handling
from
us,
but
more
interesting.
Is
it
actually
handles
our
tracing?
So
one
of
the
the
plugins
in
core
DNS
is
a
distributed,
trace,
plug-in,
and
so,
if
you
actually
enable
that
and
you
send
a
trace
somewhere
and
you
pull
it
up,
you
can
actually
watch
a
request
as
it
goes
through
different
plugins
and
we
only
trace
selectively.
A
We
don't
trace
every
single
request
unless
you
configure
that
way.
Typically,
it's
terrible
for
performance,
so,
if
you're
enabling
this
anything
but
the
bug
you
want
to
do
like
one
in
10,000
right.
So
this
this
kind
of
takes
care
of
that
for
you
and
keeps
the
tracing
going,
even
if
without
you
having
to
do
any
extra
work,
all
right,
so
that
is
actually
it
for
how
you
create
and
you
plug-in
yay.
A
You
can
find
my
question.
Yes
all
right,
so
you
don't
have
to
remember
all
of
this.
There
is
a
how-to
on
the
website.
The
coordinates
at
I/o
website.
It's
not
great,
probably
should
be
updated,
but
it's
there.
That's
where
accordion
is
github
is
recently
released.
A
book
with
cricket
Lou
called
learning
core
DNS.
A
All
of
these
examples
and
everything
there's
actually
a
lot
more
detail
in
the
book
if
you're
interested
in
this,
of
course,
with
a
lot
of
other
stuff
and
cricket
works
for
Infoblox
and
they
are
giving
away
60
copies
of
the
book
tomorrow.
So
if
you
go
there,
quick
you'll
be
there
to
sign
them
too,
and
if
you
don't
get
there
in
time,
then
they're
giving
away
popcorn
to
like
caramel,
corn
and
stuff
right
good
stuff.
If
you
want
I
can't
be
there,
unfortunately,
but
if
you
want
me
to
sign
it,
I'm
happy
to
do
that.
A
A
A
What
is
the
relation
between
the
relationship
between
cordials
and
cube
DNS,
so
cubed
in
us
is
where
DNS
has
replaced
cube
DNS
as
the
primary
of
the
default
in
cluster
DNS
server.
So
Gordian
ass
is
a
general-purpose.
Do
not
authoritative,
DNS
server
and
cube
Geonosis
only
built
for
specifically
to
be
used
in
in
kubernetes
one
of
the
issues
with
cube
DMS
there's
a
number
of
them,
but
one
is
that
it's
quite
a
bit
more
complicated.
You've
got
like
three
different
containers
running
in
the
pod.
A
You've
got
DNS
mask,
you've
got
the
cube
DNS
itself
and
you've
got
a
sidecar
for
any
metrics,
and
things
like
that.
All
of
that's
built
into
Cordy
and
ass.
There's
different
scaling
properties
for
both
of
them,
but
they,
both
in
kubernetes,
essentially
serve
the
same
function.
It's
just
with
40
of
us.
You
can
also
customize
your
core
file
to
do
all
kinds
of
other
things.
If
you
want
to.
A
A
So
that's
an
example
of
how
you
can,
if
you
had
a
very
specific
set
of
requirements
that
you
wanted
from
a
DNS
server
and
you
did
not
want
the
the
people
using
that
or
the
systems
and
that's
gonna
be
on
to
be
able
to
do
anything
about
other
than
what
you
exposed
to
these
command
lines
like
either,
because
it
you
don't
want
the
complexity
of
having
to
support
them
or
whatever.
It
is
right.
It
lets
you.
It
lets
you
sort
of
not
have
to
do
much
work
and
actually
build
a
fairly
functional,
DNS
server.
A
Dynamic
plugins,
so
there's
two
things
I
would
like
to
do,
but
it's
not
necessarily
a
priority
and
also
add
complexity.
One
is
dynamic,
loading
of
plugins
sure
the
other
is
dynamic
ordering
of
plugins,
and
so
there's
no
reason
technically
why
we
can't
order
them.
However,
you
put
you
know,
however,
you
want
it's
just
backwards,
compatibility,
first
of
all,
what
you
know
the
most
natural
way
to
do.
That
would
be
take
them
in
the
order
they're
in
the
they're
listed
in
the
stanza,
but
that's
gonna
screw
everybody
backwards
with
backwards
compatibility.