►
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
Deep Dive: CoreDNS - Michael Grosser, Okkur Labs & John Belamaric, Google
CoreDNS is a DNS server written in Go. It can be used in a multitude of environments because of its flexibility. The flexibility is due to CoreDNS’ unique plugin-based architecture: if some functionality is not provided out of the box, you can add it by writing a plugin. In this deep dive session, we take a detailed look at the plugin system of CoreDNS. We walk through the code base of a simple plugin which sync up Kubernetes deployment with services outside of the Kubernetes cluster. This plugin showcases the ease of adding new functionalities to CoreDNS, which is very valuable for DevOps in a hybrid and complicated environment.
To learn more: https://sched.co/GreJ
A
A
So
who
are
we
I'm
Michael
I'm,
the
material
or
one
of
the
maintainer
of
core
Dinah's
I'm,
the
founder
of
our
collapse,
which
is
an
open
source
research
lab
and
also
support
companies
on
Google
cloud
cuban
areas
and
around
Cardenas
we're
the
company
record
solutions
and
we
have
john
polymeric.
He
is
a
senior
staff
software
engineer
and
he's
also
a
material
at
Cardenas,
so
plugins,
so
Cardenas
is
based
on
a
plug-in
middleware
system.
So
it's
really
a
plug-and-play
model
type
thing.
So,
let's
take
a
look
at
the
different
plugin
types.
A
So
what
do
you
usually
use
by
default
are
the
core
plugins,
the
ones
that
are
actually
in
the
record
E&S
repository
and
they're
maintained
and
controlled
by
the
core
team?
Basically,
these
include
the
Prometheus
logging
plug-in
caching,
the
Kuban
a
nice
one.
Basically,
everything
that
is
bundled
by
default.
We
have
a
few
other
ones
that
are
based
based
in
the
coordinates
as
sub
projects,
so
they're
still
aligned
with
the
overall
project.
A
But
there
might
not
be
completely
specific
to
your
use
case,
and
then
we
have
the
external
plugins,
which
are
completely
maintained
externally,
but
can
be
linked
through
coordinates
that
IO.
So
if
it's
something
that
is
relevant
to
your
product
or
a
really
specific
use
case,
you
can
still
announce
it,
but
it
might
not
be
bundled
in
by
default.
A
One
of
the
plugins
that's
currently
being
proposed
and
will
start
as
an
external
plug-in
is
a
resolver
plugin.
So
you
can
use
it
on
your
home
server
or
on
your
machine
and
it
will
resolve
DNS
requests
locally.
So
it
will
start
to
basically
mature
as
an
external
plug-in
and
then
probably
move
into
the
decor
DNS
repository.
A
If
it's
good
enough
or
stable
enough
to
get
bundled
in
by
default,
so
let's
look
at
one
of
the
more
advanced
use
cases,
so
what's
hidden
primary,
basically,
a
hidden
primary
is
a
DNS
setup
where,
instead
of
pushing
the
configuration
to,
for
example,
route
file,
453
or
your
Cloud
DNS
server,
you
basically
have
a
hidden
primary
control
server,
which
is
the
authoritative
server
from
the
behind
the
scenes.
Basically,
so
what
happens?
A
In
general,
we
have
the
user
that
is
requesting
DNS
record,
that's
usually
going
to
a
recursive
one,
which
could
be
your
eyes
P
DNS
server
or
your
public
DNS
server
that
you
use
from
CloudFlare,
Google,
Public,
DNS
or
things
like
that.
These
are
just
recursive,
so
they
don't
have
the
authority
to
completely
solve
the
DNS
record,
and
it
will
then
upstream
if
it
doesn't
know
who
or
doesn't
have
anything
cached
to
the
secondary
DNS
server.
So
the
internet
based
video
or
every
user,
knows
about
the
secondary.
So
that's
why
it's
a
hidden
primary
set
up.
A
A
So,
let's
jump
into
so
we
can
basically
use
a
good
space
DNS
so
especially
for
open
source
projects
or
bigger
companies
then
need
an
audit
lock
on
their
Denese
tones
on
the
records
they
can
use.
Get
for
that
so
either
you
some
companies
use
like
a
little
small
library
that
will
consume
the
get
based
zones
and
then
push
that
to
their
cloud
provider,
which
then
serves
the
zones,
that's
nice
and
possible,
but
with
the
hidden
server
or
the
hidden
primary
use
case.
A
We
can
actually
manage
a
lot
more,
so
we
basically
get
the
data
from
the
git
repository.
In
our
case,
we
use
git
sync,
which
is
a
small
sidecar
in
in
Cuban
Aires,
which
will
pull
in
the
git
repository,
which
is
basically
just
bind
formatted
zone
files,
and
this
will
allocate
the
data
in
the
sidecar
and
next
Cardenas
Cardenas
has
a
few
plugins
one
being
a
file
plucking
and
one
being
an
out
out
of
plug-in.
It
basically
can
read
in
zones
from
the
file
system
and
then
search
them.
A
Authority,
Leafly
and
also
add
some
can
add
a
sorry.
Can
add
a
few
more
features,
for
example
rewrites,
so
you
can
rewrite
any
queries
you
want
to
have
specifically
handled
so
this
server
cárdenas,
basically
as
the
hidden
primary
will,
then
just
use
notifies
to
notify
the
secondary
dns,
my
DNS
server
to
publicly
or
pull
the
latest
updates.
So
sometimes
these
notifies
get
lost
on
the
internet
or
some
authentication
might
not
happen
or
something
like
that.
So
that's
where
we
jump
into
the
server
record.
So
it's
the
basically
the
primary
the
start
of
authority
record.
A
It's
the
one
that
describes
or
that's
the
one.
That's
the
most
minimal
record,
that's
needed
in
each
zone
so
just
to
get
into
it.
I
know.
Probably
most
of
you
already
know
that,
but
just
to
get
the
constrictor
ID
so
example
the
comb
would
be
this
zone.
Then
we
have
the
TTL
of
that
specific
record,
a
man,
basically
the
record
type
being
zero.
The
anistar
example
come
would
be
the
actual,
the
actual
name
server.
A
That
is
publicly
requested
for
all
the
requests
on
the
on
the
internet
for
your
specific
domain,
and
then
we
have
a
weird
one
so
domains
that
example
has
come.
It
looks
like
a
subdomain,
but
it's
actually
an
email
address
the
problem
with
emails.
The
ad
is
a
special
character
which
can't
be
used
in
any
zone
files.
A
So
that's
why
the
first
dot
will
be
translated
to
the
ad
but
more
interestingly,
so
we
have
the
serial,
which
is
probably
self-explanatory,
but
more
interestingly,
we
have
the
different
TTL
s,
usually
there
without
wherever
they
are
added
without
the
comments,
so
you
basically
see
four
numbers.
No
one
usually
knows
what
they
are
but
to
get
into
what
they
can
be
used
for
and
why
they
are
important
for
our
hidden
primary.
So
the
refresh
rate
is
basically
how
often
the
secondary
tries
to
pull
data
from
the
primary.
A
The
second
one,
the
retry
entry
is:
how
often
it
is
it
retries
and
to
check
if
anything
changed.
So
it
basically
just
pulls
the
header
and
then
checks
the
serial.
If
it's
updated
or
not,
and
then
we
use
refresh
rate
to
refresh
the
record,
then
we
have
the
expire.
So
in
our
case
we
use
the
hidden
primary
in
production.
It's
running
in
one
of
our
local
Cuban
Inez
clusters,
but
it's
a
replica
and
sometimes
it
gets
down.
A
But
the
wonderful
thing
about
this
set
up
is
as
long
as
the
expiry
is
longer
than
our
time
down
time
and
we
don't
do
any
changes.
No
one
notices,
so
the
expiry
basically
tells
the
secondary
how
long
he
can
answer
a
thorough
flea
on
you'd
main
or
on
your
zone
without
checking
in
with
the
master
after
the
time,
basically
is
expired
and
the
master
isn't
reachable.
A
It
will
drop
all
requests
and
basically
fail
and
Nick's
domain
and
the
other
one
is
minimum
negative
caching,
which
is
really
helpful
if
you
change
domains
and
one
a
black
hole,
a
domain
or
zone.
So
if
you
had
an
old
subdomain
which
is
not
really
used-
and
you
don't
have
negative
caching
on,
you
might
run
into
a
huge
bill
on
your
DNS
provider
because
it
keeps
on
keeps
on
spinning
and
doesn't
cache
on
the
ice
P
level.
A
B
My
Mike
okay,
there
we
go
all
right
well,
so,
as
Michael
mentioned,
core
DNS
is
a
plug-in
based
system.
What
that
means
is
that
a
request,
a
DNS
request
that
comes
in
is,
is
passed
through
a
number
of
handlers
and
you
can
insert
handlers
in
that
chain
of
your
own.
A
few
things
to
note
about
that.
Well,
it
is
a
plug-in
based
system,
it's
it's
written
and
go,
and
it's
not
using
the
go
dynamic
loading
plug-in
facilities,
so
it's
actually
the
plugins
are
all
compiled
in.
B
That
means
that
if
you
do
want
to
create
your
own
plug-in,
you're
gonna
build
the
whole
executable,
not
just
you
know
plug-in,
but
nonetheless
it's
pretty
easy
to
view,
and
you
can.
You
can
accomplish
a
lot
of
interesting
use
cases
this
way,
the
plug-in
we're
gonna
show
here,
as
a
demo
is
really
a
stupid
plug-in.
B
B
The
code
for
this
is
on
that
github.
It's
super
simple,
though
we're
just
gonna
go
through
the
code.
I'll
explain
the
different
pieces.
You
need
in
order
to
create
a
plug-in,
so
essentially
for
a
simple
plugin
like
this.
It's
two
files,
you
could
put
them
all
in
one,
but
it's
two
files.
It's
a
setup
that
go
which
contains
an
init
function.
B
That
function
is
performs
the
one-time
initializations,
including
registering
this
the
setup
function
with
caddy
and
that
so
accordion
s
uses
there's
a
webserver
a
go
playing.
Web
server
called
caddy,
that's
been
around
for
a
while.
It's
got
a
plug-in
architecture
and
it's
got
a
it's
a
sort
of
server
infrastructure.
B
Essentially,
a
lot
of
those
infrastructure
facilities
for
building
a
server
are
all
taken
care
of
for
us
and
letting
us
focus
on
just
the
DNS
pieces.
So,
in
order
to
to
build
your
plugin
you're
going
to
integrate
with
that
set
of
libraries
and
the
the
init
process,
this
registration
process
is
essentially
just
telling
caddy
hey.
When
you
read
this
configuration
file
you're
going
to
get
this
directive
a
string
demo
in
this
case,
and
when
you
get
that
I
want
you
to
call
my
function
over
here,
the
setup
function
and
pass
to
it.
B
The
handle
to
that
configuration
file
basically
sitting
there
right
at
that
at
that
directive,
so
I
can
just
consume
the
things
that
are
relevant
to
to
my
plugin.
That's
what
the
setup
does
it
parses
that
it
adds
the
handler
I?
Guess
if
you,
if
you
weren't
at
one
of
the
earlier
core
DNS
ones,
you
may
not
have
seen
the
explanation
of
a
core
file,
but
essentially
in
a
in
a
core
file
in
our
configuration
file.
B
B
So
those
stanzas
are
you
get
this
setup
call
once
for
each
of
those
stanzas
in
which
your
plug-in
directive
exists
in
the
responsibility
of
that
set
up,
call
to
to
create
a
configuration
essentially
to
parse
its
configuration,
create
an
object
and
then
associate
a
handler
for
that
for
that
with
that
stanza
internally.
Finally,
there's
the
serve
DNS
function,
which
performs
the
actual
request
processing.
So
to
look
at
the
actual
code.
B
In
our
case,
there
are
no
parameters,
so
we
don't
really
do
anything
with
it.
What
we
do
is
add
this
handler,
so
it's
the
handler
is
done
as
a
your
basically
there's
an
interface
you
have
to
implement
that
has
served
DNS
in
it
and
name,
and
those
are
the
only
two
functions
and
you
pass
that
in
here
we're
instantiating
the
demo
object.
If,
if
we
had
parameters
for
this
that
for
the
configuration
we
would,
we
would
fill
that
in
there.
B
Finally,
the
serve
DNS,
which
doesn't
look
the
same
on
the
screen
now
than
it
did
before
so
seem
to
have
lost
the
spacing.
But
in
this
case
super
simple,
you
get
you
get
three
parameters,
you
get
a
go
context
which
we
can
use
for
all
sorts
of
tricks
and
games
later.
If
we
wanted
to
you
get
a
response
writer,
which
is
essentially
just
a
class
or
a
interface,
you
can
call
in
order
to
write
the
actual
response
back
to
the
client.
B
Although
we
have
some
implementations
of
that
that
will
essentially
capture
it
and
let
let
you
manipulate
other
plugins
data
and
I'm.
Finally,
you
get
the
DNS
message,
which
is
the
actual
request,
and
in
our
case,
like
I,
said
it's
a
super
simple
stupid.
Plugin-
and
it
just
has
one
if
statement
and
changes
the
reply
based
upon
that
in
the
next,
a
little
is
the
continuation
of
that
function.
It
basically
creates
a
a
resource
record
for
the
reply
at
the
NS
message
and
sends
back
success,
so
we
can
try
it.
B
B
This
is
a
dr
command.
You
can
use
to
build
it,
so
you
don't
have
to
get
your
whole
go
environment
set
up
if
you
really
want
to,
and
so
we
can
look
at
what
that
looks
like
so
I've
already
done.
This
I've
already
did
the
build,
so
I
won't
run
that
again,
but
we
can
run
the
actual
Gordian
ass.
We
can
see.
B
This
facility
makes
it
really
easy
to
build
versions
of
coordinates
that
are
scoped
to
a
particular
purpose.
So,
for
example,
there's
a
node
local
DNS
project
that
just
came
through
kubernetes
in
113
out
in
alpha,
and
that's
done
by
actually
stripping
out
all
of
these
plugins
CFG
entries,
except
for
the
very
few
that
you
need
that
way.
We
got
the
executable
down
to
pretty
much
as
small
as
we
could
get
as
far
as
a
memory
consumption
and
because
it's
going,
you
know
on
every
single
node.
B
So
it's
it's
a
nice
way
to
tune
things
and
keep
your
resource
utilization
low.
In
any
case,
you
insert
this
in
the
plug-in
CFG
and
one
very
important
thing.
That's
kind
of
I
think
something
we
need
to
fix
eventually.
Is
that
this
also
dictates
the
order
in
which
the
plugins
are
passed.
The
request
so
your
stands
are
that
defines
what
plugins
are
activated
for
that
for
a
particular
zone.
B
It
it.
You
can't
change
the
order,
the
order
that
you
put
them
in
that
stands.
It
doesn't
actually
matter
what
matters
is
whether
they
are
not
if
they're
there,
they
get
added
to
the
to
the
chain
of
plug-in
plugins,
but
they're,
always
added
in
the
same
order,
which
is
the
order
of
this
plug-in
CFG
that
can
limit
you
in
a
number
of
ways.
B
B
The
we've
recently
added
something
we
call
the
metadata
plugin
and
what
that
does
is
it
allows
the
passing
of
information
from
one
plugin
to
the
next
so
where
this
is
used
today
is
in
things
like
the
log
plugin,
so
you
could
publish
to
this
to
them
to
the
go
context.
It's
this
metadata
and
then
the
log
can
put
that
in
your
log.
So
if
you
had
something
special,
you
don't
want
to
print
like
era,
log
messages,
but
you
had
some
status
or
something
you
wanted
to
come
out
of
your
plugin.
B
B
There
are
a
few
other
really
interesting
use
cases
I
think
we'll
be
able
to
to
do
once.
We
have
this
fully
plumbed
through
everything.
One
is
that
we
have
another
plug-in
coming
soon
called
firewall.
This
is
a
very
simple
sort
of
allow
deny
for
request,
so
you
could
do
that
based
on
client,
client,
IP
record
type,
whatever
it
is
in
the
request.
B
But
if
we
allow
say
the
kubernetes
plug-in
to
publish
metadata
about
the
requests
and
so
could
publish,
for
instance,
the
name
space
of
the
source
pod,
the
pod
corresponding
to
the
client
IP,
then
you
could
actually
use
that
kubernetes
metadata
within
the
firewall
plugin
to
build
all
kinds
of
policies
about
how
you're
allowed
to
to
resolve
requests.
So
those
are
some
of
the
things
we're
looking
at
in
the
near
future.
A
So
one
interesting
use
case
for
the
firewall
plugin,
for
example,
is
this
called
or
you
can
route
traffic
through
DNS
text
records
and,
for
example,
if
you
allow
at
an
airport
DNS,
you
might
be
able
to
tunnel
traffic
through.
So
one
idea
is
to
basically
disallow
text
records
in
airports
or
something
like
that.
So
that
would
be
a
use
case
for
the
firewall
practice,
which
is
really
tangible
and
the
other
one
that
is
basically
coming
or
that
we're
looking
into
is
a
writable
direct
API
for
currently
like
how
it's
done
but
kubernetes.
A
One
which
cut
is
coming
from
the
central
instance
or
the
cuban
Eddie's
master,
and
if
you
have
any
other
ideas
for
plugins,
especially
play
external
plugins
for
now
give
us
yeah
come
over
and
or
do
a
pull
request
or
issue
and
we're
happy
to
receive
any
contributions
so
we're
on
github
on
slack
and
if
you're
used
in
if
you're,
using
or
DNS
in
production.
We
would
love
to
hear
about
it.
Yeah.
Please
open
a
pull,
request
and
open
and
add
yourself
to
the
adopters
file.
A
B
Before
you
before,
you
start,
we
do
have.
We
have
10
t-shirts
here.
So
I
don't
know
what
sizes
you'll
just
have
to
get
lucky
with
the
sizes,
but
but
every
good
question,
not
bad
questions,
good
questions,
so
ones
we
can
answer,
maybe
or
maybe
once
we
can't
answer
would
be
better
question.
You'll
get
a
t-shirt
so
who's
first,
alright
right
here,
I
have
to
turn
this
off.
We.
D
Okay,
thank
you
for
the
talk,
so
the
web
server
component
seems
to
be
a
very
critical
piece
of
the
entire
project.
You
guys
I
mean
that's
materials,
caddy
project
right.
So
do
you
have
a
separate
folk
wherein
you
can
just
put
in
whatever
and
if
there's
a
fix
do
you
do
you
contribute
upstream
to
caddy
and
then
pull
that
caddy
specific
version
into
code
ENS
or
do
you
have
a
separate
folk
and
just
maintain
yours,
and
because
that
will
have
more
flexibility
into
whatever
changes
you
want
to
push?
B
No,
we
don't
have
a
separate
Fork,
we
use
the
upstream
carry
and
we
haven't
had
any
real
issues.
We
work
pretty
well
with
with
Matt,
and
you
know
so
that
the
times
we've
had
we
found
bugs
we've.
You
know
in
say
the
we
thought
we
found
some
in
the
restart
process,
so
there's
certain
events
that
go
out
and
causing
issues
during
restart
under
certain
conditions.
So
we
were
able
to
upstream
any
fixes
like
that.
So
we
haven't
had
an
issue
with
that.
A
It
also
depends
on
the
use
cases,
so
if
you
use
something
within
caddy
that
might
be
a
bit
more
unexposed
and
he's
changing
something
internally
or
the
Caddy
project.
Is
you
run
into
that
issue
more
often?
But
then
it's
basically
it's
a
build
time
error.
So
you
could
do
that
by
actually
building
a
specific
version,
but
we
try
to
run
as
close
as
possible
because
it's
still
most
of
the
code
base
is
the
same.
So
we
want
to
have
the
same
box
and
therefore
fix
it
upstream
faster.
Any
other
question:
lots.
E
B
The
the
file
I
believe
the
file
plug-in,
but
definitely
the
auto
plug-in
will
monitor
the
file
automatically.
So
as
soon
as
you
change
the
file
it
at
well.
After
a
little
while
it's
it's
actually
polls
periodically
it'll
it'll.
Look
at
it
and
it'll
see
that
it's
change.
The
serial
numbers
changed,
don't
forget
to
change
the
serial
number
and
then
it'll,
it'll
reload
it
so
no
support
for
ddns
what
we're
looking
at
so
so.
The
idea
behind
the
writable
API
is
that
we
we
have
all
these
different
backends
and
we're
not.
We
don't
just
have
one.
B
B
Well,
we
would
add
another
interface
for
a
writable
plug-in
that
allows
you
to
store
a
record
and
then
the
the
plugins
that
have
that
capability,
like
let's
say
the
sed
plug-in,
would
would
implement
that
interface
and
then,
on
top
of
that,
we
build
other
plugins.
That
can
do
the
external
API
for
those,
so
you
can
do
it
through
our
G
RPC
interface
or
we
can
implement
a
plug-in
that
does
three
DNS
with
the
DNS
or
we
can
implement
a
plug-in
that
has
a
restful
api.
E
A
So
on
the
on
the
file
based
one,
so
we
did
use
notifications
on
the
file
system
so
ii.
You
basically
change
the
file
on
the
system.
We
would
reload
it,
but
we
ran
into
some
race
conditions
and
issues
with
how
FS
notify
works.
So
there
were
so
many
bugs
that
were
just
annoying
and
reading
fouls,
most
likely
isn't
that
problematic,
depending
on
the
size
of
your
zones.
So
it
now
defaults
to
I,
think
30
second
pools
and
you
can
go
down
to
like
a
second,
usually
shouldn't,
be
any
issue:
Norris,
okay,.
F
B
All
right,
that's
a
really
good
question.
You
definitely
get
a
shirt,
so
the
so
Michael
mentioned
this
early
in
the
talk.
So
we
do
have
a
plug
in
external
plugin
that
compiles
in
unbound
and
that
will
allow
you
to
do
recursion.
But
we
recently
had
a
contributor
who
wrote
I
think
he
calls
it
s
DNS,
it's
a
golang,
recursive
DNS
server
that
he's
already
written.
He
just
stripped
out
a
bunch
of
stuff
and
made
it
into
a
plugin.
G
F
G
A
A
The
other
thing
is
it's
easier
to
maintain
because
keep
Tina's
was
a
bundle
of
DNS
mask,
which
is
single
threaded
and
sky
DNS,
which
sort
of
partly
maintained,
and
now
we
move
to
the
only
single
one
which
is
much
more
extensible
and
the
the
cluster
plug-in
or
add-on.
We
are
generally
mentioned
called
note,
local,
which
is
available
as
a
fern
1.13,
which
adds
a
diamond
set
of
a
minimalistic
or
DNS
instance,
and
it
also
spreads
around
all
the
different
external
requests.
A
So
internally,
as
we
said
in
the
core
file
you
can
set
depending
on
your
your
path
or
your
zone,
it
will
answer
differently.
So
all
the
internals
will
still
go
to
the
central
core
DNS
instance,
but
everything
external
would
go
right
upstream.
So
you
completely
move
around
any
issues
and
any
bottlenecks
inside
the
club,
a
central
one.
B
So
for
the
migration,
so
the
the
what
I
would
do
is
I
would
create
a
deployment
with
core
DNS.
That's
got
the
same
labels
as
the
cube
DNS
instances
and
get
it
in
the
mix
and
make
sure
everything's
working
well
for
you
and
you're
watching
the
metrics,
and
then
you
can.
You
can
transition
it.
So
it
keeps
the
if
you
worse,
if
you're
running,
cubed
min
it
will
I,
don't
think
it
upgrades
you
by
default.
A
Anecdotally,
on
the
you
can
look
for
the
next
person,
so
mini
cube,
for
example,
had
the
problem
that
they
wanted
to
switch
and
accidentally
it
deployed
both
and
then
notice
that,
because
it's
still
using
cube
deenis
as
the
cluster
service
are
basically
both
responded.
And
there
was
like
a
weird
issue
where
they're
like
oh
yeah,
our
DNS
fails,
but
only
like
half
the
time,
so
they
fixed
that.
But
it
happens.
So
you
can
actually
use
that
as
a
deployment
mechanism.
B
H
B
Very
good
questions,
so
the
the
process
is
pretty
informal.
So
if
it's
a
big
complex
plug-in
like
this
recursive
DNS
plug-in
there
we're
going
to
take
more
time,
we're
gonna
we're
gonna,
see
that
if
it's
something
really
small
and
simple,
we
may
just
pull
it
pulling
it
immediately.
We
try
and
keep
things
compiled
into
the
basic
default
image
very
general
purpose
that
useful
to
most
people.
So
if
it's
a
really
narrow
use
case,
then
it
won't
won't
make
it
in
there
and
I
need
another
shirt
to
get
you.
Your
questions.
B
So
yes,
and
no
I
guess
is
the
best
answer.
We
don't
support
views
in
the
sense
of
bind
right
now
we
do
have
there's
some
external
plugins
that
could
help
you
do
we
have
a
there's,
an
external
policy
plugin
that
you
can
use
an
external
policy
engine
to
do
all
kinds
of
crazy
stuff,
but
we
are
looking
at
I
know
for
install
over
there
and
someone
over
there
he's
got
a
some
plans
to
build
a
plugin
that
would
allow
you
to
do
something
very
similar
to
views
at
least
the
basic
functionality
of
use.
B
Does
it
support
DNS
SEC?
Yes,
it
does
support
DNS
SEC,
it's
not
it's.
It's
not
full
support
of
everything.
I
cricket
Lou
is
here
earlier
doing
some
of
the
talks
and
he
would
be
able
to
he's
more
lowers
a
lot
more
about
DNS
SEC
than
me,
but
he
said
something
like
you
have
to
use
the
same
key.
You
can't
do
split
keys.
It's
only
supports
one
of
the
algorithms,
so
there's
some
limitations,
but
it
does
support
it.
Yeah
I.
B
Not
specifically,
but
you
know,
those
are
the
sort
of
things
that
can
be
added
as
plugins.
If
people
come
to
the
community
and
they're
really
interested
in
it,
especially
if
they're
willing
to
contribute
I
do
know,
there's
some
I
lost
the
thought,
but
there's
been
discussion
of
some
of
these
things
and
there
is
a
there
are
some
plugins
I
know
for
the
Infoblox
did
that
do
alternate
or
fallback
type
of
things.
B
A
You
can
also
like
there's
a
plugin
called
fall
through,
so
as
long
as
the
other
plugins
in
the
chain
supported.
If
it
doesn't
have
an
answer,
it
will
just
fall
back
to
the
next
plug-in
in
line.
So
you
could
say
if
it's
in
the
zone,
files
that
are
local
for
example,
that
will
serve
it.
If
not
I
will
fall
through
to
the
internal
DNS
server.
A
C
B
Don't
think
you
get
a
shirt
for
that
question,
no
I,
I
I,
don't
I
can't
think
of
any
offhand.
I
mean
you
know
it.
Well,
I
got
okay,
some
would
be
if,
if
you,
you
have
to
be
careful
about
how
the
reload
semantics
work,
so
sometimes
people
or
even
us,
and
a
lot
of
our
earlier
plugins,
had
like
a
package
specific,
a
package
global
variable
and
then
when
reload
happens,
they
don't
play
well
together
and
you
get
problem
so
you
so
that's
one
I
think
area
to
be
to
be
careful
about
another.
A
One
would
be
probably
the
order
in
which
you
add
it
into
the
plug-in
CFG,
because
it
might
be
that
you
rely
on
something
in
as
a
general
serving
plug-in
or
something,
and
if
you
put
your
plug
in
before
that,
it
might
break
all
of
the
other
plugins,
because
there
is
some
implicit
ordering
for
some
plugins.
So
if
you
interrupt
them,
you
might
break
the
build
type
thing
like
not
the
build,
but
at
the
runtime
I.