What is the proper way to delegate to a private / hidden sub-domain?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
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 industry standards and best
practices that I'm aware of; registered (read: rented), delegated from
roots to multiple public DNS servers which respond to the world.

I would like to delegate lab1.example.net in such a way that the outside
world sees a delegation to what is effectively an empty zone (save for
SOA / NS / etc.) on a public server.  However I'd like the internal lab
systems see a delegation to a private zone that has all the necessary
records in the lab.

One hack that comes to mind is to have the example.net parent zone
delegate to a separate name server with a separate IP and then to
anycast that IP & name server inside the lab.  But that would require an
additional globally routed IP on the external public Internet.

I'm not currently worried about supporting DNSSEC, but it would be nice
if the solution would allow DNSSEC signing both the public and private
zones.  With the obvious assumption being the DNS servers would have
shared keys to be able to sing their copies of the zone correctly.

Does anybody have any ProTip(s) on how to go about doing this?  What
about gotchas to avoid?

Thank you and have a nice day.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Sten Carlsen
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 IPs and the outside ones have public IPs.

Both sides are signed by the same key.

The way this is organised is that I use two views, one internal and one external, I set both to be signed using:

options {
directory "/var/named/data";
auth-nxdomain no;
dnssec-enable yes;
dnssec-validation auto;
allow-query { any; };
allow-transfer { any; };
listen-on-v6  { any; };
sig-validity-interval 30 20;
dnssec-loadkeys-interval 60;
};

Never caused any problems. The downside is that I use views and have to manage both sides.
-- 
Best regards 
Sten Carlsen 


For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken


On 6 May 2020, at 19.01, Grant Taylor via bind-users <[hidden email]> wrote:

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 industry standards and best practices that I'm aware of; registered (read: rented), delegated from roots to multiple public DNS servers which respond to the world.

I would like to delegate lab1.example.net in such a way that the outside world sees a delegation to what is effectively an empty zone (save for SOA / NS / etc.) on a public server.  However I'd like the internal lab systems see a delegation to a private zone that has all the necessary records in the lab.

One hack that comes to mind is to have the example.net parent zone delegate to a separate name server with a separate IP and then to anycast that IP & name server inside the lab.  But that would require an additional globally routed IP on the external public Internet.

I'm not currently worried about supporting DNSSEC, but it would be nice if the solution would allow DNSSEC signing both the public and private zones.  With the obvious assumption being the DNS servers would have shared keys to be able to sing their copies of the zone correctly.

Does anybody have any ProTip(s) on how to go about doing this?  What about gotchas to avoid?

Thank you and have a nice day.



--
Grant. . . .
unix || die

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
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
> servers and signed. Internally in house I have a number of other
> internal both hosts and one subdomain.

It looks like your domain is delegated to Gratis DNS servers and that
they resolve specific records to your external IP.

I'm not seeing a delegation beyond that.  But that could simply be
because I don't know what name to query.  (AXFRs are properly refused.)

> The internal versions have RFC1812 IPs and the outside ones have public IPs.
>
> Both sides are signed by the same key.
>
> The way this is organised is that I use two views, one internal and one
> external, I set both to be signed using:
>
> options {
> directory "/var/named/data";
> auth-nxdomain no;
> dnssec-enable yes;
> dnssec-validation auto;
> allow-query { any; };
> allow-transfer { any; };
> listen-on-v6  { any; };
> sig-validity-interval 30 20;
> dnssec-loadkeys-interval 60;
> };
>
> Never caused any problems. The downside is that I use views and have to
> manage both sides.
Your scenario, presuming I understand it correctly, does not match what
I'm asking about.

I'll try to restate.

I want example.net to:
  - Follow all standard DNS best practices.
  - Delegate lab1.example.net to <something> using the same standard DNS
best practices.
  - <something>, which is publicly accessible, to host the public
version of the lab1.example.net zone.
  - <something(Else)>, which is not publicly accessible, to host the
private version of the lab1.example.net zone.

I want clients on the Internet, e.g. you, to be able to "dig +trace a
host.lab1.example.net" and get a proper DNS delegation chain from root
zone through net zone through example zone to lab1 zone on the external
publicly accessible DNS servers.

