Subject: [Asrg] Another dnsbl draft, now standards flavored

From: "John Levine" <[email-masked]>
Date: 19 Jul 2008 23:10:57 -0400

The IESG has expressed interest in my dnsbl draft turning into a standards 
track RFC rather than informational.  I've done another version of it 
to make it read like a standard, and there's also a few places where I 
invented some standard practices, e.g., standard test entries for IPv6 
DNSBLs.  Take a look, tell us if I got anything seriously wrong.

We're in the I-D blackout period, so I've posted xml, html, and txt at 
http://www.taugh.com/dnsbl

In related news, there WILL be an ASRG session in Dublin.  Who other than 
me is planning to be there?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener Schnitzel, please", said Tom, revealingly.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 20 Jul 2008 07:49:24 +0200

John Levine wrote:

> The IESG has expressed interest in my dnsbl draft turning
> into a standards track RFC rather than informational.

Good...

> Take a look, tell us if I got anything seriously wrong.

...skipping typos and editorial nits reported separately ::2
is interesting, as I didn't know it.  My intuitive idea for
an IPv6 test address would have been ::FFFF:127.0.0.2 based
on the IPv4 test address.  Never listing ::1 is clear, same
idea as for 127.0.0.1.  WTH is ::FFFF:127.0.0.2 in a DNSBL ?

0.0.0.2.0.0.F.7.F.F.F.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2

Well, nobody said that IPv6 DNSBLs are pretty.
 
> http://www.taugh.com/dnsbl

A diff to -05 is still readable, <http://tinyurl.com/6budf7>

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 20 Jul 2008 15:32:17 +0200

> 0.0.0.2.0.0.F.7.F.F.F.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 

Some hours later, that's wrong.  Why do they need their own test
entry, they could as well support 2.0.0.127 like IPv4 lists, if
the only purpose is to check that the list is alive and kicking.

 Frank

---

From: John Levine <[email-masked]>
Date: 20 Jul 2008 15:40:54 -0000

>the only purpose is to check that the list is alive and kicking.

Many DNSBLs are operated by specialized servers that synthesize the
records from lists of CIDR ranges.  The IPv6 test entries really need
to be IPv6 addresses or you're demanding special code in the server
for the test addresses.

I picked ::2 as the test address because it was next to ::1,
just like 127.0.0.2 is next to 127.0.0.1.

R's,
John

---

From: John Levine <[email-masked]>
Date: 20 Jul 2008 15:40:54 -0000

R's,
John

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 20 Jul 2008 18:10:23 +0200

John Levine wrote:

> The IPv6 test entries really need to be IPv6 addresses or
> you're demanding special code in the server for the test
> addresses.
 
> I picked ::2 as the test address because it was next to
> ::1, just like 127.0.0.2 is next to 127.0.0.1.

Ugh, I just send a separate mail.  Yes, it's clear why you
picked ::2.  Now IFF ::FFFF:a.b.c.d *MUST* be treated as 
IPv4 a.b.c.d by lists *and* clients, then ::FFFF:127.0.0.2
is the same as 127.0.0.2. 

You don't have that *MUST* yet, but it might make sense...

 Frank

---

From: "Larry M. Smith" <[email-masked]>
Date: Sun, 20 Jul 2008 13:01:49 -0500

John Levine wrote:
> The IESG has expressed interest in my dnsbl draft turning into a 
> standards track RFC rather than informational.  I've done another 
> version of it to make it read like a standard, and there's also a few 
> places where I invented some standard practices, e.g., standard test 
> entries for IPv6 DNSBLs.  Take a look, tell us if I got anything 
> seriously wrong.
> 
> In related news, there WILL be an ASRG session in Dublin.  Who other 
> than me is planning to be there?
> 

I realize that its been years since I have provided any input on this 
document...  I do have some questions, perhaps they are better late than 
never.

--8<-----------------------------------------------------------------

 > 2.1.  IP address DNSxL
