1. 28
  1.  

  2. 5

    I really like this guy’s tool that automatically maps out the delegation paths to find unregistered domains. Looking back at the systems I’ve interacted with, I think every one has had some kind of invariant like this that’s vital and set up properly in the beginning, and even though it could be automatically checked, it’s not, it’s undocumented or lost in the implication of some footnote. Years later, something’s vulnerable or broken because of it. Every system. It’s so easy to forget not knowing the invariant and skip over enforcing it.

    1. 2

      Preface: I’m bad at DNS. Way bad. :)

      Don’t the root nameservers who are authoritive for .IO maintain the A records in the root .IO zone file?

      His own dig output seems to point at this: after he registered ns-a1.io we saw:

      ns-a1.io. 172800 IN A 194.0.1.1

      That’s not his IP. That’s one of ICBs, the registrar that runs .IO.

      DNS traffic would never flow down to his box because the query for foo.io would go to a root nameserver authoritive for .io, which would hand back a domain name possibly owned by the attacker but an IP owned by the registrar.

      So even though they clearly fucked up, this isn’t what he claims it to be. Right?

      1. 1

        There’s another post making a similar point. https://mpounsett.blogspot.ca/2017/07/the-io-error-problem-with-bad-optics.html

        Although the author says he collected lots of queries? I guess he could make that up, but I think it’s also possible that not every resolver does exactly what we’d expect. I guess he could have redirected half of keybase.io traffic for a day to test, but that’s not a nice thing to do.