the primary beneficiaries of this
new functionality are spammers and other malfeasants,
I think this is a true statement. I think it is important to keep in
mind that registry operators "compete" for TLD franchises, and where
those "competitions" occur, this statement is not belived to be true.
Eric
Has anyone done any studies to prove this conjecture? If this was
true, maybe those registries who do perform this particular service today
ought to slow down their update frequency.
Mark
And lose share to the one who doesn't slow down?
I seem to remember the biggest reason for the flood away from the monopoly
registrar when *that* floodgate opened was that the other registrars promised
updates "this day rather than this month".
(And yes, the whole .com/.net/.org/.biz landscape is enough of a mess that the
comment applies to "registries" as well as "registrars" - a local radio station
has 'wrov.cc' because 'wrov.com' is a domain in Korea)...
In other words, Verisign is unhappy that spammers are now registering primarily
.biz domains and Verisign is no longer getting getting share of their business?
because i have sometimes been accused of being unfair to markk, i checked.
markk@verisignlabs.com (Mark Kosters) writes:
> > the primary beneficiaries of this new functionality are spammers and
> > other malfeasants,
>
> I think this is a true statement.Has anyone done any studies to prove this conjecture?
at dictionary.reference.com we see the following:
con�jec�ture P Pronunciation Key (kn-jkchr)
n.1. Inference or judgment based on inconclusive or incomplete evidence;
guesswork.2. A statement, opinion, or conclusion based on guesswork: The commentators
made various conjectures about the outcome of the next election.
as the author of the statement in question, and based on the definition
shown, it's just not conjecture.
If this was true, maybe those registries who do perform this particular
service today ought to slow down their update frequency.
as others have pointed out, spammers will always find a way to spam, and
while the number of cases where the beneficiary is not a spammer is small,
it's not zero. so we have to do it. but when someone says, later, that
the .COM zone generator ought to use a ttl template of 300 rather than
86400 in order that changes and deletions can get the same speedy service
as additions, i hope that icann will say "no."
wrt the mit paper on why small ttl's are harmless, i recommend that y'all
actually read it, the whole thing, plus some of the references, rather
than assuming that the abstract is well supported by the body.
the primary beneficiaries of this new functionality are spammers and
other malfeasants
It appears your glass is half empty rather than half full. The
primary beneficiaries are all current and future .com/.net domain
holders: timely and predictable zone updates from one's parent are a
good and useful feature. Mistakes can be fixed more rapidly and zone
administrators who know what they are doing can effect changes
quickly.
but when someone says, later, that the .COM zone generator ought to
use a ttl template of 300 rather than 86400 in order that changes
and deletions can get the same speedy service as additions, i hope
that icann will say "no."
Paul, as you know, the TTL of parent-side NS RRsets when the data
sought is in the immediate child zone is largely irrelevant because of
credibility, which I described in
http://www.merit.edu/mail.archives/nanog/2004-07/msg00255.html. I
also stated in that message that VeriSign has no intention of changing
the current 48-hour TTL on delegation NS RRsets in .com/.net.
I am not worried so much about the root servers here because of the
reasons you cite. The root server system is engineered to cope with
hugely excessive loads already.
I am worried about all the other DNS servers that have to deal with
much lesser query loads and might feel the impact of lowered TTLs
much more.
If a zone owner lowers a TTL and causes an increase in load, most of
the foot being shot off is his or her own: the zone's own name servers
will bear the brunt of the increased query load.
I agree with Daniel's earlier statement that this is an education
issue. Does anyone want to co-author an Internet-Draft on the topic
of choosing appropriate TTLs?
Matt
If a zone owner lowers a TTL and causes an increase in load, most of
the foot being shot off is his or her own: the zone's own name servers
will bear the brunt of the increased query load.
Maybe, but don't forget that when BIND9 and DJBDNS caches find
expired nameserver address (A) records they don't trust any cached
data and start them back at the roots. And in the case of BIND9,
it sends both A and A6 queries for each nameserver in the list.
For example, microsoft.com's five nameservers have A records with
TTL of one hour. Worst case we might expect every BIND9 cache to
send 10 queries to the roots (then the TLDs) every hour, just for
these nameserver addresses.
Duane W.
Do they really send A6 queries? Haven't we decided to go back to AAAA now?