ietf-asrg
[Top] [All Lists]

RE: [Asrg] 6. Proposals - RMX I Never send mail

2003-09-25 10:21:07


-----Original Message-----
From: Raymond S Brand [mailto:rsbx(_at_)rsbx(_dot_)net]
Sent: Thursday, September 25, 2003 12:51 PM
To: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] 6. Proposals - RMX I Never send mail


Although I agree with the motivation and sentiments expressed 
in this idea,
it suffers from the same set problems that _ALL_ of the TXT 
RR ideas suffer
from:

1) Large responses to the query. Potentially very large when 
you include
      some other TXT RRs people have suggested.

I don't think this is a major problem. The amount of text sent in a UDP
packet is effectively limited to 500 bytes and the cost is almost entirely
routing.

If the UDP response is too large the client does not need to followup with
TCP.


2) Multiple responses to search through to find the 
specifically formatted
      TXT RR the application is looking for.

Here an SRV like selector mechanism of the sort you propose would work well.
I would suggest however that any selector use the numeric port address
rather than a protocol name. Here we are really giving a line
characteristic.

That said it is useful to distinguish addresses that do not initiate any
connections (i.e. they only act as servers) and those that never respond,
this might merit a case by case consideration.

3) Parsing the formatted TXT RR to find the data that the 
application is
      interested in.

I am unconvinced on that point. All a network protocol consists of is
parsing and more parsing. 

If instead you use the name from the the rDNS query result to 
do an A RR
query of the following (DRIPish) form:

      addrtype._email_.${PTR_VALUE}

This way you get 24 bits to assign meaning to (if results 
must be part of
127.0.0.0/8). The query response will be small. Multiple A RRs in the
response mean the test failed. No parsing needed.

You should also do an A RR query on ${PTR_VALUE} to verify 
that the PTR RR
record isn't bogus.


Raymond S Brand


"Hallam-Baker, Phillip" wrote:

All,

        There seems to be an issue with current blacklist 
implementations.
The DNS server approach works fine functionally but the 
blacklist server
becomes a target for a DoS attack. While it is possible to run DNS
configurations hardened against DNS attack this costs a 
collosal amount. The
cost of the necessary bandwidth, hardware, support of doing 
it right is
huge.

        I would like to suggest therefore that we look for 
ways that we can
distribute certain information that is currently distributed via DNS
blacklists in a more distributed fashion. This will not be 
possible for all
information of course but is possible for certain subsets.

        In particular dial up modem pools, residential 
broadband links,
services that never send mail can be blacklisted through 
the rDNS. This has
a second advantage, the responsibility for maintenance is 
brought back to
the owner of the IP address. This would address current 
problems with large
IP address blocks being contaminated by prior spammer 
hijacking, listing by
an ISP etc.

        For example 18.2.1.xx might have a DNS record of one of the
following forms

                TXT             <ASRG><TYPE>DIALUP</TYPE></ASRG>
                POLICY  DIALUP

        Where POLICY would be a new record written for the 
purpose (usual
caveats apply). The usual caveats about using the DNS would 
also apply, risk
of spoofing etc. However I think that if those are really 
an issue we just
go fix DNS.

        I would see the following as useful identifiers:

                SERVER          A full service IP address
                DIALUP          The address is allocated to 
a dialup modem
pool
                RESIDENTIAL             The address is allocated to
residential broadband
                BLOCKED         The address is blocked, you 
should never
connect
                UNALLOCATED             The address has not 
been allocated

        It might be useful to make this a bit more complex 
so as to allow
specific protocols to be identified, but I think that is 
best done through
the forward DNS.

        This might be interpreted as breaking the end to 
end religion, but
people are already doing that of their own accord. I would 
rather have ISPs
open port 25 outgoing and label the connection honestly as 
residential than
have then block the port entirely to stop attacks from 
anti-spam vigilantes.

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg