4 ms·

There is no privacy issue here, there aren't source IP addresses attached, you can't tell who's looking these up. It's up there with Amazon's (for example) "oth

There is no privacy issue here, there aren't source IP addresses attached, you can't tell who's looking these up. It's up there with Amazon's (for example) "other people bought" recommendations, you can't tell who did the looking up. They're just domain names which are effectively public records. And even if you thought you registered a super secret domain name (no such thing), maybe the registrar looked it up, or some bot found it through brute force (if nslookup.io is open to bots).

hsbauauvhabzb 5y ago
What if someone looks up an internal domain which is actually publicly exposed. Granted they shouldn’t be secret, doesn’t mean you should broadcast them publicly.
- pul 5y ago
  Internal domains generally resolve to private IP ranges, so don't do any harm when broadcasted. Besides, many people use Chrome, and who knows what they do by default with browsing history.
  - hsbauauvhabzb 5y ago
    You’ve obviously never seen orgs with /16 IP ranges, or developers/ops accidentally screw up, for that matter. Chrome don’t actively publish nslookups on public sites. I think you’ve missed the point.
  - antonvs 5y ago
    Information leakage of any kind potentially gives an attacker something they can use. On its own any given piece of info may seem harmless, but when combined with other info it can start to pose a risk. Leaking internal hostnames could allow an attacker to build a view of an internal network ahead of time, before actual penetration. Once inside a network it's often a race against time, so this can make a difference.
weird-eye-issue 5y ago
I do understand all of that, still it feels weird to me. If I'm looking up a staging domain I'm not trying to broadcast that to the world, for example You know the Qualsys SSL Tester tool? That has a checkbox about making the result public or not and that is because by default people wouldn't expect the domain to be leaked (even though it's already public information that doesn't really matter)
- pul 5y ago
  It's a fair point, and I've thought about this when making the stats public. There are plenty domain enumeration tools out there. DNS data is inherently public, so I don't think one should rely on it for their security model.
- dwild 5y ago
  I agree with you completely. I just want to add for people that do care about domain privacy that there's many certificate provider that do publish the generated certificate over https://crt.sh/ https://crt.sh/ . I did find a few staging subdomains in the past on that website.
  - XCSme 5y ago
    As a side-note, as soon as I added some DNS A records pointing to a testing server, it started getting spammed by bots trying to hack into the server (accessing all sorts of random paths that might be exposed, like .env or common PHP files). Not sure what the solution to this is, apart from not adding DNS records for testing servers, maybe only allow access to the server from specific IPs? But that makes testing harder, if you send a link to someone with a dynamic IP.
    - pul 5y ago
      I'd be surprised if it was caused by adding the DNS record, and not for example you visiting the test site. In any case, sooner or later those attacks will come, so omitting a DNS A record won't cure it.

hsbauauvhabzb 5y ago

What if someone looks up an internal domain which is actually publicly exposed. Granted they shouldn’t be secret, doesn’t mean you should broadcast them publicly.

pul 5y ago
Internal domains generally resolve to private IP ranges, so don't do any harm when broadcasted. Besides, many people use Chrome, and who knows what they do by default with browsing history.
- hsbauauvhabzb 5y ago
  You’ve obviously never seen orgs with /16 IP ranges, or developers/ops accidentally screw up, for that matter. Chrome don’t actively publish nslookups on public sites. I think you’ve missed the point.
- antonvs 5y ago
  Information leakage of any kind potentially gives an attacker something they can use. On its own any given piece of info may seem harmless, but when combined with other info it can start to pose a risk. Leaking internal hostnames could allow an attacker to build a view of an internal network ahead of time, before actual penetration. Once inside a network it's often a race against time, so this can make a difference.

weird-eye-issue 5y ago

I do understand all of that, still it feels weird to me. If I'm looking up a staging domain I'm not trying to broadcast that to the world, for example You know the Qualsys SSL Tester tool? That has a checkbox about making the result public or not and that is because by default people wouldn't expect the domain to be leaked (even though it's already public information that doesn't really matter)

pul 5y ago
It's a fair point, and I've thought about this when making the stats public. There are plenty domain enumeration tools out there. DNS data is inherently public, so I don't think one should rely on it for their security model.
dwild 5y ago
I agree with you completely. I just want to add for people that do care about domain privacy that there's many certificate provider that do publish the generated certificate over https://crt.sh/ https://crt.sh/ . I did find a few staging subdomains in the past on that website.
- XCSme 5y ago
  As a side-note, as soon as I added some DNS A records pointing to a testing server, it started getting spammed by bots trying to hack into the server (accessing all sorts of random paths that might be exposed, like .env or common PHP files). Not sure what the solution to this is, apart from not adding DNS records for testing servers, maybe only allow access to the server from specific IPs? But that makes testing harder, if you send a link to someone with a dynamic IP.
  - pul 5y ago
    I'd be surprised if it was caused by adding the DNS record, and not for example you visiting the test site. In any case, sooner or later those attacks will come, so omitting a DNS A record won't cure it.