Do not check DNS when Topology is Private

[icereval]

Based on @billyshambrook PR #810 and conversation.

I was not 100% certain how to implement @justinsb comments but wanted to give this an attempt using the new --topology private settings.

Preference on the name? DNS = public or private

The feature (or similar) would certainly be useful in our configurations where <env>.company.internal designation is typically used.

---

This change is 

[k8s-ci-robot]

Can a kubernetes member verify that this patch is reasonable to test? If so, please reply with "@k8s-bot ok to test" on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands will still work. Regular contributors should join the org to skip this step.

If you have questions or suggestions related to this bot's behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[chrislovecnm]

@justinsb I think u want to leave this one pending you API refactoring?

[chrislovecnm]

Just to let you know this #1183 will probably impact this PR. I appreciate your patience, and help! This PR is a big change that has some huge benefits.

[chrislovecnm]

We need a rebase :) See #1206 as well

[chrislovecnm]

Did you follow this as well: https://github.com/kubernetes/kops/blob/master/docs/development/api_updates.md?

It is fresh off of the press, so I do not know if you did.

Also @justinsb wants to review all of the API changes, for the time bit. I am going to assign this to him.

Again thanks for your patience as we move to k8s api machinery code. The benefits are super exciting!

Going to have @justinsb review

[icereval]

It should be correct this time around, added it to the previous api version files per the doc and ran make apimachinery (no conversions needed, assuming omit empty).

Thanks for the guide! 🏑

[chrislovecnm]

@justinsb can u review please

[justinsb]

Incidentally, as this compares to #1264, that PR is just getting private hosted zones working (and they do work), without addressing the issues of what they should look like.

The remaining questions for me (which I think will determine the schema):

1. Would we want to expose the API (or bastions) on a different (public) DNS name? Or do we assume that there already exists e.g. OpenVPN connectivity.
2. Should we have a separate configuration in the topology section for how to expose the API. Ways I can see: DNS -> master IPs, ELB, Ingress. This is a separate but related question, IMO. Going to try prototyping it!

[chrislovecnm]

We need a rebase, and any updates on @justinsb comments?

[icereval]

With the feature flag implemented I'll just close this PR.

My two cents,

1. Production case a Bastion would likely exist and the admin would be using KOPS to deploy the cluster in the desired secure topology, needing enough hooks to orchestrate the integration (e.g. terraform cluster outputs -> bastion terraform inputs). On the other hand I do think its great to include the simple Bastion as you are doing now so users can effortlessly experience a secure cluster when experimenting.
2. Not sure.