[...]
 > If a range of addresses is listed in the DNSxL, the DNSxL MUST
 > contain an A record (or a pair of A and TXT records) for every
 > address in the DNSxL.  Conversely, if an IP address is not listed in
 > the DNSxL, there MUST NOT be any records for the address.
[...]

Currently DNSBLs are seeing a fair amount of requests for AAAA records. 
  I'm currently wondering if these could/should be treated as requests 
for A records, as it is quite possible that the DNSBL client is 
completely unaware that these requests are being done by the resolver.

--8<-----------------------------------------------------------------

 > 2.2.  IP address DNSWL
[...]
 > There is no widely used convention for mapping sublist names to bits
 > or values, beyond the convention that all A values SHOULD be in the
 > 127.0.0.0/8 range to prevent unwanted network traffic if the value is
 > accidentally used as an IP address.
[...]
 > 5.  Test and contact addresses
[...]
 > The combination of a test address that MUST exist and an address that
 > MUST NOT exist allows a client system to defend against DNSxLs which
 > deliberately or by accident install a wildcard that returns an A
 > record for all queries.  DNSxL clients SHOULD periodically check
 > appropriate test entries to ensure that the DNSxLs they are using are
 > still operating.
[...]
 > 6.  Typical usage of DNSBLs and DNSWLs
[...]
 > A client MUST interpret any returned A record as meaning that an
 > address or domain is listed in a DNSxL.  Mail servers that test
 > combined lists most often handle them the same as single lists and
 > treat any A record as meaning that an IP is listed without
 > distinguishing among the various reasons it might have been listed.
 > DNSxL clients SHOULD be able to use bit masks and value range tests
 > on returned A record values in order to select particular sublists of
 > a combined list.

Perhaps something could be said to warn about the domain name 
aftermarket, and that clients might want to quantify the return values 
to ensure that A records exist within 127/8.  Historically domain names 
hosting the DNSBL have expired and the new owners install wild-card records.

--8<-----------------------------------------------------------------

 > 2.3.  Combined IP address DNSxL
[...]
 > A single DNSxL could in principle contain both IPv4 and IPv6
 > addresses, since the different lengths prevent any ambiguity.  If a
 > DNSxL is represented using traditional zone files and wildcards,
 > there is no way to specify the length of the name that a wildcard
 > matches, so wildcard names would indeed be ambiguous for DNSxLs
 > served in that fashion.

Perhaps a recommendation that DNSBL operators not combine there IPv4 and 
IPv6 lists, instead using sublists for each could be inserted here.

--8<-----------------------------------------------------------------

 > 3.  Domain name DNSxLs
[...]
 > A few name-based DNSBLs encode e-mail addresses using a convention
 > adapted from DNS SOA records, with the mailbox name encoded as the
 > first component of the domain name, so an entry for [email-masked]
 > would have the name fred.invalid.edu.doms.example.net:

Note that this can be ambiguous with hostnames and sub-domains.

--8<-----------------------------------------------------------------

 > 3.  Domain name DNSxLs
[...]
 > Name-based DNSWLs can be created in the same manner as DNSBLs, and
 > have been used as simple reputation systems with the values of octets
 > in the A record representing reputation scores and confidence values,
 > typically on a 0-100 or 0-255 scale.

This appears to be an historical reference to some name-based DNSBL and 
inserted here because of the reference...  Perhaps this would be better 
placed in section 2.3 where bit-masks and multi-responses are discussed.

--8<-----------------------------------------------------------------

 > 5.  Test and contact addresses
[...]
 > IPv6 based DNSxLs MUST contain an entry for ::2, and MUST NOT contain
 > an entry for ::1.

While a DSNBLv6 should never list ::1, 0000::/8 is reserved and (at 
least under theory) ::2 could be used in the future with unpredictable 
results for DNSBLs.

Perhaps is is best to keep the test addresses in ::FFFF.127.0.0.0/96.

SgtChains

---

From: SM <[email-masked]>
Date: Sun, 20 Jul 2008 11:33:12 -0700

