mattboyer / vast Goto Github PK

vast tries to map a given IP address to a an assigned subnet using RDAP and, if that fails, defaults to plain old nicname/whois on TCP port 43.

For 24.152.0.0, the initial RDAP lookup results in a redirect to a different RDAP server (ARIN -> LACNIC in this case), with the redirected query yielding an invalid JSON object. The resulting whois lookup is no better:

      INFO| vast.metadata.RDAP             -- RDAP query https://rdap.arin.net/registry/ip/24.152.0.0: 303
      INFO| vast.metadata.RDAP             -- RDAP query https://rdap.lacnic.net/rdap/ip/24.152.0.0: 404
      INFO| vast.metadata.resolver         -- Caught "RDAP resource not found: https://rdap.lacnic.net/rdap/ip/24.152.0.0". Trying whois
     DEBUG| vast.metadata.whois            -- Resolved "whois.arin.net" to ('199.212.0.46', 43)
      INFO| vast.metadata.whois            -- WHOIS query whois.arin.net
     ERROR| vast.metadata.resolver         -- Malformed Whois entry: ARIN's WHOIS service provides a mechanism for finding contact and registration
   WARNING| vast.tools.mapper              -- Couldn't resolve 24.152.0.0

In this case, we should pick the lookup that yielded the most information, that is to say at least a
prefix length, which in this case is the initial RDAP lookup against ARIN's server.

More broadly, we want to ensure that we avoid all cases where a sequence of more than one lookup results in a ResolutionException that could be avoided by keeping track of provisional assigned subnets throughout the redirect/failover process.

Allow traversing assigned subnets

There's a pretty obscene number of them.
Of course, I'll need unit test coverage to sensibly do that!