[SHAME] Spam Rats

Owen DeLong owen at delong.com
Thu Jan 10 19:48:52 UTC 2013

On Jan 9, 2013, at 20:18 , Mark Foster <blakjak at blakjak.net> wrote:

> On 10/01/13 17:15, Karl Auer wrote:
>> On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote:
>>> FYI - I have a PTR for all IPs. Just general practice.
>> All IPs actually in use, or all possible IPs in a network? If the
>> latter, then it's not gunna fly for IPv6. Not at all. Not unless you
>> synthesise the responses - in which case there is no point to requiring
>> them anyway.
>> Regards, K.
> $GENERATE, as someone else pointed out, solves that problem for you?
> (Does it scale for IPv6? I can't recall - but surely this could be
> scripted too.)

Mental exercise...

$GENERATE is a run-time macro which is parsed to create in-memory
PTR records for all included entries. The end result in memory is
identical to having typed in all of the PTR records in a zone file.

If you're running a 64 bit architecture, you can, theoretically, address
a 64-bit memory space. However, that would require each in-memory
PTR record to fit in 1 byte and you would have no room remaining
for little silly inconsequential things like forward zones, the DNS server
software, the operating system, the network stack, etc.

This assumes, of course, that you have maxed out your RAM to a full
18,000+ petabytes (which I tend to doubt).

If not, then, you don;t even have enough RAM for 1 byte per PTR record.

I know PTR records can theoretically be pretty compressible, but I doubt
you can get below 1 byte/record even with the best of compression algorithms.

Real time synthesis (synthesis on request) according to something similar
to $GENERATE might be feasible, but $GENERATE as implemented
does not scale to IPv6.

> I though the point of doing so was to establish with some degree of
> accuracy that there were 'real people' behind the administration of said
> IP, and that there was a somewhat increased level of accountability as a
> result - which suggests there is infact a point.

I'll leave the flaws in that theory as an exercise to the reader.


More information about the NANOG mailing list