At 20:10 19-07-2008, John Levine wrote:
>We're in the I-D blackout period, so I've posted xml, html, and txt 
>at http://www.taugh.com/dnsbl

The is an ongoing discussion about posting I-Ds during this 
period.  I assume that this is the version that will be discussed in Dublin.

As the intended status is now Standard Track, it would be good to 
review the IPv6 angle.  Currently, there's only Section 2.4 that covers IPv6.

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 20 Jul 2008 22:39:12 -0000

>is the same as 127.0.0.2. 

I don't see that in the IPv6 documents, and in any event, this draft
is about DNSBLs, not IPv6 theology.

As I read it, if you want to embed v4 addresses in v6, here's where
you do it, but in fact nobody does.

R's,
John

---

From: John Levine <[email-masked]>
Date: 20 Jul 2008 22:42:48 -0000

>completely unaware that these requests are being done by the resolver.

Hmmn.  What AAAA record would you return?  This strikes me as a place
where, if anything, the draft should be clearer that the values are
always A records, not do something kludgy for the benefit of unknown
broken software.

>hosting the DNSBL have expired and the new owners install wild-card records.

That's the point of the MUST/MUST NOT tests described later.

>IPv6 lists, instead using sublists for each could be inserted here.

Why not?  As it says later, if you want to use the same zone for v4 and
v6 addresses, it'll work OK since there's no overlap in the names.

>Note that this can be ambiguous with hostnames and sub-domains.

A list needs to be either all domains or all e-mail addresses.  Do we
need to call that out?

R's,
John

---

From: John Levine <[email-masked]>
Date: 20 Jul 2008 22:39:12 -0000

R's,
John

---

From: John Levine <[email-masked]>
Date: 20 Jul 2008 22:42:48 -0000

R's,
John

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 21 Jul 2008 07:29:22 +0200

John Levine wrote:

> A list needs to be either all domains or all 
> e-mail addresses.  Do we need to call that out?

You could remove the concept of "e-mail" lists,
I wouldn't miss it for a second.  Twisting local
parts into DNS labels is black magic, and with
quoted-strings it gets surreal.

Half of the SPF-EAI draft argues non-stop why
this is a bad idea, a security issue, won't work
with some less capapable DNS APIs designed for
(roughly) LDH + underscore, an interoperability
nightmare (e.g., semantic content of quoted-pair,
embedded dots), and generally the worst part in
SMTP, EAI, and SPF.

 Frank

---

From: der Mouse <[email-masked]>
Date: Mon, 21 Jul 2008 01:16:13 -0400 (EDT)

> you do it, but in fact nobody does.

Either you don't use dual-stack Linux boxen or there's something I'm
missing.

I have a fair number of network programs that I've gone to some pains
to make v6-ready.  When I build and use them on Linux - any Linux, in
my admittedly quite limited experience - I see behaviour indicating
that tcp4 connections to port N in the presence of a process listening
on tcp6 port N get turned into tcp6 connections with a mapped-v4
address for the (v4-speaking) peer.  This is particularly annoying
because it means that, after binding a v6 socket listening on port N,
an attempt to bind a v4 socket listening on port N gets an
address-already-in-use error.  (There's really nothing like
compatability - and that's nothing like it.)

I forget whether v4 gets mapped into v6 this particular way
(::ffff:x.y.z.w) or some other way.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Mon, 21 Jul 2008 01:41:10 -0400 (EDT)

> You could remove the concept of "e-mail" lists,  I wouldn't miss it
> for a second.  Twisting local parts into DNS labels is black magic,

Huh?  What's black magic about it?  The only problems I can see are (a)
local-parts longer than 63 octets and (b) "DNS" APIs that don't permit
access to all the DNS's power.  The former are prima facie hopeless
without some kind of encoding scheme and the latter are the fault of
the APIs, not the spec.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 26 Jul 2008 00:23:24 +0200

der Mouse wrote:

>> Twisting local parts into DNS labels is black magic,
> Huh?  What's black magic about it?

The fine print of <Quoted-string> and quoted pairs in 
RFC 2821bis.

> local-parts longer than 63 octets

Yes, that is also fun.  RFC 4408 mentions "truncate"
in a note, but forgot to say if that is RTL or LTR,
and if it is OPTIONAL, RECOMMENDED, or REQUIRED... ;-)

