Rather than developing a positive means to prove that a protocol is
supported at a particular domain, some advocate use wildcard records
containing invalid hostnames to signal non-support.
Will the IETF/ICANN then need to establish a TLD of "invalid" to
support the concept of invalid hostnames used in automated
scenarios? For example, invalid hostnames used in an automated
fashion, such as those within MX records.
Will a wildcard scheme attempting to indicate non-support of protocol
become utilized in various DDoS attacks?
Much of the overhead related to DNS traffic might exist within the
size of domain name itself, as this may occupy half the allotted DNS
packet which must also be repeated within the response. A wildcard
scheme provides bad-actors a means to ensure their transaction is
never answered from cache, by just randomly generating a label. Even
negative caching therefore offers no relief from this type of DDoS
attack. There is also likely a problem created at the roots,
especially from domains that do not implement negative caching. The
cache itself may also be made ineffective due to sheer volumes of
bogus wildcard records it now contains.
With MX records, some receiving domains utilize SPF. SPF treats DNS
records in a script like fashion and may synthesize _10_ MX record
transactions for each:
- recipient (1 to minimum of 100)
- validated email-domain/address (EHLO, MAILFROM, PRA, n * DKIM
signing domain?)
SPF macro expands various components of the email-domain/address
questioned, where each different email-address must invoke a new set
of transactions. A spammer is able to utilize a _single_ SPF record
to induce perhaps millions of third-parties to flood their victim
domains with non-cached transactions. This could be done by simply
employing different local-parts and domains within the email-address
contained with the spam campaign. In addition, SMTP logs would not
trace what is causing the attack either, hidden within an unseen SPF
record.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html