Re: What is the proper way to delegate to a private / hidden sub-domain?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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, 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 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, jo...@taugh.com, 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 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 > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users signature.asc Description: Message signed with OpenPGP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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.3600IN 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 2020051917 2020050616 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 2020051917 2020050616 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.
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 >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, jo...@taugh.com, 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
-- 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 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 > bind-users@lists.isc.org > 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 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 using the same standard DNS
> best practices.
> - , which is publicly accessible, to host the public
> version of the lab1.example.net zone.
> - , 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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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 using the same standard DNS
best practices.
- , which is publicly accessible, to host the public
version of the lab1.example.net zone.
- , 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
smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: What is the proper way to delegate to a private / hidden sub-domain?
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
> 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
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
What is the proper way to delegate to a private / hidden sub-domain?
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