> "DNS" APIs that don't permit access to all the DNS's
> power.
[...]
> the latter are the fault of the APIs, not the spec.

Some Windows .NET API apparently doesn't like octets
in DNS queries.  I've not tested it, just heard about
it on the SPF devel list.  The SPF implementor found
a better API later.

There's also a subtle syntactical difference wrt white
space characters between RFC 2821bis and I-D 2822upd.

Unrelated, to celebrate IETF 72 and the new DNSBL I-D
I've added IPv6 support to DNSBL queries in my rxwhois
client.  Either none of the nine DNSBLs I normally use
lists ::2 and ::FFFF:127.0.0.2, or I screwed up.  Has
anybody a nice DNSBL'ed IPv6 for tests ?

 Frank
-- 
<http://purl.net/xyzzy/src/rxwhois.cmd> version 2.1.2

---

From: "Walter Dnes" <[email-masked]>
Date: Mon, 28 Jul 2008 18:41:30 -0400

On Sun, Jul 20, 2008 at 10:39:12PM -0000, John Levine wrote

> is about DNSBLs, not IPv6 theology.

  It's not about theology, it's about following the rules, just like
IPV4 DNSBLs have to follow the rules of IPV4.  A few thoughts...

  - IPV4 will be around for a while yet, so please do a proper job on it

  - IPV6 will be around after IPV4 disappears, so it's even more important
    to do the IPV6 implementation right
    - in particular, IPV4 DNSxLs use the entire "localhost" address
      space, all 24 bits of it (127.0.0.0/8).
    - do *NOT* impose an IPV4 limit on IPV6.  IPV6 has a "localhost"
      address space of 121 bits (fc00::/7).  Don't be afraid to use it

  - DNSBL servers should not try to pull a "Clippy" in terms of "being
    helpful".
    - If a server gets a query via IPV4, it should return an A record
    - If a server gets a query via IPV6, it should return an AAAA record

  - left hand, say "Hello" to right hand.  This is not a joke.  I
    suggest that you join IETF's ipng mailing list, and run your draft
    past them.
    - these people, better than anybody else, can point out any problems
      with your IPV6 implementation
    - you're not an ordinary end-user; you're developing a standards
      track RFC that should count as "protocol development"
    - the ipng may be in a position to reserve a block of addresses
      *JUST FOR DNSxLs*
    - there may already be something buried deep in the specs allocating
      a block of address just for stuff like this
    - it would look really, really bad if two IETF groups came out with
      contradictory specs

  The ipng list instructions are at...
http://playground.sun.com/pub/ipng/html/instructions.html

-- 
Walter Dnes <[email-masked]>
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 29 Jul 2008 02:43:37 +0200

> - If a server gets a query via IPV6, it should return an AAAA record

That's IMO a bit exaggerated, DNSBLs in essence (ab)use one IPv4
127.0.0.2 to signal "listed".  Extended to 127/8, maybe avoiding
127/31, to indicate also some kind of reason, e.g. defining sets
for the up to 32-8 (or 32-8-1) "free" bits in this range.

That's an ordinary DNS lookup for an A-record, no matter if this
is transported via IPv4, IPv6, or avian carrier to DNSBL servers.

And this is a feature, e.g., I have no IPv6.  But I can check
if an IPv6 is listed, using the ip6.arpa format specified in
the draft.  I implemented this some days ago, no problem.

An open question is which IPv6 could be used as test entry, to
check that a DNSBL is alive and supporting IPv6.  The draft has
it clear that ::1 MUST NOT be listed (like 127.0.0.1), that is
good to find maniacs suddenly listing "the world" (it happened).

