On 5/6/20 6:56 PM, John Levine wrote:
Oh, in that case, why don't you just put some adjusted NS entries in
your stub .net zone pointing at your internal name servers? Seems a
lot easier than fooling around with routing.
Because that is a hack at best.
I figured that there was something I
In article you write:
>-=-=-=-=-=-
>
>
>On 5/6/20 4:12 PM, John Levine wrote:
>> Since they can't access the root servers, how do you expect them to
>> do DNS lookups at all?
>There is a copy of the root zone in the environment.
>
>There is also enough net zone for the needed tests.
>
>DNSSEC is
On 5/6/20 4:12 PM, John Levine wrote:
Since they can't access the root servers, how do you expect them to
do DNS lookups at all?
There is a copy of the root zone in the environment.
There is also enough net zone for the needed tests.
DNSSEC is obviously not in play with doctored zones in the
In article you write:
>-=-=-=-=-=-
>
>On 5/6/20 3:40 PM, John Levine wrote:
>> Can clients on the internal network contact hosts in the outside
>> world, or is it really disconnected?
>It depends on which particular lab is being used and what is being tested.
>
>I can guarantee that some of the
On 5/6/20 3:38 PM, John Levine wrote:
The DNS server sends different answers depending on the client IP,
so on your internal network it sees the private subdomain,
everywhere else sees a ENT or NXDOMAIN.
Thank you for confirming. That is indeed what I /thought/ we were
talking about. But
On 5/6/20 3:40 PM, John Levine wrote:
Can clients on the internal network contact hosts in the outside
world, or is it really disconnected?
It depends on which particular lab is being used and what is being tested.
I can guarantee that some of the labs will NOT have access to other
networks,
In article you write:
>-=-=-=-=-=-
>
>On 5/6/20 2:29 PM, Grant Taylor wrote:
>> That's one of the hard requirements of what I'm doing. Not doing that
>> is not an option.
>
>To elaborate, the internal clients are in a sequestered network which
>will never have outside access to it. As such,
In article you write:
>> This really seems like ordinary split horizon DNS.
>
>Please explain what you mean by "split horizon DNS" like I'm a n00b,
>because obviously my understanding of it differs from what your
>understanding seems to be.
The DNS server sends different answers depending on
On 5/6/20 2:29 PM, Grant Taylor wrote:
That's one of the hard requirements of what I'm doing. Not doing that
is not an option.
To elaborate, the internal clients are in a sequestered network which
will never have outside access to it. As such, the outside world can
never query something
Thanks
Sten
> On 6 May 2020, at 22.28, Grant Taylor via bind-users
> wrote:
>
> On 5/6/20 2:18 PM, Sten Carlsen wrote:
>> I believe the answer must lie in the lookup of a named DNS server, which
>> will be resolved to different IPs depending on your location. Then it can
>> point to
On 5/6/20 2:21 PM, John Levine wrote:
Don't Do That.
That's one of the hard requirements of what I'm doing. Not doing that
is not an option.
This really seems like ordinary split horizon DNS.
Please explain what you mean by "split horizon DNS" like I'm a n00b,
because obviously my
On 5/6/20 2:18 PM, Sten Carlsen wrote:
I believe the answer must lie in the lookup of a named DNS server, which
will be resolved to different IPs depending on your location. Then it
can point to different servers.
If I understand correctly, that would rely on the DNS server's FQDNs
being
On 5/6/20 1:28 PM, Grant Taylor via bind-users wrote:
The only way that I see how to make this work is to anycast the names
and IPs of the name servers that lab1.example.net is delegated to. One
anycast instance being external publicly accessible and the other
anycast instance being internal
In article you write:
>> I think one possibility (to avoid anycast) is to have an internal and
>> external view for the "example.net" zone, so it can delegate the lab
>> zones to different servers internally and externally.
>
>But how do you do that if the internal and external views are on
--
Best regards
Sten Carlsen
For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken
> On 6 May 2020, at 22.10, Grant Taylor via bind-users
> wrote:
>
> On 5/6/20 1:44 PM, Bob Harold wrote:
>> Good questions.
>
> :-)
>
>> I think one possibility (to avoid
On 5/6/20 1:44 PM, Bob Harold wrote:
Good questions.
:-)
I think one possibility (to avoid anycast) is to have an internal and
external view for the "example.net" zone, so it can delegate the lab
zones to different servers internally and externally.
But how do you do that if the internal
On Wed, May 6, 2020 at 3:28 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 5/6/20 11:38 AM, Sten Carlsen wrote:
> > I have been doing that for quite some time without knowing it should be
> > difficult.
>
> I'm not saying that it should be difficult. I'm asking what
On 5/6/20 11:38 AM, Sten Carlsen wrote:
I have been doing that for quite some time without knowing it should be
difficult.
I'm not saying that it should be difficult. I'm asking what people
think the proper method is.
I have a domain (in the mail address) which is properly delegated to
I have been doing that for quite some time without knowing it should be
difficult.
I have a domain (in the mail address) which is properly delegated to servers
and signed. Internally in house I have a number of other internal both hosts
and one subdomain.
The internal versions have RFC1812
Hi,
What is the proper way to delegate to a private / hidden sub-domain?
I have a globally registered domain, call it example.net for this
thread, that has multiple sub-domains that I'd like to be properly
delegated to internal labs; lab#.example.net.
Example.net itself is following all the
20 matches
Mail list logo