I want clients in the lab to be able to do the same "dig +trace a
host.lab1.example.net" and get a proper DNS delegation chain from root
zone through net zone through example zone to lab1 zone on the internal
private accessible DNS servers.

The difference is that the external publicly accessible lab1 DNS server
is a separate server from the internal private accessible lab1 DNS
server.  Separate in the sense that external can be a zone on a VPS
server and the internal being an isolated VM in the lab.  More
specifically, external public and internal private are NOT even remotely
the same system thus can't use views or multiple instances of BIND.

E:  "." ({a..m}.root-servers.net) -> "net." ({a..m}.root-servers.net) ->
"example.net." (ns{1,2}.example.net) -> lab1.example.net
(extns{1,2}.lab1.example.net)
I:  "." ({a..m}.root-servers.net) -> "net." ({a..m}.root-servers.net) ->
"example.net." (ns{1,2}.example.net) -> lab1.example.net
(intns{a,b}.lab1.example.net)

As I type the previous lines, I think that the delegation from
example.net to lab1.example.net will need to be to the same named &
addressed servers.  However, the external and internal servers for
lab1.example.net are completely different systems and could easily be in
different parts of the Internet / country / world.

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 private accessible.

I don't see another way to delegate the same zone to different (sets of)
name servers without using anycast.  Hence my email to the list asking
if anyone had any suggestions.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bob Harold

On Wed, May 6, 2020 at 3:28 PM Grant Taylor via bind-users <[hidden email]> 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 people
think the proper method is.

> 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.

It looks like your domain is delegated to Gratis DNS servers and that
they resolve specific records to your external IP.

I'm not seeing a delegation beyond that.  But that could simply be
because I don't know what name to query.  (AXFRs are properly refused.)

> The internal versions have RFC1812 IPs and the outside ones have public IPs.
>
> Both sides are signed by the same key.
>
> The way this is organised is that I use two views, one internal and one
> external, I set both to be signed using:
>
> options {
> directory "/var/named/data";
> auth-nxdomain no;
> dnssec-enable yes;
> dnssec-validation auto;
> allow-query { any; };
> allow-transfer { any; };
> listen-on-v6  { any; };
> sig-validity-interval 30 20;
> dnssec-loadkeys-interval 60;
> };
>
> Never caused any problems. The downside is that I use views and have to
> manage both sides.

Your scenario, presuming I understand it correctly, does not match what
I'm asking about.

I'll try to restate.

I want example.net to:
  - Follow all standard DNS best practices.
  - Delegate lab1.example.net to <something> using the same standard DNS
best practices.
  - <something>, which is publicly accessible, to host the public
version of the lab1.example.net zone.
  - <something(Else)>, which is not publicly accessible, to host the
private version of the lab1.example.net zone.

I want clients on the Internet, e.g. you, to be able to "dig +trace a
host.lab1.example.net" and get a proper DNS delegation chain from root
zone through net zone through example zone to lab1 zone on the external
publicly accessible DNS servers.

I want clients in the lab to be able to do the same "dig +trace a
host.lab1.example.net" and get a proper DNS delegation chain from root
zone through net zone through example zone to lab1 zone on the internal
private accessible DNS servers.

The difference is that the external publicly accessible lab1 DNS server
is a separate server from the internal private accessible lab1 DNS
server.  Separate in the sense that external can be a zone on a VPS
server and the internal being an isolated VM in the lab.  More
specifically, external public and internal private are NOT even remotely
the same system thus can't use views or multiple instances of BIND.

E:  "." ({a..m}.root-servers.net) -> "net." ({a..m}.root-servers.net) ->
"example.net." (ns{1,2}.example.net) -> lab1.example.net
(extns{1,2}.lab1.example.net)
I:  "." ({a..m}.root-servers.net) -> "net." ({a..m}.root-servers.net) ->
"example.net." (ns{1,2}.example.net) -> lab1.example.net
(intns{a,b}.lab1.example.net)

As I type the previous lines, I think that the delegation from
example.net to lab1.example.net will need to be to the same named &
addressed servers.  However, the external and internal servers for
lab1.example.net are completely different systems and could easily be in
different parts of the Internet / country / world.

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 private accessible.

