Re: [ietf-dkim] Jim's issues - one more try

On Fri, 15 Jun 2007 03:41:16 +0100, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>  
wrote:
> On Jun 14, 2007, at 3:33 AM, Charles Lindsey wrote:
>
> > On Wed, 13 Jun 2007 15:24:59 +0100, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>  
> > wrote:
> > > On Jun 13, 2007, at 3:47 AM, Charles Lindsey wrote:
> > And those querying MX records to see if a 'conventional' address such  
> > as 'nomail.invalid' is present do not then need to try to retrieve its  
> > IP address.
> Spam is often highly distributed, perhaps to millions of servers.  When  
> such spam induces DNS resolution of bogus names, negative responses  
> might be cached for a few minutes, and in some cases not at all.   
> RFC2308 'suggests' using the SOA minimum field, which is often 1 day at  
> the root.
Yes, the root server I looked at had one day, which means that the  
non-existence of the 'invalid' TLD should be cached for that long.
>  There is _no_ assurance negative caching is implemented.
It seems to be required by RFC2308. I should think it is now implemented  
on most resolvers worldwide.
>  To safely thwart spammers without hammering roots, point targets within  
> the MX records to 192.0.2.0/24 address space.  See RFC3330.
Yes, an MX record pointing to some 'conventional' address in that space  
would serve our purpose, but I think MX records are supposed to point to  
domains rather than IPs.
> In the case of MX records, it is code, not people, that see  
> "nomail.invalid".  A well considered scheme will not induce automated  
> use of bogus names which might then pound root severs.  Perhaps a TLD of  
> "invalid" could be established.
It IS established (see RFC 2606), and if you stare at the ICANN website  
for long enough you will find they have agreed never to allocate it. But  
registering it on the root servers with a huge TTL would indeed help.
>  Perhaps IP addresses for "invalid" names servers could be assigned the  
> address of "192.0.2.2"   After all, who wants to pay for a large amount  
> of bogus traffic?  As it is now, critical roots bear the brunt.  Don't  
> assume publishing bogus names in DNS records is safe, especially with  
> respect the most abused anonymous push protocols there is, SMTP.
> > > > I reckone there would be no need then to deprecate A records where MX  
> > > > was absent, or anything like that.
> > But, as has been pointed out to you, that "deprecation of A records" is  
> > just not going to happen. I am just trying to point out an alternative  
> > that might work instead.
> This is _not_ about deprecating A records.  It is about deprecating  
> their use for discovery.
I don't believe that is goiung to happen either.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html