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

[Grant Taylor]

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.

[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

Post by Grant Taylor
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
https://lists.isc.org/mailman/listinfo/bind-users

[Grant Taylor]

Post by Sten Carlsen
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.

Post by Sten Carlsen
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.)

Post by Sten Carlsen
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
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.

[Bob Harold]

On Wed, May 6, 2020 at 3:28 PM Grant Taylor via bind-users <

Post by Grant Taylor

Post by Sten Carlsen
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.

Post by Sten Carlsen
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.)

Post by Sten Carlsen
The internal versions have RFC1812 IPs and the outside ones have public

IPs.

Post by Sten Carlsen
Both sides are signed by the same key.
The way this is organised is that I use two views, one internal and one
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.
- 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.

[Grant Taylor]

Post by Bob Harold
Good questions.

:-)

Post by Bob Harold
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.

Post by Bob Harold
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.

[John Levine]

Post by Grant Taylor

Post by Bob Harold
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.

Post by Grant Taylor
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.

[Sten Carlsen]

--
Best regards
Sten Carlsen


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

Post by Bob Harold
Good questions.

:-)

Post by Bob Harold
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.

Post by Bob Harold
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
https://lists.isc.org/mailman/listinfo/bind-users

[Grant Taylor]

Post by Grant Taylor
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 Taylor]

Post by Sten Carlsen
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 Taylor]

Post by John Levine
Don't Do That.

That's one of the hard requirements of what I'm doing. Not doing that
is not an option.

Post by John Levine
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.

[John Levine]

Post by Grant Taylor

Post by John Levine
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.

[Sten Carlsen]

Thanks

Sten

Post by Sten Carlsen
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
https://lists.isc.org/mailman/listinfo/bind-users

[Grant Taylor]

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.

[John Levine]

-=-=-=-=-=-

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?

[Grant Taylor]

Post by John Levine
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.

[John Levine]

-=-=-=-=-=-

Post by John Levine
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

[Grant Taylor]

Post by John Levine
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.

Post by John Levine
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.

Post by John Levine
...I suppose putting the two servers at the same IP addresss facing
different networks could work,

Hence "anycast".

Post by John Levine
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.

Post by John Levine
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 Taylor]

Post by John Levine
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.

[John Levine]

-=-=-=-=-=-

Post by John Levine
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.

[Grant Taylor]

Post by John Levine
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.