I don't see another way to delegate the same zone to different (sets of)
name servers without using anycast.  Hence my email to the list asking
if anyone had any suggestions.



--
Grant. . . .
unix || die

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 that can make the "example.net" zone harder to manage.
It would be easier to have a split view for "split.example.net" and lab zones "lab#.split.example.net", if the extra level was acceptable.

-- 
Bob Harold


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
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 and external views are on
different servers with completely different IPs?

I ask because now you're back to the same issue, just at the parent
domain:  How does the net zone delegate to different example zones
depending on if the client is internal or external.

I don't see any options that avoid anycast.

> But that can make the "example.net" zone harder to manage. It would
> be easier to have a split view for "split.example.net" and lab zones
> "lab#.split.example.net", if the extra level was acceptable.
Please elaborate on what you mean by "split view" hear.  I'm used to
"split view DNS" being tantamount to what I would use views for.  Which,
as previously stated, won't work in this case because the different
views are hosted on different servers.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Sten Carlsen

-- 
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 <[hidden email]> wrote:

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 and external views are on different servers with completely different IPs?

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.


I ask because now you're back to the same issue, just at the parent domain:  How does the net zone delegate to different example zones depending on if the client is internal or external.

I don't see any options that avoid anycast.

But that can make the "example.net" zone harder to manage. It would
be easier to have a split view for "split.example.net" and lab zones "lab#.split.example.net", if the extra level was acceptable.
Please elaborate on what you mean by "split view" hear.  I'm used to "split view DNS" being tantamount to what I would use views for.  Which, as previously stated, won't work in this case because the different views are hosted on different servers.



--
Grant. . . .
unix || die

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

John Levine
In reply to this post by Bind-Users forum mailing list
In article <[hidden email]> 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
>different servers with completely different IPs?

Don't Do That.

>I ask because now you're back to the same issue, just at the parent
>domain:  How does the net zone delegate to different example zones
>depending on if the client is internal or external.
>
>I don't see any options that avoid anycast.

This really seems like ordinary split horizon DNS.

--
Regards,
John Levine, [hidden email], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
In reply to this post by Bind-Users forum mailing list
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 private accessible.

I have done a proof of concept of the anycast method and it does seem to
work correctly.

    --------
    internal% dig test.lab1.tnclab.net

    ; <<>> DiG 9.10.6 <<>> test.lab1.tnclab.net
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23882
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;test.lab1.tnclab.net. IN A

    ;; ANSWER SECTION:
    test.lab1.tnclab.net. 3600 IN A 192.0.2.1

    ;; Query time: 39 msec
    ;; SERVER: REDACTED
    ;; WHEN: Wed May 06 14:18:10 MDT 2020
    ;; MSG SIZE  rcvd: 65
    --------



    --------
    external% dig test.lab1.tnclab.net

    ; <<>> DiG 9.12.3-P4 <<>> test.lab1.tnclab.net
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63790
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ; COOKIE: 5fc29c39df72cceab05aca3f5eb31d230e6f902042ae0ee9 (good)
    ;; QUESTION SECTION:
    ;test.lab1.tnclab.net. IN A

    ;; AUTHORITY SECTION:
    lab1.tnclab.net. 300 IN SOA hidden-soa.lab1.tnclab.net.
gtaylor.tnetconsulting.net. 2017072101 3600 1800 2419200 3600

    ;; Query time: 390 msec
    ;; SERVER: REDACTED
    ;; WHEN: Wed May 06 20:25:07 UTC 2020
    ;; MSG SIZE  rcvd: 150
    --------



    --------
    internal% dig +trace test.lab1.tnclab.net

    ; <<>> DiG 9.10.6 <<>> +trace test.lab1.tnclab.net
    ;; global options: +cmd
    . 518400 IN NS e.root-servers.net.
    . 518400 IN NS m.root-servers.net.
    . 518400 IN NS i.root-servers.net.
    . 518400 IN NS a.root-servers.net.
    . 518400 IN NS j.root-servers.net.
    . 518400 IN NS c.root-servers.net.
    . 518400 IN NS b.root-servers.net.
    . 518400 IN NS g.root-servers.net.
    . 518400 IN NS d.root-servers.net.
    . 518400 IN NS h.root-servers.net.
    . 518400 IN NS f.root-servers.net.
    . 518400 IN NS k.root-servers.net.
    . 518400 IN NS l.root-servers.net.
    . 518400 IN RRSIG NS 8 0 518400 20200519170000 20200506160000
