On 11/13/21 9:07 AM, Reindl Harald wrote:
but you have to deal with it
And? So?We have to deal with all sorts of things. The need to do our job is not a reason in and of itself a reason to not do it.
you missed my second post!
No, order of reply vs reading.
* he needs the delegation because lack of control
Maybe I've lost context, but I thought the overall theme of the thread was delegating to a private IP address.
* when the clients network is using a public forwarder the delegation simply can't work
My thought was around three DNS servers. 1) Company A's local DNS server. 2) Company B's local DNS server.3) Public DNS hierarchy which delegates A's domain to a private IP in A's LAN.
If there is a VPN between company A and company B, then client's on company B's LAN will use company B's local recursive DNS server. B's recursive DNS server will receive the delegation from 3 to 1, traverse the VPN to talk to A. Thus 2 will be able to resolve something delegated to A's DNS server with private IP.
* so the problem is lack of control and can't be solvedpersonally i would simply add additional names point to the LAN addresses in my normal public zone, you don't even need a full subdomain zone for add "something.priv.example.com" poining to 192.168.196.10------------and not to forget: most networks are forwarding to some public nameserver which can't reach your private named at all
I don't view -- what I consider to be -- questionable practice to be a valid reason to not do something. A *LOT* of people smoked in the mid 19th century, and that's turned out to be not as good as once thought.
I would advocate for businesses to have their own LAN based DNS servers that are authoritative for their own zone(s) and recursive for other zones. If people want, they can have their local DNS server forward the recursive responsibility elsewhere.
In some ways this thread is a re-hash of the venerable "Why can't Google DNS figure out my private Active Directory? ... But WHY?!?!?!".
-- 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