The draft proposes (or proposed if John changed it) to use ::2
as test entry (like 127.0.0.2).  I wasn't sure if this is as it
should be, and proposed ::FFFF:127.0.0.2 (as the always listed
IPv6 test entry).

If you have a better proposal, or if you could tell us what is
dubious with ::2, or dubious with ::FFFF:127.0.0.2, this would 
help us, as it is in essence the only open question.

DNSBLs don't need more "reason codes" than 127/8 (minus 127/31
in my parallel universe, but that is not a part of the draft).

 Frank

---

From: "Walter Dnes" <[email-masked]>
Date: Mon, 28 Jul 2008 23:40:45 -0400

On Tue, Jul 29, 2008 at 02:43:37AM +0200, Frank Ellermann wrote
> for the up to 32-8 (or 32-8-1) "free" bits in this range.

  This is a case of "everything you know is wrong", because there are
fundamental differences between IPV4 and IPV6.  In short, *** IPV6 DOES
NOT HAVE ANYTHING EQUIVALANT TO IPV4's 127.0.0.0/8 address range ***.
It's true that IPV6 ::1 is the functional equivalant of IPV4's
127.0.0.1.  But unlike IPV4, which devotes 16 million addresses to
"this machine", IPV6 allocates only 1 address to "this machine".  Given
that IPV6 doesn't have such a range, I suggested using the
RFC1918-equivalent range fc00:: /7 instead.  It's sort of like
192.168.0.0 /16, but with a lot more room.

> good to find maniacs suddenly listing "the world" (it happened).

::1 is *NOT* part of a "this machine" address range, because there
ain't no such animal in IPV6.  Don't assume that you can play fast and
loose with 16 million addresses in the range ::0 to ::FF:FF:FF:FF.
This doesn't exclude the possibility of using ::2 as a test address.
I feel that meta-data/control-data should be "out-of-band" from actual
data.  Not only should the submitted address be out-of-band, so should
the result.  Again, I suggest checking with the official IPV6 gurus, as
to which addresses we can safely use.

> should be, and proposed ::FFFF:127.0.0.2 (as the always listed

  We don't know what will happen with that range once IPV4 goes away. 
and why restrict ourselves to 24 bits, anyways?

> in my parallel universe, but that is not a part of the draft).

  That attitude is what got us into this mess in the first place.  If
CIDRs and NAT had been used from day 1, we'd be another few years from
running out of addresses.

---

From: der Mouse <[email-masked]>
Date: Mon, 28 Jul 2008 23:50:18 -0400 (EDT)

> fundamental differences between IPV4 and IPV6.  In short, *** IPV6
> DOES NOT HAVE ANYTHING EQUIVALANT TO IPV4's 127.0.0.0/8 address range
> ***.

It doesn't need to.  The A records returned by DNSLs are not machine
addresses; there is no reason not to use the full 32 bits available,
except human discomfort with treating A records that way.

> Don't assume that you can play fast and loose with 16 million
> addresses in the range ::0 to ::FF:FF:FF:FF.

::0 through ::FF:FF:FF:FF is ff00ff00ff0100 hex, or 71777214294589696
decimal, addresses, not anything like 16 million.  If you mean 16777216
addresses, ITYPM ::0 through ::ff:ffff.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Tony Hansen <[email-masked]>
Date: Tue, 29 Jul 2008 04:46:22 -0400

My take:

Think of DNSxL as an exercise in steganography: A few bits of 
information are encoded into something that looks an awful lot like an 
IP address and can be carried over a channel intended to transmit IP 
addresses. Otherwise it's an opaque value.

The choice of 127.0.0.0/8 and ANY sort of range in the IPv6 address 
space is truly irrelevant. These are not IP addresses; they just look 
like IP addresses.

	Tony Hansen
	[email-masked]

---

From: John Levine <[email-masked]>
Date: 29 Jul 2008 14:57:56 -0000

>192.168.0.0 /16, but with a lot more room.