48903 . OD2b8PqZD5hfvqfK8fpR/1LdfzXU+WRG5cTgZdpuA8/GAba1oP5/6HPK
mzOHTuU7MpLI7u8TIJNd/NtvrZ/1cC6NO+olIu3umCcxte0PJqgxZGSK
0eFaFHrbjBwJd509MnjuZlhdBSGGuS2uD0fdyquZecor+pVQUfTCYCdI
T8w1+F8OmkNfd2F2FUZYq2bBXOJMtgGuyHOo0RHogVQJOw58fDjMWXtS
nMjs+0Lkk/Lh2ZB8tXUnunBM7CrincaLhxQf2Ez9rQS3UeOd5jJAWYMo
V57A5O5FsGJo41vvrS4+Sh10Frk+3sdWwLvCzPPuH/eHsGtdEq8KSfTG a2IC4w==
    ;; Received 1109 bytes from 198:18:18::254#53(198:18:18::254) in 38 ms

    net. 172800 IN NS a.gtld-servers.net.
    net. 172800 IN NS b.gtld-servers.net.
    net. 172800 IN NS c.gtld-servers.net.
    net. 172800 IN NS d.gtld-servers.net.
    net. 172800 IN NS e.gtld-servers.net.
    net. 172800 IN NS f.gtld-servers.net.
    net. 172800 IN NS g.gtld-servers.net.
    net. 172800 IN NS h.gtld-servers.net.
    net. 172800 IN NS i.gtld-servers.net.
    net. 172800 IN NS j.gtld-servers.net.
    net. 172800 IN NS k.gtld-servers.net.
    net. 172800 IN NS l.gtld-servers.net.
    net. 172800 IN NS m.gtld-servers.net.
    net. 86400 IN DS 35886 8 2
7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE
    net. 86400 IN RRSIG DS 8 1 86400 20200519170000 20200506160000
48903 . t7tjxOQhUoE6+VRIPH1U4fVOf6PZ+zsNFky80lrmCMYHJ6YPwo7pwY5n
Fp5GbEC9JcdrcFjpa+NbanTw5RFgWiukZT5AQANZ966ZegyA6tUwaNTV
9L90194vvQDcHNaQznftw4PpcQ0lNNETUswFm1lzv6GGs9iNFjjba459
XXTGYq9voALC8AfySPANp49fWteXPG0YvA0Fu/T+2IooyFwRwiDxEhpQ
49IVwVJZB3CimeL1kmP0nfP4/dxtj0OXhg+0S7gNX+HKf6gopVvtkfVs
AuZZkYRdderRh4mqc1tyK2QIH7QvO8xpzc7ruWVMjNjpKQ6GICGs0inS XLC5tA==
    ;; Received 1177 bytes from 192.203.230.10#53(e.root-servers.net) in
32 ms

    tnclab.net. 172800 IN NS ns1.linode.com.
    tnclab.net. 172800 IN NS ns2.linode.com.
    tnclab.net. 172800 IN NS ns3.linode.com.
    tnclab.net. 172800 IN NS ns4.linode.com.
    tnclab.net. 172800 IN NS ns5.linode.com.
    tnclab.net. 86400 IN DS 45760 8 1
FF5960A7A1CA8F1C94125BA8F471A828738C046F
    tnclab.net. 86400 IN DS 45760 8 2
2E3CDCAD213387EA611A7B368E37D259811DB75371CBB4F2831F89D4 B6014A57
    tnclab.net. 86400 IN RRSIG DS 8 2 86400 20200513064718
