5 ms·

Number one reason that comes to mind is you prevent the possibility of information leakage. You can't screw up your split-dns configuration and end up leaking y

Number one reason that comes to mind is you prevent the possibility of information leakage. You can't screw up your split-dns configuration and end up leaking your internal IP space if everything is .internal. It's much the same reason why some very large IPv6 services deploy some protected IPv6 space in RFC4193 FC::/7 space. Of course you have firewalls. And of course you have all sorts of layers of IDS and air-gaps as appropriate. But, if by design you don't want to make this space reachable outside the enterprise - the extra steps are a belt and suspenders approach. So, even if I mess up my firewall rules and do leak a critical control point: FD41:3165:4215:0001:0013:50ff:fe12:3456 - you wouldn't be able to route to it anyways. Same thing with .internal - that will never be advertised externally.

deleted 2y ago
[deleted]
nox101 2y ago
What about things like cookies, storage, caching, etc.. If my job has `https://testing.internal https://testing.internal` and some company I visit also has `https://testing.internal https://testing.internal` ...
- dudus 2y ago
  Great question. I think they leak but this happens regardless.
- kelnos 2y ago
  Presumably you don't trust the CA that signed the certificate on the server at the company you're visiting. As long as you heed the certificate error and don't visits the site, you're fine.
  - hsbauauvhabzb 2y ago
    So we’re back to trusting the user?
    - 0l 2y ago
      Use HSTS, browsers are specifically designed not to let users bypass these.
      - hsbauauvhabzb 2y ago
        Hsts forces encryption, it has no impact on certificate invalidity, at least to my knowledge.
        0l 2y ago
        Visit your .internal site -> website uses TLS cert signed by root CA that is preloaded on your device. Succeeds and HSTS flag is set. Visit other .internal site -> uses TLS cert NOT signed by root CA that is preloaded on your device -> certificate error, and cannot be bypassed due to HSTS.
  - thayne 2y ago
    Now suppose you are a contractor who did some work for company A, then went to do some work for company B, and still have some cookies set from A's internal site.
- thebeardisred 2y ago
  May god have mercy on the person using this in their mobile applications.
- mrkstu 2y ago
  I'm assuming you wouldn't import their CA as authoritative just to use their wifi...
- fulafel 2y ago
  Yep, ambiguous addressing doesn't save you, same as 10.x IPv4 networks. And one day you'll need to connect or merge or otherwise coexist with disparate uses if it's a common one (like in .internal and 10.x)...
  - kevincox 2y ago
    IPv6 solves this as you are strongly recommend to use a random component at the top of the internal reserved space. So the chance of a collision is quite low.
    - pas 2y ago
      there's some list of ULA ranges allocated to organizations, no? edit: ah, unfortunately it's not really standard, just a grassroots effort https://ungleich.ch/u/projects/ipv6ula/ https://ungleich.ch/u/projects/ipv6ula/
    - fulafel 2y ago
      There's usually little reason to use reserved space vs internet addresses, unless you just want to relive the pain of NAT+IPv4. The exception is if you lack PI space and can't copy with potential renumbering.
      - ghshephard 2y ago
        I've deployed/managed over 25 million production elements in RFC4193 space. These elements ((mostly mesh networking nodes for utilities) ), by definition, should never route to the internet. (According to NERC CIP they shouldn't even route beyond the substation for distribution elements). Non routability was a design feature. I've been out of Enterprise IT for 15 years - but if I was going to do an IPv6 deployment today - I would strongly consider NAT6 prefix replacement - it offers 90% of the benefits of native IPv6 addresses, doesn't conflate "security" and "flexibility" (prefix replacement is just a straight 1:1 passthrough - globally routable) - and who want to go update all their router configs and DNS every time they change their upstream. Ugh.
- viraptor 2y ago
  Ideally, you use "testing.company-name.internal" for that kind of things. (Especially if you think you'll ever end up interacting at that level)
- mrighele 2y ago
  I would expect ACME to use https://testing.acme.internal https://testing.acme.internal, and not just https://testing.internal https://testing.internal, that would remove most of the incidental clashes (not malicious ones, of course).

deleted 2y ago

[deleted]

nox101 2y ago

What about things like cookies, storage, caching, etc.. If my job has `https://testing.internal https://testing.internal` and some company I visit also has `https://testing.internal https://testing.internal` ...

dudus 2y ago
Great question. I think they leak but this happens regardless.
kelnos 2y ago
Presumably you don't trust the CA that signed the certificate on the server at the company you're visiting. As long as you heed the certificate error and don't visits the site, you're fine.
- hsbauauvhabzb 2y ago
  So we’re back to trusting the user?
  - 0l 2y ago
    Use HSTS, browsers are specifically designed not to let users bypass these.
    - hsbauauvhabzb 2y ago
      Hsts forces encryption, it has no impact on certificate invalidity, at least to my knowledge.
      - 0l 2y ago
        Visit your .internal site -> website uses TLS cert signed by root CA that is preloaded on your device. Succeeds and HSTS flag is set. Visit other .internal site -> uses TLS cert NOT signed by root CA that is preloaded on your device -> certificate error, and cannot be bypassed due to HSTS.
- thayne 2y ago
  Now suppose you are a contractor who did some work for company A, then went to do some work for company B, and still have some cookies set from A's internal site.
thebeardisred 2y ago
May god have mercy on the person using this in their mobile applications.
mrkstu 2y ago
I'm assuming you wouldn't import their CA as authoritative just to use their wifi...
fulafel 2y ago
Yep, ambiguous addressing doesn't save you, same as 10.x IPv4 networks. And one day you'll need to connect or merge or otherwise coexist with disparate uses if it's a common one (like in .internal and 10.x)...
- kevincox 2y ago
  IPv6 solves this as you are strongly recommend to use a random component at the top of the internal reserved space. So the chance of a collision is quite low.
  - pas 2y ago
    there's some list of ULA ranges allocated to organizations, no? edit: ah, unfortunately it's not really standard, just a grassroots effort https://ungleich.ch/u/projects/ipv6ula/ https://ungleich.ch/u/projects/ipv6ula/
  - fulafel 2y ago
    There's usually little reason to use reserved space vs internet addresses, unless you just want to relive the pain of NAT+IPv4. The exception is if you lack PI space and can't copy with potential renumbering.
    - ghshephard 2y ago
      I've deployed/managed over 25 million production elements in RFC4193 space. These elements ((mostly mesh networking nodes for utilities) ), by definition, should never route to the internet. (According to NERC CIP they shouldn't even route beyond the substation for distribution elements). Non routability was a design feature. I've been out of Enterprise IT for 15 years - but if I was going to do an IPv6 deployment today - I would strongly consider NAT6 prefix replacement - it offers 90% of the benefits of native IPv6 addresses, doesn't conflate "security" and "flexibility" (prefix replacement is just a straight 1:1 passthrough - globally routable) - and who want to go update all their router configs and DNS every time they change their upstream. Ugh.
viraptor 2y ago
Ideally, you use "testing.company-name.internal" for that kind of things. (Especially if you think you'll ever end up interacting at that level)
mrighele 2y ago
I would expect ACME to use https://testing.acme.internal https://testing.acme.internal, and not just https://testing.internal https://testing.internal, that would remove most of the incidental clashes (not malicious ones, of course).