4 ms·
Devil's advocate: using an Internet-public domain for internal purposes will publicly expose your internal hostnames if you enable DNSSEC on the Internet-public
by solatic 3y ago
Devil's advocate: using an Internet-public domain for internal purposes will publicly expose your internal hostnames if you enable DNSSEC on the Internet-public domain. This is a problem if you're required to enable DNSSEC, e.g. for FedRAMP compliance.
The number of cases where this is actually a legitimate concern, IMO, is extremely small, and I'm personally of the opinion that using Internet-public domains for internal purposes is generally fine. But it's still important to point out that the number of cases is not zero.
- akdev1l 3y agoYou can use a public domain but a local/private DNS server
- INTPenis 3y agoI believe the advice about using a TLD you control outside and inside is mostly to prevent takeover on the outside that could affect the inside. But you can still have completely separate DNS for the inside. Using a shared DB for both would probably be recommended to avoid conflicts.
- eqvinox 3y ago> expose your internal hostnames if you enable DNSSEC Zone content enumeration in DNSsec was fixed by NSEC3 records (RFC5155, March 2008)
- tptacek 3y agoNo it wasn't! NSEC3 is crackable the same way a 1990s Unix password file is. This was such a big problem that two competing approaches were introduced to defeat it: "whitelies", which I perceive as the "best practices standard" answer, requires servers to operate as online signers (they should have been all along) so they can generate dynamic chaff records to foil enumeration, and NSEC5.
- eqvinox 3y agoHmm. Interesting. I wasn't aware of that, thanks! … also, https://github.com/CyberCX-STA/NSEC-3-Walker https://github.com/CyberCX-STA/NSEC-3-Walker …
- tptacek 3y agoEvery security auditor in ever regs regime will flag zone transfers.