20200506053718 36059 net.
2yGFlsfpeXC8ID7mh1fVzwrBy7X9Y9fk9sw66Yy8ZqiM20mRCzhf0Fuh
cQGrZRBP4QA65bP1NWc3m5dTV/R0K8ZxDjw4dHMWwmp8e78BRi+CqPzC
ZxSVGBO9WlKKoL9jIvfOUkqQU+YEVEriXe2vMk4DmWT+5yjECjWLMPz3
ExeU1HebMZy6uA4CRueicnzBEkAKN5YJfpPnZdRuq53fnQ==
    ;; Received 428 bytes from
2001:503:231d::2:30#53(b.gtld-servers.net) in 207 ms

    lab1.tnclab.net. 3600 IN NS acns.tnclab.net.
    lab1.tnclab.net. 3600 IN NSEC tnclab.net. NS RRSIG NSEC
    lab1.tnclab.net. 3600 IN RRSIG NSEC 8 3 3600 20200605194430
20200506184430 18336 tnclab.net.
zmBPhbAJpJTPXIFIk3B57vtPnRqqZ6xYbVwQY2V3o14pHxqy8kjHL0QW
ZPoUCoXmzQ1yRPp8rMlDR6mp/6gNbejN2VSUtlbERnJLns08786LSCsd
oRieCphgsJLZPOKcL9FBa2rKSwp4QOlZdWid91eu+68l359X8TZeInHi xRw=
    ;; Received 456 bytes from
2400:cb00:2049:1::a29f:1827#53(ns2.linode.com) in 99 ms

    test.lab1.tnclab.net. 3600 IN A 192.0.2.1
    ;; Received 65 bytes from 45.33.28.7#53(acns.tnclab.net) in 1 ms
    --------



    --------
    external% dig +trace test.lab1.tnclab.net

    ; <<>> DiG 9.12.3-P4 <<>> +trace test.lab1.tnclab.net
    ;; global options: +cmd
    . 164357 IN NS e.root-servers.net.
    . 164357 IN NS f.root-servers.net.
    . 164357 IN NS k.root-servers.net.
    . 164357 IN NS h.root-servers.net.
    . 164357 IN NS b.root-servers.net.
    . 164357 IN NS j.root-servers.net.
    . 164357 IN NS l.root-servers.net.
    . 164357 IN NS g.root-servers.net.
    . 164357 IN NS m.root-servers.net.
    . 164357 IN NS a.root-servers.net.
    . 164357 IN NS d.root-servers.net.
    . 164357 IN NS c.root-servers.net.
    . 164357 IN NS i.root-servers.net.
    . 164357 IN RRSIG NS 8 0 518400 20200515050000 20200502040000
48903 . dGTnT7OISNAcz0hcLgOXqLpvSAMJBWDpi1XSSvWpVekIo3ZOwfOHqMdJ
DcZlGtmC4QfU7YXJi9LBVdCI57v9AbL8uyOJhCFVPmmjXoZvijZ9toPd
Ou0YMdBQG2y5ToXinStHcZGeICNUYpwPyuNs+ulK7smJd7Co4N5y5V3t
V+SO9wmVQNou3TIrUUX6KQ7DmyPBmoFIs24wy4NeQ/q547QZgSff7LUP
5rJMwxQhPwy3V3FcaMSbJfHFu5uO3WIHXS98i6HNVw/8G02xhHsTBtj3
NVsXzOB1Wfu4NERzka+Tle53jeK4TZnGWdXldnw4/729RVVVpfF4KpGt j3UQpw==
    ;; Received 565 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

    net. 172800 IN NS l.gtld-servers.net.
    net. 172800 IN NS b.gtld-servers.net.
    net. 172800 IN NS c.gtld-servers.net.
    net. 172800 IN NS d.gtld-servers.net.
    net. 172800 IN NS e.gtld-servers.net.
    net. 172800 IN NS f.gtld-servers.net.
    net. 172800 IN NS g.gtld-servers.net.
    net. 172800 IN NS a.gtld-servers.net.
    net. 172800 IN NS h.gtld-servers.net.
    net. 172800 IN NS i.gtld-servers.net.
    net. 172800 IN NS j.gtld-servers.net.
    net. 172800 IN NS k.gtld-servers.net.
    net. 172800 IN NS m.gtld-servers.net.
    net. 86400 IN DS 35886 8 2
7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE
    net. 86400 IN RRSIG DS 8 1 86400 20200519170000 20200506160000
