On 04/03/2018 05:24 PM, Browne, Stuart via bind-users wrote:
A number of places use a 'stealth' (or 'hidden') master as a bit of protection from potential bad actors. It's a network domain barrier between the master (usually on an internal-only network) from a public network with potential bad actors.
I thought hidden master configurations did not include the MNAME server in any of the published NS records in the zone or registered with the registrar (or parent zone).
So, I don't see the MNAME being related to (poorly named?) "stealth" name servers if it's not included in either the published NS records or registered with the registrar (parent zone).
For example, a dynamic update for a zone will contact the mname defined in the SOA record unless told otherwise. If you watch your DNS traffic closely on a properly configured public authoritative server, you will see many failed dynamic updates.
There's opportunity to play with this traffic. }:-)I worked in a network that had a service name for the MNAME (mname.$zone) that was using (different) apex overrides on each server to cause mname.$zone to resolve to the local server. Said servers were configured to forward updates to the master server(s) that they were slaving zones from.
Doing this allowed Windows clients to send DDNS updates to the DNS server they could reach which would then forward them up the chain to the real master (which the clients could not reach). This actually worked out quite well and avoided a LOT of Windows / AD related indigestion.
-- 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