I don't have strong opinions about what the test entry should be,
but it seems a poor idea to make it an address that might actually
appear on a network.  Where's fc00:: defined?  I don't see it in
RFC 4291.

Also, to pile on to other comments, the data in DNSBLs is always A and TXT
records.  The A record isn't an address, it's either a bit mask or a bunch
of subfields, and I see no reason to change it just because the names change.

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 29 Jul 2008 13:26:45 -0400

> space is truly irrelevant. These are not IP addresses; they just look 

Correct.  But having the DNSBL return addresses that may actually be in 
use means that you can't tell the difference between a correctly 
operating DNSBL and an ordinary DNS server returning real IP addresses.

Eg: a DNSBL domain gets typo-squattered (or reclaimed), whereupon the 
domain owner puts in wildcarded A records pointing at their click thru 
advertising page.  In ipv4 space, there is a not insignificant fraction 
of DNSBL clients that will treat this as meaning all IPs are listed. 
The slightly better ones know that non-127/8 returns should be ignored.

We need the same safety net in ipv6.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Steve Atkins <[email-masked]>
Date: Tue, 29 Jul 2008 10:32:34 -0700

On Jul 29, 2008, at 10:26 AM, Chris Lewis wrote:

>> information are encoded into something that looks an awful lot like  
>> an IP address and can be carried over a channel intended to  
>> transmit IP addresses. Otherwise it's an opaque value.
>> space is truly irrelevant. These are not IP addresses; they just  
>> look like IP addresses.
>
> Correct.  But having the DNSBL return addresses that may actually be  
> in use means that you can't tell the difference between a correctly  
> Eg: a DNSBL domain gets typo-squattered (or reclaimed), whereupon  
> the domain owner puts in wildcarded A records pointing at their  
> click thru advertising page.  In ipv4 space, there is a not  
> insignificant fraction of DNSBL clients that will treat this as  
> meaning all IPs are listed. The slightly better ones know that  
> non-127/8 returns should be ignored.
>

You'd only need the same safety net for IPv6 responses if you decided  
to have a DNSBL return IPv6 responses, which I don't think anyone is  
seriously suggesting, are they?

Otherwise, it returns an A record and, after you've gone through the  
step of converting the IP address you're querying to a hostname,  
everything behaves identically for v4 and v6 queries.

Cheers,
   Steve

---

From: SM <[email-masked]>
Date: Tue, 29 Jul 2008 10:38:36 -0700

>appear on a network.  Where's fc00:: defined?  I don't see it in

See RFC 4193.

Regards,
-sm

---

From: der Mouse <[email-masked]>
Date: Tue, 29 Jul 2008 13:54:55 -0400 (EDT)

> operating DNSBL and an ordinary DNS server returning real IP

"Test listings."  If looking up 2.0.0.127.$DNSL and 3.0.0.127.$DNSL (or
whatever the list's should-exist and shouldn't-exist addresses are)
returns the same thing - whether address or no-address - then the list
is not functioning correctly.  (What the should-exist and
shouldn't-exist addresses for the list are constitutes part of the
configuration for use of the list.)

Yes, a lot of lists currently aren't this well built.  I don't see the
popularity of doing it wrong as a reason to not even try to do it right.

> domain owner puts in wildcarded A records pointing at their click
> thru advertising page.  In ipv4 space, there is a not insignificant
> fraction of DNSBL clients that will treat this as meaning all IPs are
> listed.

There's not much that can be done about that.  Those clients will
(mis)behave that way whether or not the DNSL always returns addresses
in 127/8.

> The slightly better ones know that non-127/8 returns should be

I'd say, rather, that the better ones apply some sanity checks; just
because non-127/8 is the currently-common sanity check does nt mean
it's the only possible, or even best possible, sanity check.

> We need the same safety net in ipv6.

I'm not convinced IPv6 has anything at all to do with this.  (Well,
except that once IPv4 is dead then there will be no reason to not use
all 32 bits in A records, since A records won't be used for anything
else.  But that time is far enough off we can ignore it for now.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign