On 10/15/22 1:51 PM, Greg Choules via bind-users wrote:
Hi Grant.
Hi Gred,
I'm quickly replying to your message. I'll reply to Matus & Fred later
when I have more time for a proper reply.
My understanding is this, which is almost identical to what I did in a
former life:
client ---recur
OK, if a known client accesses DNS on the internal network, that
client is pointed at a recursive resolver (e.g by DHCP). That resolver
either provides access to the internal DNS zones (e.g. via stub zones)
or sends the client query to the root servers on the internet. An
unknown client (e.g. guest
Hi Grant.
My understanding is this, which is almost identical to what I did in a
former life:
client ---recursive_query---> recursive_DNS_server
---non_recursive_query---> internal_auth/Internet
where:
client == laptop/phone/server running stub resolver code
recursive_DNS_server == what Bob is as
People do the funniest things with DNS. It's a pretty good key-value
store, especially for read-heavy workloads.
Maybe you update counters for "what clients in this OT environment are
posting telemetry to this web server"? DNS wouldn't be a good choice for
that, but Redis is. But maybe you wan
If you are an ISP/registry/DNS provider, it makes sense to separate
authoritative zones for your clients' domains, for all those cases
your client move their domains somewhere else without notifying you
(hell, they do that too often), or to be able to prepare moving
domains to your servers.
#
On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:
If you are an ISP/registry/DNS provider, it makes sense to separate
authoritative zones for your clients' domains, for all those cases your
client move their domains somewhere else without notifying you (hell,
they do that too often), or to be
On 10/15/22 10:03 AM, Bob McDonald wrote:
My understanding has always been that the recommendation is/was to
separate recursive and non-recursive servers.
I too (had) long shared -- what I'm going to retroactively call -- that
over simplification.
Now I understand I'm talking about an INTERN
I'm thinking about redesigning an internal DNS environment. To begin
with, all internal DNS zones would reside on non-recursive servers
only.
why?
On 15.10.22 12:03, Bob McDonald wrote:
My understanding has always been that the recommendation is/was to
separate recursive and non-recursive se
>>I'm thinking about redesigning an internal DNS environment. To begin
>>with, all internal DNS zones would reside on non-recursive servers
>>only.
>why?
My understanding has always been that the recommendation is/was to
separate recursive and non-recursive servers. Now I understand I'm
talking a
Hi!
> I have a zone definition like this:
>
> zone "myzone" in {
> type master;file "signed/myzone";
Aha, this file path was wrong. Fixed, at least it crashes no longer.
--
p...@opsec.eu+49 171 3101372Now what ?
--
Visit https://lists.isc.org/mailman/listinfo
Hello,
I have a zone definition like this:
zone "myzone" in {
type master;file "signed/myzone";
allow-transfer { "myacl"; };
inline-signing yes;
dnssec-policy default;
};
and starting bind9.18.7 on FreeBSD 13.1 (self-compiled ports version)
leads to this crash, according to syslog, see b
11 matches
Mail list logo
