North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: 2008.02.20 NANOG 42 IPv4 PTR queries for unallocated space

  • From: David Conrad
  • Date: Wed Feb 20 15:28:28 2008


Just FYI:


Leo's email address is

<[email protected]>

Regards,
-drc

On Feb 20, 2008, at 10:34 AM, Matthew Petach wrote:


Notes from day 4 of NANOG 42, we're on the home stretch now, so there's only a bit more of my spewage to wade through before we can resume our normal discussion of the imminent death of the internet as we know it. :)

Again, apologies for typos, misspellings of names, etc.

Matt



2008.02.20 opening remarks and analysis of PTR
queries for IPv4 reserved addresses

Trying to measure use of unallocated IPv4 address
space

Starting with Leo Vigoda, working at IANA now.
[email protected]

At last NANOG, did lightning talk about how people
were using unallocated space, but didn't show lots
of data.

Now, has a way to hopefully measure IPv4 addresses
that people are trying to use.

Not all the addresses, but at least one view of it.

Problem?
All unallocated unicast space will eventually be
allocated; no more free /8's in the IANA pool at
some point, as v6 won't get rolled out in time.

Some people are using the same addres space that's
currently in the 'unallocated' pool.

Tried to measure it by looking at DNS queries at
l.root for addresses in the unallocated blocks.
root servers provide in-addr.arpa delegations,
if a /8 isn't allocated, there's no delegation,
so the root servers see the queries.

Can't measure well-maintained networks with
split-horizon DNS, or with good egress filters.

Doesn't know how to measure truly private
internal use; if you have ideas, let him know.

Results slide; long blue line at the far left,
lots and lots of queries, then shallows off to
the right side; some old rubbish names in in-addr
people are querying for.

Left side is the fun stuff.

222/8, allocated to APNIC; not sure why it gets
a lot more queries than the other /8's.  Could be
mail server lookups, since there's a lot of mail
that comes out of 222/8; could be one rogue server.
If you assume it's bogus, and chuck it out, data
'looks' better.
10/8 is near the top, as expected.
0/8 RFC3330
2/8 is unallocated; in the top 15 range.  Odd there's
unallocated space so close to the top of the queries
range.
If you take out all the unallocated stuff, there's
still a lot of entries; looking at top 10 list:
2/8, 1/8, 23/8, 5/8, 100/8 is there at #5, which
is odd.  the next /8's they *were* going to give
ARIN were 100/101, they decided to NOT give it
out to figure out why there's so many hits on it
in this round.

The top 10 list is the 30 day period ending sunday;
he also compared to statistics he used at the esNOG
meeting in madrid a few months ago.

Not very static; people leave top 10, new come on.

28dec-26jan, vs 19jan to 17feb

2/8 and 1/8 stay in #1 and #2
other /8s shift; 5/8 rises, 23/8 rises, 100/8
drops, 27/8 drops.

It's not static, there's movement, people are
shifting and shuffling blocks.

Not measuring the query source address and AS #
that could be gathered to inform people they're
trying to talk to unallocated space.

Only gathering from l.root, would be good to get
data from other root servers.

Leo's not a proper researcher, so would be good to
get skillset from a real researcher.

Would like to get data from nodes all over the
world to get more global information; can see if
there's more of a local component, or if this is
a global phenomenon.  This would be a very big
data analysis challenge, combining l, k, and other
root server operators, and get a more complete view
of the data.

Use it to either warn people, or help get things
fixed if at all possible.

Q: Louis Lee, Equinix, want to find out if they've
looked to see if the top10 prefixes are in the global
routing table when the queries come in?
A: No, that hasn't been looked at, but a proper
researcher would probably have considered and
tied that data in as well.

Q: Leo Bicknell, ISC: did they look at the source of
queries?  Are they all coming from a common
resolver?
A: no, not yet; would be the sort of thing that a
proper researcher would be able to dig into.
There are privacy considerations with looking at
sources of queries, etc; needs to be thought
through very carefully to make sure no per

Q: Keith Mitchell, Interesting work, thanks Leo;
there's lots of information for gathering, sharing,
and protecting privacy in OIRC; if he would like
to work with OIRC, they can give pointers on how
to handle that data with necessary

Q: further instrumenting to see if there's noise
in the allocated space to see if this may be just
part of overall background noise?
A: this is the raw, basic data

Q: Duane Wessels, measurement factory; DNS queries
behave differently when a result exists vs doesn't
exist; may be worthwhile to temporarily make them
exist on a set of servers, and collect the data
from there, and see if the resolution process
follows the delegation.

Q: Troy Jessup, Utah edu network; could 1, 2, 100,
etc. network queries be due to malware that starts
at one end of a block and just starts scanning
indiscriminantly.  100 seems to be a common starting
point for malware, for example.
Haven't looked into it in that much detail--is it
just 1.1.1.1/32, or 1.1.1.1/16, how much coverage
within the block is there?  is it just hot spots?
These are really good ideas for the Real Researcher(tm)
to delve into, once one can be tracked down.

If people want to send suggestions, email him at

[email protected]