48903 . t7tjxOQhUoE6+VRIPH1U4fVOf6PZ+zsNFky80lrmCMYHJ6YPwo7pwY5n
Fp5GbEC9JcdrcFjpa+NbanTw5RFgWiukZT5AQANZ966ZegyA6tUwaNTV
9L90194vvQDcHNaQznftw4PpcQ0lNNETUswFm1lzv6GGs9iNFjjba459
XXTGYq9voALC8AfySPANp49fWteXPG0YvA0Fu/T+2IooyFwRwiDxEhpQ
49IVwVJZB3CimeL1kmP0nfP4/dxtj0OXhg+0S7gNX+HKf6gopVvtkfVs
AuZZkYRdderRh4mqc1tyK2QIH7QvO8xpzc7ruWVMjNjpKQ6GICGs0inS XLC5tA==
    ;; Received 1177 bytes from 2001:500:2f::f#53(f.root-servers.net) in
1 ms

    tnclab.net. 172800 IN NS ns1.linode.com.
    tnclab.net. 172800 IN NS ns2.linode.com.
    tnclab.net. 172800 IN NS ns3.linode.com.
    tnclab.net. 172800 IN NS ns4.linode.com.
    tnclab.net. 172800 IN NS ns5.linode.com.
    tnclab.net. 86400 IN DS 45760 8 1
FF5960A7A1CA8F1C94125BA8F471A828738C046F
    tnclab.net. 86400 IN DS 45760 8 2
2E3CDCAD213387EA611A7B368E37D259811DB75371CBB4F2831F89D4 B6014A57
    tnclab.net. 86400 IN RRSIG DS 8 2 86400 20200513064718
20200506053718 36059 net.
2yGFlsfpeXC8ID7mh1fVzwrBy7X9Y9fk9sw66Yy8ZqiM20mRCzhf0Fuh
cQGrZRBP4QA65bP1NWc3m5dTV/R0K8ZxDjw4dHMWwmp8e78BRi+CqPzC
ZxSVGBO9WlKKoL9jIvfOUkqQU+YEVEriXe2vMk4DmWT+5yjECjWLMPz3
ExeU1HebMZy6uA4CRueicnzBEkAKN5YJfpPnZdRuq53fnQ==
    ;; Received 428 bytes from 192.43.172.30#53(i.gtld-servers.net) in 7 ms

    lab1.tnclab.net. 3600 IN NS acns.tnclab.net.
    lab1.tnclab.net. 3600 IN NSEC tnclab.net. NS RRSIG NSEC
    lab1.tnclab.net. 3600 IN RRSIG NSEC 8 3 3600 20200605194430
20200506184430 18336 tnclab.net.
zmBPhbAJpJTPXIFIk3B57vtPnRqqZ6xYbVwQY2V3o14pHxqy8kjHL0QW
ZPoUCoXmzQ1yRPp8rMlDR6mp/6gNbejN2VSUtlbERnJLns08786LSCsd
oRieCphgsJLZPOKcL9FBa2rKSwp4QOlZdWid91eu+68l359X8TZeInHi xRw=
    ;; Received 456 bytes from 162.159.24.25#53(ns5.linode.com) in 74 ms

    lab1.tnclab.net. 300 IN SOA hidden-soa.lab1.tnclab.net.
gtaylor.tnetconsulting.net. 2017072101 3600 1800 2419200 3600
    ;; Received 119 bytes from 45.33.28.7#53(acns.tnclab.net) in 102 ms
    --------

45.33.28.7 is anycasted in that it exists globally on one of my VPSs and
in my lab enviornment.  (No BGP involved with this anycast.)



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
In reply to this post by Sten Carlsen
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 outside of the zone's scope, thus not (potentially) included in
the additional information section, which could massively mess with that.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
In reply to this post by John Levine
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 understanding of it differs from what your
understanding seems to be.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Sten Carlsen
In reply to this post by Bind-Users forum mailing list

Thanks

Sten

On 6 May 2020, at 22.28, Grant Taylor via bind-users <[hidden email]> 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 different servers.

