We started to test unbound in our internal DNS servers, but when has
some zone update we need to wait until ttl expire to had a fresh
information. To solve this problem I implemented NOTIFY part in unbound
to flush qname in cache.
I think that can be used in many cases, since most of times we need to
propagate fast DNS modifications to our DNS internals.
I need to implement acl yet (notify-access-control), but what
maintainers think about?
my opinion is that this thing doesn't belong to recursive server. It's
probably fine in your specific case, but it doesn't really make sense
in whole DNS scenario.
There's already a remote API for this in unbound, with access control. See
unbound-control's "flush_zone". Assuming your zone update process has or
can have some scripting/automation, just run unbound-control flush_zone
against your recursive servers when you update a zone.
Yes, I know. But with do not use native DNS infrastructure to do this
using NOTIFY? Why create an script in master DNS to check if some zone
are modified and connect on all remote unbound and execute flush.
Doesn't make sense to me.
This idea doesn't break anything, it just implement an easy way to keep
your info fresh into your recursives dns. The principle of RFC-1996.
RFC 1996 deals with messages from a master to its slave(s), so only on the
authoritative side. Resolvers are zone agnostic, so this can only work
partly and, more importantly, in a controlled environment where the master
knows which resolvers to inform. Now, in an enterprise environment this
might be the case, but distributing the zone content close to the resolvers
and not caching there might be a better option.
That's my point. In an enterprise enviroment we need to resolve our
locals zones and external zones too. With notify I can use only unbound
as resolver, pointing our zones to dns master with fast zone update.
Your approach to take zone and put close to unbound have problems, like:
1. If you use unbound as recursive and put nsd/bind in another port, you
have protocol overhead.
2. If you use unbound with local-zone and local-data you need some
script to publish and take care.
This idea doesn't break anything, it just implement an easy way to keep
your info fresh into your recursives dns. The principle of RFC-1996.
RFC 1996 deals with messages from a master to its slave(s), so only on the
authoritative side. Resolvers are zone agnostic, so this can only work
partly and, more importantly, in a controlled environment where the master
knows which resolvers to inform. Now, in an enterprise environment this
might be the case, but distributing the zone content close to the resolvers
and not caching there might be a better option.
That's my point. In an enterprise enviroment we need to resolve our
locals zones and external zones too. With notify I can use only unbound
as resolver, pointing our zones to dns master with fast zone update.
Your approach to take zone and put close to unbound have problems, like:
1. If you use unbound as recursive and put nsd/bind in another port, you
have protocol overhead.
2. If you use unbound with local-zone and local-data you need some
script to publish and take care.
Why do not take advantage of unbound cache?
Another problem here is security. Without BCP 38 deployed I can easily
keep your unbound cache flushing over and over and over.
Yes, it's true, but this problem isn't affect only unbound right? But
you are right.
Your proposal abuses the protocol and can be implemented with unbound
control which has much more security (TLS).
I don't think "abuse the protocol", I think about "using the protocol" Besides, the security part are doing like others, using acl.
I understand your point and I agree, but I don't think it's possible
implement TLS in notify part.
Yes, it can be done, but not for all entries. My concern is about when
you need to change something fast or some service change IP. To do this
without notify you need to loggin in all servers and flush zone.
One example is DNS RR, if you need to take off one server, you need to
flush. If you decrease TTL to much you increase load in your servers.
I'm reading this with interest, and wonder why the TTLs on the
authoritative data is not tweaked to reflect the dynamic nature of
(certain data).
Then Marcus Alves Grando wrote:
Yes, it can be done, but not for all entries. My concern is about when
you need to change something fast or some service change IP. To do this
without notify you need to loggin in all servers and flush zone.
What's the problem with logging into each server to flush the zone? You
can automate it using any number of well-known sys-admin techniques.
The patch code looks fine, but the problem is security for this.
If you were to create a small program listening on port 12345 that
runs next to your unbound servers, that flushes the zone when notified (using unbound-control on the local machine). evldns could be easy to
build such a thing. Then direct the notifies to that other port number.
Would that solve your issues in an architecturally sound manner?
since ldns has some tsig functionality, that could then also be brought to bear to secure the situation properly.
The patch code looks fine, but the problem is security for this.
If you were to create a small program listening on port 12345 that
runs next to your unbound servers, that flushes the zone when notified
(using unbound-control on the local machine). evldns could be easy to
build such a thing. Then direct the notifies to that other port number.
Would that solve your issues in an architecturally sound manner?
since ldns has some tsig functionality, that could then also be brought
to bear to secure the situation properly.
The main idea is create one way to recursive server keep all my zones
freshly, without update all process or less as possible.
Implementing notify to unbound I don't need to change anything in master
server, but need to respect RFC and not implement anything then notify.
Your manner, creating evldns daemon in another port is secureless too.
Yes, it's another port but notify does not include security option. If
same people discovery evldns port is the same thing as implement notify
to unboud.
I have no problem with evldns daemon and yes, it will be solve my
problem, but for me it's another thing to take care, create some way to
keep running, another procedure in case of fail to our operators, etc.
If you guys thing that notify is not a better way, I'll create evldns
daemon without problem, but for me it's a same thing.
# Forward zones
# Create entries like below, to make all queries for 'example.com' and
# 'example.org' go to the given list of servers. These servers have to handle
# recursion to other nameservers. List zero or more nameservers by hostname
# or by ipaddress. Use an entry with name "." to forward all queries.
# forward-zone:
# name: "example.com"
# forward-addr: 192.0.2.68
# forward-addr: 192.0.2.73@5355 # forward to port 5355.
The description does not make it clear whether or not the responses are
always forwarded, or whether they are cached.
An alternative could be to set cache-max-ttl very low and override the
packet TTL's.
I've been wondering the same thing for a long time now. I think based
on my experience with one site where I've set up unbound using
forward-addr they are cached, which would-be/is (IMHO) wrong.
Ultimately though I like the NOTIFY solution best.
Sites converting from BIND will already be using NOTIFY.
The so-called "security" issue for NOTIFY is a bunch of FUD-mongering.
There are several ways to make sure unauthorised NOTIFY messages don't
cause any harm.
