On 18.10.22 09:23, Bob McDonald wrote:
There are no outside clients. In this example, I'm only discussing inside
clients on inside DNS. The recursive resolvers that ALL inside clients
connect to will seek responses from the DNS root servers AFTER determining
that the response can not be determine
Let's not overthink this. I fear that I've activated a lot of creative
circuitry in individuals and provided flimsy details around my example.
There are no outside clients. In this example, I'm only discussing inside
clients on inside DNS. The recursive resolvers that ALL inside clients
connect to
On 14. 10. 22 18:08, Bob McDonald wrote:
I'm thinking about redesigning an internal DNS environment. To begin
with, all internal DNS zones would reside on non-recursive servers
only. That said, all clients would connect to recursive resolvers.
The question is this; do I use an internal root with
On 15.10.22 16:03, Bob McDonald wrote:
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 th
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
On 14.10.22 12:08, Bob McDonald wrote:
I'm thinking about redesigning an internal DNS environment. To begin
with, all internal DNS zones would reside on non-recursive servers
only.
why?
That said, all clients would connect to recursive resolvers.
don't they now?
The question is this; do I
Hi Greg,Great points! I must have forgotten how messy this got :) ./John
Original message From: Greg Choules
Hi John.Yes, you *could* forward and that
was a setup I inherited a good few years ago. The appeal is obvious: it's easy
to do; just chuck queries over there and get ans
Hi John.
Yes, you *could* forward and that was a setup I inherited a good few years
ago. The appeal is obvious: it's easy to do; just chuck queries over there
and get answers.
But forwarding keeps the RD bit set, meaning that the server being
forwarded to should a) have recursion enabled (though it
Hi Bob,I've been able to do this with 'forward' zones. The config would go in
the resolver but the files would not./John
Original message From: Bob McDonald I'm
thinking about redesigning an internal DNS environment. To beginwith, all
internal DNS zones would reside on non-recu
Hi Bob.
In a previous life I did just this. Large resolvers for customers and
internal users, defaulting to the Internet but with specific configuration
to internal auth-only servers for private zones (I used stub but
static-stub and mirror are alternatives - they each behave slightly
differently).
I'm thinking about redesigning an internal DNS environment. To begin
with, all internal DNS zones would reside on non-recursive servers
only. That said, all clients would connect to recursive resolvers.
The question is this; do I use an internal root with pointers to the
internal zones (as well as
19 matches
Mail list logo