If I understand correctly, that would rely on the DNS server's FQDNs being outside of the zone's scope, thus not (potentially) included in the additional information section, which could massively mess with that.

Yes or being answered from your own servers with dat depending on your location.




--
Grant. . . .
unix || die

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
In reply to this post by Bind-Users forum mailing list
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 from a system in it.

Further, the external publicaly accessible DNS servers exist elsewhere
on the Internet to provide just enough zone content to make delegation
happy.

Perhaps the external publicaly accessible parent example.net can
(blindly) delegate zones to internal private DNS servers.  However I
dislike this because I believe it leaves things in an unclean state for
people on the Internet a large.  At the very least it means no route to
host errors at best or at worst timeouts.

Conversly, what I'm working on will immediately and successfully return
a response of NXDOMAIN.  Something that I think is cleaner for the
Internet at large.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

John Levine
In reply to this post by Bind-Users forum mailing list
In article <[hidden email]> 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 the client IP, so
on your internal network it sees the private subdomain, everywhere
else sees a ENT or NXDOMAIN.

If you really have to use physically separate servers for reasons that
you can't explain, I suppose putting the two servers at the same IP
addresss facing different networks could work, although you're asking
for trouble with route leaks anytime someone adjusts a router anywhere
near one or the other.  Remember that with normal anycast all of the
mirrors send identical or at least equivalent answers so the routes
are not a security issue.

--
Regards,
John Levine, [hidden email], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

John Levine
In reply to this post by Bind-Users forum mailing list
In article <[hidden email]> 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, the outside world can
>never query something from a system in it.

Can clients on the internal network contact hosts in the outside world,
or is it really disconnected?

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
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, much less the Internet.  (Some of them even have a protocol
barrier.)

(IPv4 network)---[IPv4|bastion|IPX]---(IPX
network)---[IPX|router|IPX]---(IPX network)---[IPX|bastion|IPv6]---(IPv6
network)

Nothing IPv4 in the lab is going to make it out to the world.

The IPX router hard filters anything that's not IPX.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
In reply to this post by John Levine

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 given the difference in what you were describing and
what I was thinking, I figured that it was worth confirming.

> If you really have to use physically separate servers for reasons
> that you can't explain,...

There's not anything stopping me from explaining.

The main network I want dig +trace to behave (as) correctly (as
possible) is inside the labs.  (Obviously tracing won't work without
some support infrastructure on the disconnected labs.)

The external server is more to make the delegation into the labs look as
clean as possible to the rest of the world.  I.e. return NXDOMAIN
instead of timeouts.

In some ways, the external aspect is somewhat optional, save for the
desire to lay nice with others.

I'd like to consistently re-use the same method across all labs,
independent if they are isolated or not, both internally and externally.

> ...I suppose putting the two servers at the same IP addresss facing
> different networks could work,

Hence "anycast".

> although you're asking for trouble with route leaks anytime someone
> adjusts a router anywhere near one or the other.

In general, I agree with you.  However, in this particular case, I don't
think it's going to be an issue.  The router inside the lab is not using
any routing protocols, only static configs.  The router can get the
local traffic to the anycast IP without worrying about anything
escaping.  (Be it on the router w/ local DNS server, or directly
attached network, or a host route to another system that is directly
attached.)

I'm taking your warning, processing it, and then deciding that this
particular scenario is not subject to the concerns you rightfully have.

> Remember that with normal anycast all of the mirrors send identical
> or at least equivalent answers so the routes are not a security
> issue.
Agreed.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

John Levine
In reply to this post by Bind-Users forum mailing list
In article <[hidden email]> 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 labs will NOT have access to other
>networks, much less the Internet.  (Some of them even have a protocol
>barrier.)

Since they can't access the root servers, how do you expect them to
do DNS lookups at all?

R's,
John
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list

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 labs.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

John Levine
In reply to this post by Bind-Users forum mailing list
In article <[hidden email]> 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 obviously not in play with doctored zones in the labs.

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.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: What is the proper way to delegate to a private / hidden sub-domain?

Bind-Users forum mailing list
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 was missing that didn't require
anycast for proper delegation.  But I'm not seeing anything else.



--
Grant. . . .
unix || die


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

smime.p7s (5K) Download Attachment