Re: VeriSign's rapid DNS updates in .com/.net

[Robert E. Seastrom]

Randy Bush <[EMAIL PROTECTED]> writes:

> > I'm not talking about intended beneficiaries.  I agree with your statement
> > when applied to intended beneficiaries.  I'm talking about the character
> > of the preponderance of actual beneficiaries, whether measured by number
> > of domain registration events per unit time, or number of dollars of income
> > enabled by the speediness of the "fast update" VeriSign is now announcing.
> 
> paying net customers want quick adds/updates/deletes.  verisign's
> competitors offer this.  versign will offer this.  get over it.

Nothing wrong with showing the last 30 days worth of changes via
whois; it would address Paul's concerns and make it painfully obvious
when someone is monkeying around.

---Rob

Re: VeriSign's rapid DNS updates in .com/.net

[Randy Bush]

> I'm not talking about intended beneficiaries.  I agree with your statement
> when applied to intended beneficiaries.  I'm talking about the character
> of the preponderance of actual beneficiaries, whether measured by number
> of domain registration events per unit time, or number of dollars of income
> enabled by the speediness of the "fast update" VeriSign is now announcing.

paying net customers want quick adds/updates/deletes.  verisign's
competitors offer this.  versign will offer this.  get over it.

randy

Re: VeriSign's rapid DNS updates in .com/.net

[Paul Vixie]

> > the primary beneficiaries of this new functionality are spammers and
> > other malfeasants
> 
> ... The primary beneficiaries are all
 ^
 intended
> current and future .com/.net domain holders: 

I'm not talking about intended beneficiaries.  I agree with your statement
when applied to intended beneficiaries.  I'm talking about the character
of the preponderance of actual beneficiaries, whether measured by number
of domain registration events per unit time, or number of dollars of income
enabled by the speediness of the "fast update" VeriSign is now announcing.

> ... 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.

Right.  And I hope you are able to stick to that plan in the face of what
I think will be gigantic pressure, from both registrants and competitors,
to lower it.

> 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?

I can't think of anyone who could do it better than you could, Matt.  I
know I offered to help a while back, but we never really got started on it,
and after being named as a "sitefinder co-conspirator" in your lawsuit
against ICANN, I think I'll hold off on co-authoring anything with any
VeriSign employee for the time being.

Re: that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net ) (longish)

[Daniel Karrenberg]

On 23.07 22:30, Simon Waters wrote:
>  
> The abstract doesn't mention that the TTL on NS records is found to be
> important for scalability of the DNS. 

Sic!

And it is the *child* TTL that counts for most implementations.

Re: VeriSign's rapid DNS updates in .com/.net

[william(at)elan.net]

On Fri, 23 Jul 2004, Duane Wessels wrote:

> 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.

Do they really send A6 queries? Haven't we decided to go back to  now?
 
-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: VeriSign's rapid DNS updates in .com/.net

[Duane Wessels]

> 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.

Re: VeriSign's rapid DNS updates in .com/.net

[Matt Larson]

On Thu, 22 Jul 2004, Paul Vixie wrote:
> 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.

On Fri, 23 Jul 2004, Paul Vixie wrote:
> 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.

On Thu, 22 Jul 2004, Daniel Karrenberg wrote:
> 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
--
Matt Larson <[EMAIL PROTECTED]>
VeriSign Naming and Directory Services

RE: VeriSign's rapid DNS updates in .com/.net

[Brian Battle]

Petri Helenius wrote:

> What would be your suggestion to achieve the desired
> effect that many seek by lower TTL's, which is changing
> A records to point to available, lower load servers at
> different times?

On a similar note (and not viewing the issue through 
the usual spam-colored glasses):

Some people are using low dns TTLs in disaster recovery
setups, so that in the event of a disaster at a primary
site, services can be switched over to new servers at a
secondary site via easy and fast DNS changes?  If the TTLs
are too long, all the cached records will continue to
point at the servers which might no longer exist -- until
they expire.  This is another situation where low TTLs 
can be beneficial.

Are there any other uses for low dns TTLs that haven't
been brought up in this thread?

And what is a "low TTL" being classified as?  30 minutes?
10 minutes?  5 minutes?

-Brian

Re: that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net ) (longish)

[Valdis . Kletnieks]

On Fri, 23 Jul 2004 22:30:46 BST, Simon Waters <[EMAIL PROTECTED]>  said:

> I think relying on accurate DNS information to distinguish spammers from
> genuine senders is at best shakey currently, the only people I can think
> would suffer with making it easier and quicker to create new domains
> would be people relying on something like SPF, but I think that just
> reveals issues with SPF, and the design flaws of SPF shouldn't influence
> how we should manage the DNS.

Ahh.. but if SPF (complete with issues and design flaws) is widely deployed, we
may not have any choice regarding whether its issues and flaws dictate the DNS
management.

Remember that we've seen this before - RFC2052 didn't specify a '_', RFC2782
does.  And we all know where BIND's "delegation-only" came from


pgpXkHSYEKm4D.pgp
Description: PGP signature

Re: that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net ) (longish)

[Simon Waters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
| Date: Fri, 23 Jul 2004 17:01:54 +
| From: Paul Vixie <[EMAIL PROTECTED]>
| Subject: that MIT paper again (Re: VeriSign's rapid DNS updates in
.com/.net )
|
|>>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.
| http://nms.lcs.mit.edu/papers/dns-imw2001.html
I think most people are probably way too busy. I'll comment, and Paul
can tell me where I am wrong or incomplete ;)
I'm slightly concerned that the authors think web traffic is the big
source of DNS, they may well be right (especially given one of the
authors is talking about his own network), but my quick glance at the
type of queries shouts to me that SMTP (and email related traffic,
RBL's, etc) generate a disproportionate amount of wide area DNS traffic
byte for byte of data. I would think this is one that is pretty easy to
settle for specific networks. In particular I see a lot of retries
generated by email servers for UBE and virus dross (in our case for upto
5 days), when human surfers have famously given up the domain as dead
after the first 8 seconds. Perhaps if most people preview HTML in
emails, surfing and email access to novel URI are one and the same.
They conclude that the great bulk of benefit from sharing a DNS cache is
obtained in the first 10 to 20 clients. Although they scale this only to
1000+ clients, maybe some NANOG members can comment if they have scaled
DNS caches much bigger than this, but I suspect a lot of the scaling
issues are driven by maintainance costs and reliability, since DNS
doesn't generate much WAN traffic in comparison to HTTP for most people
here (let's face it the root/tld owners are probably the only people who
even think about bandwidth of DNS traffic).
They conclude the TTL on A records isn't so crucial.
The abstract doesn't mention that the TTL on NS records is found to be
important for scalability of the DNS. Probably the main point Paul wants
us to note. Just because the DNS in insensitive to slight changes in A
record TTL doesn't mean TTL doesn't matter on other records.
The paper leaves a lot of hanging question about "poor performance",
the number of unanswered queries, and poor latency, which I'm sure can
be pinned down to the generally poor state of the DNS (both forward and
especially reverse), and a few bad applications.
The big difference between the places/times studied, suggests to me how
the DNS performs depends a lot on what mix of questions you ask it.
They suggest not passing on unqualified names would lose a lot of fluff
(me I still think big caches could zone transfer "." and save both
traffic and, more importantly for the end users, latency, but that goes
further than their proposal). Remember resolvers do various interesting
things with unqualified names depending who coded them and when.
The paper doesn't pass any judgement on types of lookups, but obviously
not all DNS lookups are equal from the end user perspective. For example
reverse DNS from HTTP server is typically done off the critical path
(asynchronously), where as the same reverse lookup may be in the
critical path for deciding whether to accept an email message (not that
most people regard email as that time critical). Be nice to do a study
classifying them along the lines of "DNS lookups you wait for", "DNS
lookups that slow things down", "DNS lookups that have to be done by
Friday for the weekly statistics".
Some *nix vendor(s?) should make sure loghost is in /etc/hosts or not in
/etc/syslog.conf by default by the sound of it ;)
As regards rapid update by Verisign - bring it on - I'm always
embarassed to tell clients they may have to wait upto 12 hours for a new
website in this day and age. And any errors that gets made in the
initial setup takes too long to fix, I don't want to be setting up a
site 3PM Friday, and having to check it Monday morning to discover some
typo means it is Tuesday before it works, when in a sane world one TTL +
5 minutes is long enough.
I think relying on accurate DNS information to distinguish spammers from
genuine senders is at best shakey currently, the only people I can think
would suffer with making it easier and quicker to create new domains
would be people relying on something like SPF, but I think that just
reveals issues with SPF, and the design flaws of SPF shouldn't influence
how we should manage the DNS.
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQFBAYOEGFXfHI9FVgYRApWTAKCupO6Eo5i0QtDqEuYs5d1xgEMetgCgjFJf
LQBGn1G1gsdbKlg8pagoEVM=
=fu+g
-END PGP SIGNATURE-

Re: VeriSign's rapid DNS updates in .com/.net

[Randy Bush]

> so, let's increase dynamicism of domain addition, but let's please
> not also increase dynamicism of delegation change and domain deletion.

dear customer, you can have wheat bread today, but rye takes a
day.  here is a url which explains the reasons in obscure technical
terms.  right; bloody likely.

we are here to serve the customer.  the black hats use the same
services that the good customers use.  do not cut off nose to spite
face.

and, as i said a few years back, in the long run, the spammers i
fear are the big business bulk mailers.  it is they who fill my
post box at discounted postal rates.  and they look a lot like
'legitimate' customers.

randy

that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net )

[Paul Vixie]

i'd said:

> > 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.

someone asked me:

> Would you happen to have the URL for the MIT paper?  I meant to keep it
> to read at a latertime, but it seems I deleted the message.

http://nms.lcs.mit.edu/papers/dns-imw2001.html

Re: VeriSign's rapid DNS updates in .com/.net

[Eric Brunner-Williams in Portland Maine]

I don't want to digress into a spam-l or asrg standard thread, but I do want
to point out the similarity of what I think are ad networks that manage
sets of write-engines (aka "zombies") in the blog-spam (http) problem space
with the canonical abuse-desk/xdsl swamp meta-thread on nanog.

I'm observing rotation of write-side assets (dsl zomb-o-the-moment), and
rotation of ad inventory (variation on viagra/paxil/casino/xxx domains.

This is in response to the comment that begins
> Let's just be clear that not all sites mentioned in spam are profiting
> ...

Which was in reply to a comment that concluded
> Spam doesn't occur in a vacuum.  The other half is the "site(s)" profiting 
> ...

Eric

Re: VeriSign's rapid DNS updates in .com/.net

[Paul Vixie]

> >...  so, let's increase dynamicism of domain addition, but let's please
> >not also increase dynamicism of delegation change and domain deletion.
>
> What would be your suggestion to achieve the desired effect that many seek
> by lower TTL's, which is changing A records to point to available, lower
> load servers at different times?

"get over it."

> I did read the point that lower TTL's should only be used when
> appropriate but if most high-traffic sites use low TTL's, the point
> about the rest is moot. (with the exception of the root-servers) The
> load will be seen on ISP resolvers, specially on consumer networks.

that's not even the worst of it.

many business plans throughout history have involved virtualizing
something that used to be physical, or driving a bus through a loophole,
or both.  i'm happy to see dns still working lo these 25 years later,
but the terminology has improved to the point where i can make my
complaints more exact.  what is dns exactly, and what isn't it?

dns is a distributed, reliable, autonomous, coherent database.

dns is not a directory service.  if you want a directory service you
probably want soundex rather than wildcards, and you probably want
something that's specific to a protocol (like web browsing) rather than
something that also affects e-mail, ssh, and everything else.

dns is not a mapping service.  incoherency is bad.  an answer should
depend on the question (which means name, class, and type) and on the
time the question was asked.  offering different results when the same
question is asked at the same time is "deliberate incoherence".  when
once upon a time yelling at akamai for doing this, i called it "stupid
dns tricks".

i remain open to the possibility that a standards effort will someday
add directory services, or mapping services, to dns.  but delivering
such services without protocol changes is an abuse of a loophole, not
"innovation."

note that immediate updates for .ORG and now .COM/.NET are completely
within the definition of dns and i'm happy to see people doing it.  (in
isc's own .ORG bid, we also proposed to have it work this way.)  i say
this in case someone mistakenly believes that this is not a new thread.

Re: VeriSign's rapid DNS updates in .com/.net

[Daniel Senie]

At 10:05 AM 7/23/2004, Christian Kuhtz wrote:


On 7/23/04 5:29 AM, "Richard Cox" <[EMAIL PROTECTED]> wrote:
>
> On Thu, 22 Jul 2004 15:27:37 -1000 Randy Bush <[EMAIL PROTECTED]> wrote:
>
> | all they need to do is register foo.bar with delegation to their
> | dns servers, and change a third level domain name at will.
>
> Er, no.  They have of course tried that already!
>
> By registering foo.bar with delegation to THEIR dns servers gives full
> identification of THEIR dns servers, and the host or upstream of those
> servers can (and often does) start invoking their acceptable use policy.
> If not, then all the considerations that Paul V. recently cited about
> neighbours who allow bad things on their network, start to kick in.
>
> The scenario I have outlined - now well established, and the mechanism
> understood - allows the malfeasants to operate on the 'net with zero
> traceability of their identity or location, based on everything they do
> being able to be done through zombied Windows PCs or open(ed) proxies.
The distribution of spam is only half of the economy at work here.  Spam
doesn't occur in a vacuum.  The other half is the "site(s)" profiting from
the spam.
Let's just be clear that not all sites mentioned in spam are profiting at 
all. Spammers mention sites unrelated to what they're advertising to:

1) throw off blocklists which attempt to build lists of sites mentioned in 
spam.

2) purposely hurt the reputation of sites by getting blocklists to mention 
those sites

3) and possibly cause flash traffic loads to sites that would otherwise not 
get high loads.

Sites mentioned without permission common. Be clear with any attempt to go 
after sites "profiting" from spam to explain how you will only affect those 
who are really profiting and have given their permission.

Re: VeriSign's rapid DNS updates in .com/.net

[Christian Kuhtz]

On 7/23/04 5:29 AM, "Richard Cox" <[EMAIL PROTECTED]> wrote:

> 
> On Thu, 22 Jul 2004 15:27:37 -1000 Randy Bush <[EMAIL PROTECTED]> wrote:
> 
> | all they need to do is register foo.bar with delegation to their
> | dns servers, and change a third level domain name at will.
> 
> Er, no.  They have of course tried that already!
> 
> By registering foo.bar with delegation to THEIR dns servers gives full
> identification of THEIR dns servers, and the host or upstream of those
> servers can (and often does) start invoking their acceptable use policy.
> If not, then all the considerations that Paul V. recently cited about
> neighbours who allow bad things on their network, start to kick in.
> 
> The scenario I have outlined - now well established, and the mechanism
> understood - allows the malfeasants to operate on the 'net with zero
> traceability of their identity or location, based on everything they do
> being able to be done through zombied Windows PCs or open(ed) proxies.

The distribution of spam is only half of the economy at work here.  Spam
doesn't occur in a vacuum.  The other half is the "site(s)" profiting from
the spam.  


*
The information transmitted is intended only for the person or entity to which it is 
addressed and may contain confidential, proprietary, and/or privileged material.  Any 
review, retransmission, dissemination or other use of, or taking of any action in 
reliance upon, this information by persons or entities other than the intended 
recipient is prohibited.  If you received this in error, please contact the sender and 
delete the material from all computers. 113

Re: VeriSign's rapid DNS updates in .com/.net

[Petri Helenius]

Paul Vixie wrote:
so do i. but more importantly, i agree with daniel that the next thing
that's going to happen as a result is that there will be pressure toward
lower ttl's.  and i further agree with daniel that lower ttl's would be
bad.  so, let's increase dynamicism of domain addition, but let's please
not also increase dynamicism of delegation change and domain deletion.
 

What would be your suggestion to achieve the desired effect that many 
seek by lower TTL's, which is changing A records to point to available, 
lower load servers at different times? I did read the point that lower 
TTL's should only be used when appropriate but if most high-traffic 
sites use low TTL's, the point about the rest is moot. (with the 
exception of the root-servers) The load will be seen on ISP resolvers, 
specially on consumer networks.

Pete

Re: VeriSign's rapid DNS updates in .com/.net

[Richard Cox]

On Thu, 22 Jul 2004 15:27:37 -1000 Randy Bush <[EMAIL PROTECTED]> wrote:

| all they need to do is register foo.bar with delegation to their
| dns servers, and change a third level domain name at will.

Er, no.  They have of course tried that already!

By registering foo.bar with delegation to THEIR dns servers gives full
identification of THEIR dns servers, and the host or upstream of those
servers can (and often does) start invoking their acceptable use policy.
If not, then all the considerations that Paul V. recently cited about
neighbours who allow bad things on their network, start to kick in.

The scenario I have outlined - now well established, and the mechanism
understood - allows the malfeasants to operate on the 'net with zero
traceability of their identity or location, based on everything they do
being able to be done through zombied Windows PCs or open(ed) proxies.

-- 
Richard Cox

Re: VeriSign's rapid DNS updates in .com/.net

[Paul Vixie]

because i have sometimes been accused of being unfair to markk, i checked.

[EMAIL PROTECTED] (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.
-- 
Paul Vixie

Re: VeriSign's rapid DNS updates in .com/.net

[Paul Vixie]

> I welcome the change.

so do i.  but more importantly, i agree with daniel that the next thing
that's going to happen as a result is that there will be pressure toward
lower ttl's.  and i further agree with daniel that lower ttl's would be
bad.  so, let's increase dynamicism of domain addition, but let's please
not also increase dynamicism of delegation change and domain deletion.
-- 
Paul Vixie

Re: VeriSign's rapid DNS updates in .com/.net

[Daniel Karrenberg]

On 22.07 14:46, Randy Bush wrote:
> 
> ... the TTL issue is almost entirely NS RRs, ...
> of course, almost all date in the gtlds are NS RRs, so the worry about
> TTL crank-down holds, though just for silly gtld servers.  then again,
> they're paid to serve.

This assumes rational behavior of a lot of zone admins. YMMV

Of course rational behavior may be increased by information and education.

Daniel

Re: VeriSign's rapid DNS updates in .com/.net

[Eric Brunner-Williams in Portland Maine]

Richard wrote:
> ... the return path provides ...

This was where I ended up also. As Barry and others have discussed on the
asrg, the write-side is throw-away assets. The "return path" is where the
persistence of the names used is greater and the value to the scheme is
realized.

and Randy wrote:
> all they need to do is register foo.bar
> with delegation to their dns servers, and change a third level
> domain name at will.

Yeah. But that's where registrars and registries can interpose on the
scheme. The static 2LD with a twinkling constelation of 3LDs is still
vulnerable. A run of twinkling 2LDs is harder for registrars and/or
registries to break, cross registries and registrars. There may be
fewer points of failure in the NS-set used for a particular campaign.

Eric

Re: VeriSign's rapid DNS updates in .com/.net

[william(at)elan.net]

On Fri, 23 Jul 2004, Richard Cox wrote:

> The key here is not registration but change.  Currently, while spammers
> and other malfeasants have the ability to send out through compromised
> proxies and zombied PCs, there is little that can be done to identify
> them until they require a response, and then the return path provides
> some traceability via the IP addresses used, at least for nameservers.
> 
> One of the latest spammer exploits involves relying on compromised
> PCs for hosting of websites and DNS: which, coupled with the ability
> to update the root DNS in close-to-real-time, means that the entire
> hosting operation including nameservers can be based on compromised
> boxes, often with an encrypted/obfuscated link back to the real point
> of control, and that is significantly harder to track.  This becomes
> of rather greater significance if the hosting is for a phishing site.

That is one of the main reasons why I don't like that Verisign has removed
ability to find data on how list of nameservers for domain and more ip 
address of nameserver might have been changed. The only thing we can 
see is what whois shows (=bulk zone data) which is just one time/day
snapshot while spammer may have changed the ip address of nameserver
many times during the day to point to different zombie PCs.

I hope Matt can get through to correct people and deltas will be available
for those already doing bulk zone downloads.

> The demand for extra domains serves the registrars' business model well.
> When a contact address is proved to be bogus, and at the end of 15 days
> the domain complained of is in consequence shut down, it does not seem
> to occur to most registrars that the other (say) six hundred - perhaps
> thousands of domains - that were registered by the same person with the
> identical contact details, must also have bogus contact details and so
> should be automatically shut down.  No, an individual complaint seems
> to be needed in each case, which means that the malfeasants are given
> 15 days from the first appearance of EACH domain during which the
> entire domain is, as it were, bulletproof.

It seems that by these policies registries are actively helping out spammers
while claiming to be neutral party. But in reality they know full well who 
the registrant of the domain is and that they deliberately breaking ICANN
rules but they do not close their account and allow them to register more
domains with false data. This "neutral party" excuse also leads to most
domain registries refusing spam compaints, again they know exactly who it
is that registers these domain and can definetly see they are spammer, but 
they will not do anything about it because spammers are good customers
who register lots of domains.

This situation not helping in trying to stop this epidemic.

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: VeriSign's rapid DNS updates in .com/.net

[Randy Bush]

> The key here is not registration but change.  Currently, while spammers
> and other malfeasants have the ability to send out through compromised
> proxies and zombied PCs, there is little that can be done to identify
> them until they require a response, and then the return path provides
> some traceability via the IP addresses used, at least for nameservers.
> 
> One of the latest spammer exploits involves relying on compromised
> PCs for hosting of websites and DNS: which, coupled with the ability
> to update the root DNS in close-to-real-time, means that the entire
> hosting operation including nameservers can be based on compromised
> boxes, often with an encrypted/obfuscated link back to the real point
> of control, and that is significantly harder to track.  This becomes
> of rather greater significance if the hosting is for a phishing site.
> 
> The root DNS is controlled through the registrar, and what contact
> information is held by the registrars frequently turns out to be at
> best highly imaginative.

aside from your confusion between the root and second level domain
names, this is still fud.  all they need to do is register foo.bar
with delegation to their dns servers, and change a third level
domain name at will.

randy

Re: VeriSign's rapid DNS updates in .com/.net

[Richard Cox]

On Thu, 22 Jul 2004 17:24:07 -0700
"Robert L Mathews" <[EMAIL PROTECTED]> wrote:

| At 7/22/04 10:08 AM, Paul Vixie wrote:
|
|> the primary beneficiaries of this new functionality are spammers
|> and other malfeasants
|
| I think you're suggesting that such people will register domain
| names and use them right away (which may be true), and that the
| lack of a delay enables them to do things they couldn't otherwise
| do (which isn't).

The key here is not registration but change.  Currently, while spammers
and other malfeasants have the ability to send out through compromised
proxies and zombied PCs, there is little that can be done to identify
them until they require a response, and then the return path provides
some traceability via the IP addresses used, at least for nameservers.

One of the latest spammer exploits involves relying on compromised
PCs for hosting of websites and DNS: which, coupled with the ability
to update the root DNS in close-to-real-time, means that the entire
hosting operation including nameservers can be based on compromised
boxes, often with an encrypted/obfuscated link back to the real point
of control, and that is significantly harder to track.  This becomes
of rather greater significance if the hosting is for a phishing site.

The root DNS is controlled through the registrar, and what contact
information is held by the registrars frequently turns out to be at
best highly imaginative.

In removing the previous delays in updating root DNS, the registrars
have removed the last obstacle to making hosting totally-untraceable:
and then the only record of a hosting activity will be whatever data
is held by the registrar.  The only impact of the changes that ICANN
made to improve whois-accuracy, has been that the malfeasants are now
registering more domains, so that they can rely on the mandated 15-day
grace period during which when the registrar is required to keep their
domain up even though the provided contact details are totally bogus.

The demand for extra domains serves the registrars' business model well.
When a contact address is proved to be bogus, and at the end of 15 days
the domain complained of is in consequence shut down, it does not seem
to occur to most registrars that the other (say) six hundred - perhaps
thousands of domains - that were registered by the same person with the
identical contact details, must also have bogus contact details and so
should be automatically shut down.  No, an individual complaint seems
to be needed in each case, which means that the malfeasants are given
15 days from the first appearance of EACH domain during which the
entire domain is, as it were, bulletproof.

-- 
Richard Cox

Re: VeriSign's rapid DNS updates in .com/.net

[Randy Bush]

> But the new policy does allow normal people to do something they couldn't 
> otherwise do: have a working .com/.net Web site and e-mail in a few 
> minutes. That's good for legitimate domain owner happiness.
> 
> By far the number one question customers ask my (hosting) company when 
> they sign up is "When will it start working?". It's almost embarrassing 
> to tell these poor people "ahem... it probably won't work for a day or 
> so, and it's a bit random -- your friends might find it works before you 
> do, so please don't complain if that happens", etc.
> 
> It's certainly true that a day's wait isn't the end of the world, but 
> these people are anxious, and it is a source of confusion, bother and 
> worry for them.

bingo!  and the TTL issue is almost entirely NS RRs, as Sam Stickland
<[EMAIL PROTECTED]> pointed out in the article from the usual
suspects at mit/lcs, .
of course, almost all date in the gtlds are NS RRs, so the worry about
TTL crank-down holds, though just for silly gtld servers.  then again,
they're paid to serve.

randy

Re: VeriSign's rapid DNS updates in .com/.net

[Chris Brenton]

On Thu, 2004-07-22 at 20:24, Robert L Mathews wrote:
>
> At 7/22/04 10:08 AM, Paul Vixie wrote:
> 
> >the primary beneficiaries of this
> >new functionality are spammers and other malfeasants
> 
> I think you're suggesting that such people will register domain names and 
> use them right away (which may be true), and that the lack of a delay 
> enables them to do things they couldn't otherwise do (which isn't).

Actually, this *does* make the spammer's lives a whole lote easier. See
my post to Bugtraq from about a year ago titled "Permitting recursion
can allow spammers to steal name server resources". It pretty much
hinges on the spammers finding an authority that will react quickly to
change requests.

Worst part is a year after that post I still see this activity taking
place. :(

HTH,
Chris

Re: VeriSign's rapid DNS updates in .com/.net

[Robert L Mathews]

At 7/22/04 10:08 AM, Paul Vixie wrote:

>the primary beneficiaries of this
>new functionality are spammers and other malfeasants

I think you're suggesting that such people will register domain names and 
use them right away (which may be true), and that the lack of a delay 
enables them to do things they couldn't otherwise do (which isn't).

Plenty of spammers register lots of .com domain names and let them sit 
for a little while before using them; if you're a committed spammer, it's 
obviously trivial to just get three days ahead of the game. The policy 
change doesn't allow evildoers to do anything they couldn't already do 
with a tiny amount of forethought (or by registering a .biz, .org, .info 
or .us domain, for that matter).

But the new policy does allow normal people to do something they couldn't 
otherwise do: have a working .com/.net Web site and e-mail in a few 
minutes. That's good for legitimate domain owner happiness.

By far the number one question customers ask my (hosting) company when 
they sign up is "When will it start working?". It's almost embarrassing 
to tell these poor people "ahem... it probably won't work for a day or 
so, and it's a bit random -- your friends might find it works before you 
do, so please don't complain if that happens", etc.

It's certainly true that a day's wait isn't the end of the world, but 
these people are anxious, and it is a source of confusion, bother and 
worry for them.

I welcome the change.

-- 
Robert L Mathews, Tiger Technologieshttp://www.tigertech.net/

 "There are many who dare not kill themselves for fear of what the
  neighbours might say."  -- Cyril Connolly

Re: VeriSign's rapid DNS updates in .com/.net

[william(at)elan.net]

On Thu, 22 Jul 2004, Daniel Karrenberg wrote:

> What I am concerned about is the pressure to lower TTLs across the board
> if the increase in zone update speed creates expectations that it alone
> cannot fulfill. 
>
> I observe this being sold as "instantaneous updates" instead of
> "instantaneous additions".  When this becomes clear the pressure will be
> to deliver what the salespeople promised.  This will result inthe obvious
> "soloution": Lower TTLs everywhere. 

What you're suggesting is that once Verisign marketing force moves in, this
will cause pressure ("imitating Verisign", who really does it?) on marketing 
department of ISPs and DNS hosting providers to offer same level service?

I agree with you there, but I think most you will see are marketing by 
companies offering outsourced dns servers, such as what is done by Enom
and or Zonedit. In these cases however, most such dns service providers 
already do offer to their customers lower then normal TTL.

And greater majority of domains are not hosted on such provider but with
ISP that is taking care of the customer's entire DNS configuration and 
does not need to change ip that often. I don't think this puts pressure on 
such providers to change TTL.

So while some increase in genereal TTL may happen, I dont think it will 
be overwhelming so as to cause serious alarm.

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: VeriSign's rapid DNS updates in .com/.net

[Eric Brunner-Williams in Portland Maine]

> 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?

Do you want me to answer that wearing my hired-by-NeuStar-to-write-.biz hat
or my fired-by-NeuStar-for-trying-to-policy-.biz hat?

Or my almost-anybody-but-NSI/VGRS hat?

;-)

Re: VeriSign's rapid DNS updates in .com/.net

[Eric Brunner-Williams in Portland Maine]

Mark,

I've been looking at spam in blogs, that is paxil et al domain names that
are POSTed into blogs as comments.

An example (from http://wampum.wabanaki.net/archives/000794.html, a post
on this very subject) follows this reply to you.

Some number of URLs are presented to engines that index this blog, and
as long as the data generated from those indexings (rankings) has value,
or the GET captured pages are cached by the indexing engines, value is
transfered from the host blog to the producers of ratings, or the producers
of means to obtain an increase in ratings, or the rated domain name.

One example I used earlier was a domain name owned by a major pharmacutical
company, and inserted in as many blogs as I cared to look at.

For want of a better term, I feel like I'm looking at an ad network (zombie
writer population) that performs ad placements (from xdsl puddles in Italy
or elsewhere) for buyers. It isn't banner-ads that are being placed, but a
latent index ranking that will be harvested within some few number of days
after placement.

Here is one viewed from an apache logfile:
customer72-236.mni.ne.jp - - [22/Jul/2004:13:31:53 -0400] "POST 
/cgi-bin/mt-comments.cgi?entry_id=339 HTTP/1.0" 200 1713

Entry 393 was posted on July 15, 2003, a little over a year ago. The attempted
POST is ment not be detected by any means other than exhaustive indexing of
some weblog.

I think I'm looking at a click-through model that is defined by a theft of
advertizing value, whether banners for eyeballs, or tags for ranking. I'm
getting redundant, but I've got two early readers pulling my fingers off
the keyboard and onto their texts.

As long as the names are either indexed, or resolve, the covert ad works.

Thinking about reducing the persistence of resolution of covert placed
names has caused me to think about spam and agility. For my part, it is,
as you pointed out, conjecture. I'm too busy trying to get my little
registrar business off the deck to perform "studies". But as I look at
the example (below), it seems interesting to think about the resolution
of the names and the delivery of the names (in spam) as potentially a
synchronous event. That's why "instant ad" seems abuse prone to me, and
"instant mod" even more so.

There appear to be 15 URLs embedded in the comment below, which I selected
simply for having "levitra" in it.

As always, YMMV, and yes, I worked for an ad network (Engage/Flycast/CMGI),
and there is no 1x1 tracking gif anywhere in this message.
Eric

--- begin ---
COMMENT:
AUTHOR: http://www.fabuloussextoys.com
EMAIL: [EMAIL PROTECTED]
IP: 81.152.188.36
URL: http://www.fabuloussextoys.com
DATE: 06/08/2004 09:16:22 AM
The actor who plays http://www.888.com Connor in Angel will not bereturning for the 
http://www.mobilesandringtones.com fifth season of Angel. The actor will guest star in 
one http://www.celebtastic.com episode at the start of the http://www.ringtonespy.com 
season. The producers decided not to http://www.levitra-express.com pick up the 
actor's contract http://www.williamhill.co.uk for another season, as the character 
didn't have a http://www.cialis-express.com place to fit into the new story arc. 
Vincent is the second actor to http://www.adultfriendfinder.com leave the show, as 
producers also http://www.unbeatablemobiles.co.uk dropped Charisma Carpenter 
http://www.mobilequicksale.com from the cast. It is widely believed these two 
http://www.unbeatablecellphones.com actors have been dropped to make 
http://www.adultfriendfinder.com way for the two additions to Angel's 
http://www.lookforukhotels.com cast next season. James http://www.dating999.com 
Marsters is to join the cast ht!
 tp://www.adultfriendfinder.com of Angel next season,

--- end ---

Re: VeriSign's rapid DNS updates in .com/.net

[william(at)elan.net]

On Thu, 22 Jul 2004, Eric Brunner-Williams in Portland Maine wrote:

> > 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.

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?

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: VeriSign's rapid DNS updates in .com/.net

[Valdis . Kletnieks]

On Thu, 22 Jul 2004 17:04:24 EDT, Mark Kosters said:

> 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.

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)...



pgps3c9rl4PqG.pgp
Description: PGP signature

Re: VeriSign's rapid DNS updates in .com/.net

[Mark Kosters]

On Thu, Jul 22, 2004 at 08:27:45PM +, Eric Brunner-Williams in Portland Maine 
wrote:
> > 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? If this was
true, maybe those registries who do perform this particular service today
ought to slow down their update frequency.

Mark

-- 

Mark Kosters[EMAIL PROTECTED]   Verisign Applied Research

Re: VeriSign's rapid DNS updates in .com/.net

[Eric Brunner-Williams in Portland Maine]

> 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

Re: VeriSign's rapid DNS updates in .com/.net

[Pete Schroebel]

- Original Message - 
From: "Daniel Karrenberg" <[EMAIL PROTECTED]>
To: "Paul Vixie" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 22, 2004 3:05 PM
Subject: Re: VeriSign's rapid DNS updates in .com/.net


>
> On 22.07 17:08, Paul Vixie wrote:
> >
> >   therefore if there were a drop in TTL for root-zone data, it would
> > only be a multiplier against 2.1% of f-root's present volume.
>
> 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 root servers that have to deal with
> much lesser query loads and might feel the impact of lowered TTLs
> much more.
>
> > ... and the impact of
> > having it in many TLD's will be to put downward pressure on TTL's.  this
> > all needs to be looked at very carefully.
>
> Yes, we need to keep an eye on this and argue against lowering TTLs
> across the board for little good reasion.
>
>
Infospace / Authorize Net and their successors have their ttl's set for 10
minutes and that just plain goofy. Plus, TTL's at 600 or below have always
been the calling card for a spammer; . . . er not that I am accusing them of
spamming, rather they are just straining dns queries.

Peter

Re: VeriSign's rapid DNS updates in .com/.net

[Daniel Karrenberg]

On 22.07 21:05, an alter ego of Daniel Karrenberg wrote:
> 
> I am worried about all the other root servers that have to deal with
> much lesser query loads and might feel the impact of lowered TTLs
> much more. 

Of course I meant "all the other DNS servers".

Daniel

Re: VeriSign's rapid DNS updates in .com/.net

[Daniel Karrenberg]

On 22.07 17:08, Paul Vixie wrote:
> 
>   therefore if there were a drop in TTL for root-zone data, it would
> only be a multiplier against 2.1% of f-root's present volume.

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 root servers that have to deal with
much lesser query loads and might feel the impact of lowered TTLs
much more. 

> ... and the impact of
> having it in many TLD's will be to put downward pressure on TTL's.  this
> all needs to be looked at very carefully.

Yes, we need to keep an eye on this and argue against lowering TTLs 
across the board for little good reasion.

RE: VeriSign's rapid DNS updates in .com/.net (fwd from ml)

[Sam Stickland]

I got forwarded this URL from Patrick McManus. I haven't had a chance to
read the paper myself yet so I won't comment on it. I've included the link
and the abstract below.

A choice quote is "these results suggest that the performance of DNS is
not as dependent on aggressive caching as is commonly believed, and that
the widespread use of dynamic, low-TTL A-record bindings should not
degrade DNS performance."

http://nms.lcs.mit.edu/papers/dns-imw2001.html



Abstract:

This paper presents a detailed analysis of traces of DNS and associated 
TCP traffic collected on the Internet links of the MIT Laboratory for 
Computer Science and the Korea Advanced Institute of Science and 
Technology (KAIST). The first part of the analysis details how clients at 
these institutions interact with the wide-area DNS system, focusing on 
performance and prevalence of failures. The second part evaluates the 
effectiveness of DNS caching. 

In the most recent MIT trace, 23% of lookups receive no answer; these 
lookups account for more than half of all traced DNS packets since they 
are retransmitted multiple times. About 13% of all lookups result in an 
answer that indicates a failure. Many of these failures appear to be 
caused by missing inverse (IP-to-name) mappings or NS records that point 
to non-existent or inappropriate hosts. 27% of the queries sent to the 
root name servers result in such failures. 

The paper presents trace-driven simulations that explore the effect of 
varying TTLs and varying degrees of cache sharing on DNS cache hit rates. 
The results show that reducing the TTLs of address (A) records to as low 
as a few hundred seconds has little adverse effect on hit rates, and that 
little benefit is obtained from sharing a forwarding DNS cache among more 
than 10 or 20 clients. These results suggest that the performance of DNS 
is not as dependent on aggressive caching as is commonly believed, and 
that the widespread use of dynamic, low-TTL A-record bindings should not 
degrade DNS performance. 

Sam

On Thu, 22 Jul 2004, Sam Stickland wrote:

> 
> I think I ought to qualify my earlier email - I certainly didn't mean to 
> suggest that this would happen. I meant to merely comment on what the 
> expected increase in load might be if we did see a trend towards lower 
> TTLs.
> 
> Any trend towards lower TTLs would be outside of Verisign's control 
> anyhow, and if it did happen, it would no doubt be a gradual effect. Which 
> brings me back to my original question - does anyone know of any stastics 
> for TTL values?
> 
> Sam
> 
> On Thu, 22 Jul 2004, Henry Linneweh wrote:
> 
> > 
> > Before a big panic starts, they can restore it back to
> > the way it was if there is an event of such proportion
> > to totally hoze the entire network or any major
> > portion of it, until they fix any major issue with
> > these changes
> > 
> > -Henry
> > 
> > --- Sam Stickland <[EMAIL PROTECTED]> wrote:
> > > 
> > > Well, a naive calculation, based on reducing the TTL
> > > to 15 mins from 24
> > > hours to match Verisign's new update times, would
> > > suggest that the number
> > > of queries would increase by (24 * 60) / 15 = 96
> > > times? (or twice that if 
> > > you factor in for the Nyquist interval).
> > > 
> > > Any there any resources out there there that have
> > > information on global 
> > > DNS statistics? ie. the average TTL currently in
> > > use.
> > > 
> > > But I guess it remains to be seen if this will have
> > > a knock on effect like 
> > > that described below. Verisign are only doing this
> > > for the nameserver 
> > > records at present time - it just depends on whether
> > > expection for such 
> > > rapid changes gets pushed on down.
> > > 
> > > Sam
> > > 
> > > On Thu, 22 Jul 2004, Ray Plzak wrote:
> > > 
> > > > 
> > > > Good point!  You can reduce TTLs to such a point
> > > that the servers will
> > > > become preoccupied with doing something other than
> > > providing answers.
> > > > 
> > > > Ray
> > > > 
> > > > > -Original Message-
> > > > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of
> > > > > Daniel Karrenberg
> > > > > Sent: Thursday, July 22, 2004 3:12 AM
> > > > > To: Matt Larson
> > > > > Cc: [EMAIL PROTECTED]
> > > > > Subject: Re: VeriSign's rapid DNS updates in
> > > .com/.net
> > > > > 
> > > > > 
> > > > &

Re: VeriSign's rapid DNS updates in .com/.net

[Paul Vixie]

duane wessels' presentation at the last eugene nanog meeting distinguished
between two kinds of traffic received at f-root during his sampling work:
crap: 97.9%; non-crap: 2.1%.  the "crap" category includes requestors who
do not seem to cache the responses they hear, thus rendering the actual TTL
moot.  therefore if there were a drop in TTL for root-zone data, it would
only be a multiplier against 2.1% of f-root's present volume.

but i agree with daniel.  the reason verisign is doing this has got to be
because ultradns does it, and .ORG therefore has marketing hoopla that
.COM/.NET lacks, and parity was needed.  the primary beneficiaries of this
new functionality are spammers and other malfeasants, and the impact of
having it in many TLD's will be to put downward pressure on TTL's.  this
all needs to be looked at very carefully.
-- 
Paul Vixie

RE: VeriSign's rapid DNS updates in .com/.net (fwd from ml)

[Sam Stickland]

I think I ought to qualify my earlier email - I certainly didn't mean to 
suggest that this would happen. I meant to merely comment on what the 
expected increase in load might be if we did see a trend towards lower 
TTLs.

Any trend towards lower TTLs would be outside of Verisign's control 
anyhow, and if it did happen, it would no doubt be a gradual effect. Which 
brings me back to my original question - does anyone know of any stastics 
for TTL values?

Sam

On Thu, 22 Jul 2004, Henry Linneweh wrote:

> 
> Before a big panic starts, they can restore it back to
> the way it was if there is an event of such proportion
> to totally hoze the entire network or any major
> portion of it, until they fix any major issue with
> these changes
> 
> -Henry
> 
> --- Sam Stickland <[EMAIL PROTECTED]> wrote:
> > 
> > Well, a naive calculation, based on reducing the TTL
> > to 15 mins from 24
> > hours to match Verisign's new update times, would
> > suggest that the number
> > of queries would increase by (24 * 60) / 15 = 96
> > times? (or twice that if 
> > you factor in for the Nyquist interval).
> > 
> > Any there any resources out there there that have
> > information on global 
> > DNS statistics? ie. the average TTL currently in
> > use.
> > 
> > But I guess it remains to be seen if this will have
> > a knock on effect like 
> > that described below. Verisign are only doing this
> > for the nameserver 
> > records at present time - it just depends on whether
> > expection for such 
> > rapid changes gets pushed on down.
> > 
> > Sam
> > 
> > On Thu, 22 Jul 2004, Ray Plzak wrote:
> > 
> > > 
> > > Good point!  You can reduce TTLs to such a point
> > that the servers will
> > > become preoccupied with doing something other than
> > providing answers.
> > > 
> > > Ray
> > > 
> > > > -----Original Message-
> > > > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > > > Daniel Karrenberg
> > > > Sent: Thursday, July 22, 2004 3:12 AM
> > > > To: Matt Larson
> > > > Cc: [EMAIL PROTECTED]
> > > > Subject: Re: VeriSign's rapid DNS updates in
> > .com/.net
> > > > 
> > > > 
> > > > Matt, others,
> > > > 
> > > > I am a quite concerned about these zone update
> > speed improvements
> > > > because they are likely to result in
> > considerable pressure to reduce
> > > > TTLs **throughout the DNS** for little to no
> > good reason.
> > > > 
> > > > It will not be long before the marketeers will
> > discover that they do not
> > > > deliver what they (implicitly) promise to
> > customers in case of **changes
> > > > and removals** rather than just additions to a
> > zone.
> > > > 
> > > > Reducing TTLs across the board will be the
> > obvious *soloution*.
> > > > 
> > > > Yet, the DNS architecture is built around
> > effective caching!
> > > > 
> > > > Are we sure that the DNS as a whole will remain
> > operational when
> > > > (not if) this happens in a significant way?
> > > > 
> > > > Can we still mitigate that trend by education of
> > marketeers and users?
> > > > 
> > > > Daniel
> > > 
> > 
> > 
> 

RE: VeriSign's rapid DNS updates in .com/.net

[Henry Linneweh]

Before a big panic starts, they can restore it back to
the way it was if there is an event of such proportion
to totally hoze the entire network or any major
portion of it, until they fix any major issue with
these changes

-Henry

--- Sam Stickland <[EMAIL PROTECTED]> wrote:
> 
> Well, a naive calculation, based on reducing the TTL
> to 15 mins from 24
> hours to match Verisign's new update times, would
> suggest that the number
> of queries would increase by (24 * 60) / 15 = 96
> times? (or twice that if 
> you factor in for the Nyquist interval).
> 
> Any there any resources out there there that have
> information on global 
> DNS statistics? ie. the average TTL currently in
> use.
> 
> But I guess it remains to be seen if this will have
> a knock on effect like 
> that described below. Verisign are only doing this
> for the nameserver 
> records at present time - it just depends on whether
> expection for such 
> rapid changes gets pushed on down.
> 
> Sam
> 
> On Thu, 22 Jul 2004, Ray Plzak wrote:
> 
> > 
> > Good point!  You can reduce TTLs to such a point
> that the servers will
> > become preoccupied with doing something other than
> providing answers.
> > 
> > Ray
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> > > Daniel Karrenberg
> > > Sent: Thursday, July 22, 2004 3:12 AM
> > > To: Matt Larson
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: VeriSign's rapid DNS updates in
> .com/.net
> > > 
> > > 
> > > Matt, others,
> > > 
> > > I am a quite concerned about these zone update
> speed improvements
> > > because they are likely to result in
> considerable pressure to reduce
> > > TTLs **throughout the DNS** for little to no
> good reason.
> > > 
> > > It will not be long before the marketeers will
> discover that they do not
> > > deliver what they (implicitly) promise to
> customers in case of **changes
> > > and removals** rather than just additions to a
> zone.
> > > 
> > > Reducing TTLs across the board will be the
> obvious *soloution*.
> > > 
> > > Yet, the DNS architecture is built around
> effective caching!
> > > 
> > > Are we sure that the DNS as a whole will remain
> operational when
> > > (not if) this happens in a significant way?
> > > 
> > > Can we still mitigate that trend by education of
> marketeers and users?
> > > 
> > > Daniel
> > 
> 
> 

Re: VeriSign's rapid DNS updates in .com/.net

[Daniel Karrenberg]

On 22.07 12:26, Stephen J. Wilcox wrote:
> 
> I dont see any reference to adjusting the TTL in the verisign announcement.

Correct.

> They say they will update the zones every 5 minutes from the registry data.
> 
> These are not the same things (or did I miss that bit?)

Correct.

> Also, isnt a lot of this dependent on the NS records in the second level gtlds 
> which is hosted by the ISPs.. so this part doesnt change?

Correct. 

What I am concerned about is the pressure to lower TTLs across the board
if the increase in zone update speed creates expectations that it alone
cannot fulfill. 

I observe this being sold as "instantaneous updates" instead of
"instantaneous additions".  When this becomes clear the pressure will be
to deliver what the salespeople promised.  This will result inthe obvious
"soloution": Lower TTLs everywhere. 

I am not sure the DNS will remain stable if TTLs are lowered to
a couple of seconds throughout.

I am suggesting clearer marketing:
"Quick additions: Yes.  Quick changes/deletions: No."

Note that I am not concerned about *judicious* lowering of TTLs 
in preparation for changes or to provide services such as akamai.
It is more a general trend of many independent actors serving nor real
purpose that worries me. 

Caveat emptor.

Daniel

RE: VeriSign's rapid DNS updates in .com/.net

[Stephen J. Wilcox]

Hang fire..

I dont see any reference to adjusting the TTL in the verisign announcement.

They say they will update the zones every 5 minutes from the registry data.

These are not the same things (or did I miss that bit?)

Also, isnt a lot of this dependent on the NS records in the second level gtlds 
which is hosted by the ISPs.. so this part doesnt change?

Steve

On Thu, 22 Jul 2004, Sam Stickland wrote:

> 
> Well, a naive calculation, based on reducing the TTL to 15 mins from 24
> hours to match Verisign's new update times, would suggest that the number
> of queries would increase by (24 * 60) / 15 = 96 times? (or twice that if 
> you factor in for the Nyquist interval).
> 
> Any there any resources out there there that have information on global 
> DNS statistics? ie. the average TTL currently in use.
> 
> But I guess it remains to be seen if this will have a knock on effect like 
> that described below. Verisign are only doing this for the nameserver 
> records at present time - it just depends on whether expection for such 
> rapid changes gets pushed on down.
> 
> Sam
> 
> On Thu, 22 Jul 2004, Ray Plzak wrote:
> 
> > 
> > Good point!  You can reduce TTLs to such a point that the servers will
> > become preoccupied with doing something other than providing answers.
> > 
> > Ray
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> > > Daniel Karrenberg
> > > Sent: Thursday, July 22, 2004 3:12 AM
> > > To: Matt Larson
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: VeriSign's rapid DNS updates in .com/.net
> > > 
> > > 
> > > Matt, others,
> > > 
> > > I am a quite concerned about these zone update speed improvements
> > > because they are likely to result in considerable pressure to reduce
> > > TTLs **throughout the DNS** for little to no good reason.
> > > 
> > > It will not be long before the marketeers will discover that they do not
> > > deliver what they (implicitly) promise to customers in case of **changes
> > > and removals** rather than just additions to a zone.
> > > 
> > > Reducing TTLs across the board will be the obvious *soloution*.
> > > 
> > > Yet, the DNS architecture is built around effective caching!
> > > 
> > > Are we sure that the DNS as a whole will remain operational when
> > > (not if) this happens in a significant way?
> > > 
> > > Can we still mitigate that trend by education of marketeers and users?
> > > 
> > > Daniel
> > 
> 
> 

RE: VeriSign's rapid DNS updates in .com/.net

[Sam Stickland]

Well, a naive calculation, based on reducing the TTL to 15 mins from 24
hours to match Verisign's new update times, would suggest that the number
of queries would increase by (24 * 60) / 15 = 96 times? (or twice that if 
you factor in for the Nyquist interval).

Any there any resources out there there that have information on global 
DNS statistics? ie. the average TTL currently in use.

But I guess it remains to be seen if this will have a knock on effect like 
that described below. Verisign are only doing this for the nameserver 
records at present time - it just depends on whether expection for such 
rapid changes gets pushed on down.

Sam

On Thu, 22 Jul 2004, Ray Plzak wrote:

> 
> Good point!  You can reduce TTLs to such a point that the servers will
> become preoccupied with doing something other than providing answers.
> 
> Ray
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> > Daniel Karrenberg
> > Sent: Thursday, July 22, 2004 3:12 AM
> > To: Matt Larson
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: VeriSign's rapid DNS updates in .com/.net
> > 
> > 
> > Matt, others,
> > 
> > I am a quite concerned about these zone update speed improvements
> > because they are likely to result in considerable pressure to reduce
> > TTLs **throughout the DNS** for little to no good reason.
> > 
> > It will not be long before the marketeers will discover that they do not
> > deliver what they (implicitly) promise to customers in case of **changes
> > and removals** rather than just additions to a zone.
> > 
> > Reducing TTLs across the board will be the obvious *soloution*.
> > 
> > Yet, the DNS architecture is built around effective caching!
> > 
> > Are we sure that the DNS as a whole will remain operational when
> > (not if) this happens in a significant way?
> > 
> > Can we still mitigate that trend by education of marketeers and users?
> > 
> > Daniel
> 

RE: VeriSign's rapid DNS updates in .com/.net

[Ray Plzak]

Good point!  You can reduce TTLs to such a point that the servers will
become preoccupied with doing something other than providing answers.

Ray

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Daniel Karrenberg
> Sent: Thursday, July 22, 2004 3:12 AM
> To: Matt Larson
> Cc: [EMAIL PROTECTED]
> Subject: Re: VeriSign's rapid DNS updates in .com/.net
> 
> 
> Matt, others,
> 
> I am a quite concerned about these zone update speed improvements
> because they are likely to result in considerable pressure to reduce
> TTLs **throughout the DNS** for little to no good reason.
> 
> It will not be long before the marketeers will discover that they do not
> deliver what they (implicitly) promise to customers in case of **changes
> and removals** rather than just additions to a zone.
> 
> Reducing TTLs across the board will be the obvious *soloution*.
> 
> Yet, the DNS architecture is built around effective caching!
> 
> Are we sure that the DNS as a whole will remain operational when
> (not if) this happens in a significant way?
> 
> Can we still mitigate that trend by education of marketeers and users?
> 
> Daniel

Re: VeriSign's rapid DNS updates in .com/.net

[Daniel Karrenberg]

Matt, others,

I am a quite concerned about these zone update speed improvements
because they are likely to result in considerable pressure to reduce
TTLs **throughout the DNS** for little to no good reason.

It will not be long before the marketeers will discover that they do not
deliver what they (implicitly) promise to customers in case of **changes
and removals** rather than just additions to a zone. 

Reducing TTLs across the board will be the obvious *soloution*. 

Yet, the DNS architecture is built around effective caching! 

Are we sure that the DNS as a whole will remain operational when
(not if) this happens in a significant way? 

Can we still mitigate that trend by education of marketeers and users? 

Daniel

Re: VeriSign's rapid DNS updates in .com/.net

[Matt Larson]

William,

On Wed, 14 Jul 2004, william(at)elan.net wrote:
> I reforward this email in hopes that it was by simple omission that nobody 
> from Verisign is yet to respond to it.

Replying to your original message has been on my to-do list.

> 1. Currently SLD deligation info for .com/.net TLDs seems to be updated about
> twice a day and new entire TLD dns zone is published as one bulk operation. 
> These changes seems to be synced pretty well to changes in whois database
> as seen at whois.crsnic.net, so listing of nameservers in whois seems 
> almost always correct. Is it my understanding that after this change SLD 
> dns delegation will not be synced to nameserver listing in whois?

You are correct that the .com/.net zone files and Whois data are
currently updated at around the same time, twice per day.  Those
processes will continue after the deployment of the rapid updates.  As
a result, the .com/.net zone files available through the zone file
access program will continue match the data currently available in
Whois.  But the .com/.net the authoritative servers will contain
changes not yet reflected in Whois.

> 2. Is it only changes in SLD delegation (listing of nameservers or ips of 
> nameservers) that will be effected?

Essentially, yes, but see below.

> Does that mean that changes to domain such as moving domain from one
> registrar to another, delition of domain will still be done once per
> day?

Yes.

> Related - what about status codes as submitted by registrar? In
> particular, would change of status that causes domain to temporarily
> or permanently not be delegated (but keeps listing of nameservers in
> whois) also be processed immediatly?

You're referring to Hold status, of which there are several kinds, all
of which keep a domain's NS records out of the .com/.net zones.  A
change in status will cause a domain's NS records to be inserted or
withdrawn from the .com/.net zones in near-real time.

> 3. Is it my understanding that with this change those who participate
> in bulk whois program will not be able to see entire history of dns
> delegation changes for the domain?

You said "bulk whois program", but I believe you're referring to the
"TLD Zone File Access Program"
(http://www.verisign.com/nds/naming/tld/).  VeriSign does not make the
bulk .com/.net Whois data available.

> In that case, you remove value of 
> participation in bulk TLD zone downloads for certain kinds of research 
> activity and in addition may actually be breaking service agreement for 
> providing this kind of data. To cover that "hole" you need provide a way
> to not only download entire TLD zone but also changes done to domain
> since last time entire TLD zone file has been published (to give an 
> example what I'm asking is ability to download "UPDATES" as in routevews 
> directory rather then entire bgp dump from "RIBS" directory).  
> 
> Please note that being able to find entire history of domain delegation 
> changes is important in quite a number of cases, for example when you 
> need to show that either your dns registrar or isp screwed up (and then
> corrected itself but does not want to admit it because that may cause them 
> to pay compensation per SLA) or to show improper unathorized use of the 
> domain, when its suspect that domain may have been hijacked (but dns has
> been changed for half an hour and then returned back) or when you're tracking
> domains used by spammers that change info from one zombie computer to another
> every 10-30 minutes (you want to be able to create entire list of zombies
> associated with such a domain and report these to ISPs, not just one or 
> two taken once or twice per day, because otherwise spammers would just 
> register different domain when that reported one is  deactivated but they
> will still keep use of the same zombies)

Right now we don't have plans to make the deltas available, but I will
make sure the right people see the suggestion and your supporting
reasons for wanting them.

> 4. Last comment is I believe that such public announcement of changes
> should to go other mail lists and not just nanog which covers primarily
> those concerned with network routing in US and Canada, but not necessarily
> with dns operations at your ISP. I'm subscribed to at least three dns 
> specific mail lists and have not seen anything there. The onece I remember
> by name are isp-dns.com, the other is bind-users, third one is I think 
> dns list at RIPE. 
> 
> I'm not suggesting you make announcement on exactly those lists (or only 
> on those lists + nanog), but if Verisign is trying to have better 
> involvement with community and making viable prior notices worldwide of 
> changes it is making to dns system, some investigation on where is it best 
> to make such notices that it would reach largest number of persons 
> concerned with dns technical support worldwide should be done. 

With over 7000 subscribers (if I'm remembering the numbers from
Susan's latest statistics s

Re: VeriSign's rapid DNS updates in .com/.net

[william(at)elan.net]

I reforward this email in hopes that it was by simple omission that nobody 
from Verisign is yet to respond to it. All questions in sections 1 - 3 are 
valid and something that directly concerns proposed changes, none of that 
had been asked before here in brief nanog discussion after Verisign's 
post on Friday. And of course, I'm still relying that its more then simple 
PR tactic that made verisign post to nanog originally and that they are 
going to consult internet engineering community before making any significant
change to most widely used TLD infrastructure and that if there are any 
problems found that would arrise from the change that the plan to address 
them would be made available.


-- Forwarded message --
Date: Mon, 12 Jul 2004 04:35:36 -0700 (PDT)
From: "william(at)elan.net" <[EMAIL PROTECTED]>
To: Matt Larson <[EMAIL PROTECTED]>
Cc: 
Subject: Re: VeriSign's rapid DNS updates in .com/.net


On Fri, 9 Jul 2004, Matt Larson wrote:

> VeriSign Naming and Directory Services (VNDS) currently generates new
> versions of the .com/.net zones files twice per day.  VNDS is
> scheduled to deploy on September 8, 2004 a new feature that will
> enable VNDS to update the .com/.net zones more frequently to reflect
> the registration activity of the .com/.net registrars in near real
> time.  After the rapid DNS update is implemented, the elapsed time
> from registrars' add or change operations to the visibility of those
> adds or changes in all 13 .com/.net authoritative name servers is
> expected to average less than five minutes.

Questions/Comments:

1. Currently SLD deligation info for .com/.net TLDs seems to be updated about
twice a day and new entire TLD dns zone is published as one bulk operation. 
These changes seems to be synced pretty well to changes in whois database
as seen at whois.crsnic.net, so listing of nameservers in whois seems 
almost always correct. Is it my understanding that after this change SLD 
dns delegation will not be synced to nameserver listing in whois?

2. Is it only changes in SLD delegation (listing of nameservers or ips of 
nameservers) that will be effected? Does that mean that changes to domain 
such as moving domain from one registrar to another, delition of domain 
will still be done once per day? Related - what about status codes as 
submitted by registrar? In particular, would change of status that causes 
domain to temporarily or permanently not be delegated (but keeps listing 
of nameservers in whois) also be processed immediatly?

> VNDS will continue to publish .com/.net zone files twice per day as
> part of the TLD Zone File Access Program. [2]  These zone files will
> continue to reflect the state of the .com/.net registry database at
> the moment zone generation begins.

3. Is it my understanding that with this change those who participate
in bulk whois program will not be able to see entire history of dns
delegation changes for the domain? In that case, you remove value of 
participation in bulk TLD zone downloads for certain kinds of research 
activity and in addition may actually be breaking service agreement for 
providing this kind of data. To cover that "hole" you need provide a way
to not only download entire TLD zone but also changes done to domain
since last time entire TLD zone file has been published (to give an 
example what I'm asking is ability to download "UPDATES" as in routevews 
directory rather then entire bgp dump from "RIBS" directory).  

Please note that being able to find entire history of domain delegation 
changes is important in quite a number of cases, for example when you 
need to show that either your dns registrar or isp screwed up (and then
corrected itself but does not want to admit it because that may cause them 
to pay compensation per SLA) or to show improper unathorized use of the 
domain, when its suspect that domain may have been hijacked (but dns has
been changed for half an hour and then returned back) or when you're tracking
domains used by spammers that change info from one zombie computer to another
every 10-30 minutes (you want to be able to create entire list of zombies
associated with such a domain and report these to ISPs, not just one or 
two taken once or twice per day, because otherwise spammers would just 
register different domain when that reported one is  deactivated but they
will still keep use of the same zombies)

> VNDS does not anticipate any negative consequences of deployment of
> rapid updates to the .com/.net zones.  However, as a courtesy we are
> providing the Internet community with 60 days advance notice of the
> change to the update process.

4. Last comment is I believe that such public announcement of changes
should to go other mail lists and not just nanog which covers primarily
those concerned with network routing in US and Canada, but 

Re: VeriSign's rapid DNS updates in .com/.net

[william(at)elan.net]

On Fri, 9 Jul 2004, Matt Larson wrote:

> VeriSign Naming and Directory Services (VNDS) currently generates new
> versions of the .com/.net zones files twice per day.  VNDS is
> scheduled to deploy on September 8, 2004 a new feature that will
> enable VNDS to update the .com/.net zones more frequently to reflect
> the registration activity of the .com/.net registrars in near real
> time.  After the rapid DNS update is implemented, the elapsed time
> from registrars' add or change operations to the visibility of those
> adds or changes in all 13 .com/.net authoritative name servers is
> expected to average less than five minutes.

Questions/Comments:

1. Currently SLD deligation info for .com/.net TLDs seems to be updated about
twice a day and new entire TLD dns zone is published as one bulk operation. 
These changes seems to be synced pretty well to changes in whois database
as seen at whois.crsnic.net, so listing of nameservers in whois seems 
almost always correct. Is it my understanding that after this change SLD 
dns delegation will not be synced to nameserver listing in whois?

2. Is it only changes in SLD delegation (listing of nameservers or ips of 
nameservers) that will be effected? Does that mean that changes to domain 
such as moving domain from one registrar to another, delition of domain 
will still be done once per day? Related - what about status codes as 
submitted by registrar? In particular, would change of status that causes 
domain to temporarily or permanently not be delegated (but keeps listing 
of nameservers in whois) also be processed immediatly?

> VNDS will continue to publish .com/.net zone files twice per day as
> part of the TLD Zone File Access Program. [2]  These zone files will
> continue to reflect the state of the .com/.net registry database at
> the moment zone generation begins.

3. Is it my understanding that with this change those who participate
in bulk whois program will not be able to see entire history of dns
delegation changes for the domain? In that case, you remove value of 
participation in bulk TLD zone downloads for certain kinds of research 
activity and in addition may actually be breaking service agreement for 
providing this kind of data. To cover that "hole" you need provide a way
to not only download entire TLD zone but also changes done to domain
since last time entire TLD zone file has been published (to give an 
example what I'm asking is ability to download "UPDATES" as in routevews 
directory rather then entire bgp dump from "RIBS" directory).  

Please note that being able to find entire history of domain delegation 
changes is important in quite a number of cases, for example when you 
need to show that either your dns registrar or isp screwed up (and then
corrected itself but does not want to admit it because that may cause them 
to pay compensation per SLA) or to show improper unathorized use of the 
domain, when its suspect that domain may have been hijacked (but dns has
been changed for half an hour and then returned back) or when you're tracking
domains used by spammers that change info from one zombie computer to another
every 10-30 minutes (you want to be able to create entire list of zombies
associated with such a domain and report these to ISPs, not just one or 
two taken once or twice per day, because otherwise spammers would just 
register different domain when that reported one is  deactivated but they
will still keep use of the same zombies)

> VNDS does not anticipate any negative consequences of deployment of
> rapid updates to the .com/.net zones.  However, as a courtesy we are
> providing the Internet community with 60 days advance notice of the
> change to the update process.

4. Last comment is I believe that such public announcement of changes
should to go other mail lists and not just nanog which covers primarily
those concerned with network routing in US and Canada, but not necessarily
with dns operations at your ISP. I'm subscribed to at least three dns 
specific mail lists and have not seen anything there. The onece I remember
by name are isp-dns.com, the other is bind-users, third one is I think 
dns list at RIPE. 

I'm not suggesting you make announcement on exactly those lists (or only 
on those lists + nanog), but if Verisign is trying to have better 
involvement with community and making viable prior notices worldwide of 
changes it is making to dns system, some investigation on where is it best 
to make such notices that it would reach largest number of persons 
concerned with dns technical support worldwide should be done. 

> Some questions and answers about rapid updates for .com/.net are
> available at http://www.verisign.com/nds/naming/rapid_update/faq.html.
>
> [1] http://www.merit.edu/mail.archives/nanog/2004-01/msg00115.html
>
> [2] http://www.verisign.com/nds/naming/tld/

Additionally I notice that on the page you included as reference to TLD
zone file information on Verisign website (link [2] above) does

RE: VeriSign's rapid DNS updates in .com/.net

[Bruce Beckwith]

Since September 2003, .ORG has offered resolution of new registrations
and changes to domain name records within 5 minutes.  This was announced
in the following release
http://www.pir.org/news/press_releases/pr_articles/2003-09-08-01

Regards,

Bruce


Bruce W. Beckwith
VP, Operations
Public Interest Registry

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Mike Lewinski
Sent: Saturday, July 10, 2004 10:36 PM
To: [EMAIL PROTECTED]
Subject: Re: VeriSign's rapid DNS updates in .com/.net


David A.Ulevitch wrote:

> I'm appreciative of this change -- but fyi, they aren't the only TLD 
> operators doing this, there are quite a few doing near-instant changes

> to their respective zones.

I just registered a new .org and it had visibility from external NS not 
more than 15 minutes later (I would have paid closer attention to just 
how long it took, but didn't even think to check on it until reading 
this thread).

Maybe I just got lucky and hit their update window (I registered ~ 
3:15AM UTC on 11-July-2004 fwiw). Anyone know the status of .org
updates?

Re: VeriSign's rapid DNS updates in .com/.net

[David A . Ulevitch]

On Jul 10, 2004, at 7:35 PM, Mike Lewinski wrote:
David A.Ulevitch wrote:
I'm appreciative of this change -- but fyi, they aren't the only TLD 
operators doing this, there are quite a few doing near-instant 
changes to their respective zones.
I just registered a new .org and it had visibility from external NS 
not more than 15 minutes later (I would have paid closer attention to 
just how long it took, but didn't even think to check on it until 
reading this thread).

Maybe I just got lucky and hit their update window (I registered ~ 
3:15AM UTC on 11-July-2004 fwiw). Anyone know the status of .org 
updates?
Nope, .org is run this way also (since the handover to udns, if I 
remember right.  I don't know of a comprehensive list of tld's in this 
setup but I would say that the list is only growing...I learn of tlds 
running in this fashion every once in a while[1].

-davidu
1: not to imply any connection to when I notice it and when it is 
actually implemented. ;)

Re: VeriSign's rapid DNS updates in .com/.net

[Suresh Ramasubramanian]

On Sat, 10 Jul 2004, David A.Ulevitch wrote:

> It also means that changes can be made to host records quickly which is 
> important for people who don't plan well or have unexpected changes 
> that they want propagated.
> 
> I'm appreciative of this change -- but fyi, they aren't the only TLD 
> operators doing this, there are quite a few doing near-instant changes 
> to their respective zones.

.biz, .info etc do this as well.

It is an excellent policy, and a convenient thing not to wait several 
hours for your new .com domain to appear online immediately.

The disadvantage is, of course, that several abusers who register domains 
at a rapid clip with these two tlds, setting < 1 minute TTL on these and 
pointing these domain names to IPs that are basically compromised boxes or 
virus infected boxes, will now also start using .com / .net

There should be some way of fixing this, like requiring registrars to do
more due diligence when registering domains, maybe, and some better /
faster procedures to take down [say] phisher domains with fake contact
info.  Well yes, there is already a process, but it could sure do with 
more streamlining.

regards
--srs

Re: VeriSign's rapid DNS updates in .com/.net

[Mike Lewinski]

David A.Ulevitch wrote:
I'm appreciative of this change -- but fyi, they aren't the only TLD 
operators doing this, there are quite a few doing near-instant changes 
to their respective zones.
I just registered a new .org and it had visibility from external NS not 
more than 15 minutes later (I would have paid closer attention to just 
how long it took, but didn't even think to check on it until reading 
this thread).

Maybe I just got lucky and hit their update window (I registered ~ 
3:15AM UTC on 11-July-2004 fwiw). Anyone know the status of .org updates?

Re: VeriSign's rapid DNS updates in .com/.net

[Alexei Roudnev]

Hmm... May be, you are correct - if you sell service to the 'consumers'
(inexperienced customers), they do not expect any delays between 'payment
completed' and 'I can see my brand new domain WWW.HOW-COOL-I-AM.COM. And
TTL's/caches do not prevent you from this, because you did not requested
this domain before.

This is still just Public relation, but very useful, I agree.

PS. I  know about other operator, I just wanted to verify, who appreciate
this improvement - I agree that it is good for average consumer market (I
want to show my new WEB to  my friends NOW, while I am on weekend
downloading my photos, and I do not want to know about 24h, IP hops, DNS
cliens, TTLs and so on ... ). One more step in making Internet the same
'simple to use' reality as houses, cars, TV




>
>
> On Jul 10, 2004, at 1:19 PM, Alexei Roudnev wrote:
>
> >
> > It is cool, but where is any value in this (I mean - 5 minutes)  rapid
> > updates for .com and other base domains? I wish rapid DNS when running
> > enterprise zone (with dynamic updates) or when running dynamic-dns
> > service
> > (for those who use dynalic IP's); but for .com and .net, it is just a
> > public
> > relation useless feature - registration time is 1 year, 5 minutes vs
> > 1/2
> > day - do not makes any difference.
>
> It makes a big difference to people who sell web/mail/etc services to
> people that includes the domain name.
>
> It means that someone who pays for a new website through an automated
> system doesn't have to wait 12-24 hours for it to be live, just a few
> minutes.
>
> It also means that changes can be made to host records quickly which is
> important for people who don't plan well or have unexpected changes
> that they want propagated.
>
> I'm appreciative of this change -- but fyi, they aren't the only TLD
> operators doing this, there are quite a few doing near-instant changes
> to their respective zones.
>
> The only thing I would still want would be the ability to create
> multiple host records of the same name but with various values.  At
> least the opposite, mutliple host names to the same value is now
> allowed.  That's good enough for me. :)
>
> -davidu
>

Re: VeriSign's rapid DNS updates in .com/.net

[David A . Ulevitch]

On Jul 10, 2004, at 1:19 PM, Alexei Roudnev wrote:
It is cool, but where is any value in this (I mean - 5 minutes)  rapid
updates for .com and other base domains? I wish rapid DNS when running
enterprise zone (with dynamic updates) or when running dynamic-dns 
service
(for those who use dynalic IP's); but for .com and .net, it is just a 
public
relation useless feature - registration time is 1 year, 5 minutes vs 
1/2
day - do not makes any difference.
It makes a big difference to people who sell web/mail/etc services to 
people that includes the domain name.

It means that someone who pays for a new website through an automated 
system doesn't have to wait 12-24 hours for it to be live, just a few 
minutes.

It also means that changes can be made to host records quickly which is 
important for people who don't plan well or have unexpected changes 
that they want propagated.

I'm appreciative of this change -- but fyi, they aren't the only TLD 
operators doing this, there are quite a few doing near-instant changes 
to their respective zones.

The only thing I would still want would be the ability to create 
multiple host records of the same name but with various values.  At 
least the opposite, mutliple host names to the same value is now 
allowed.  That's good enough for me. :)

-davidu

Re: VeriSign's rapid DNS updates in .com/.net

[Alexei Roudnev]

It is cool, but where is any value in this (I mean - 5 minutes)  rapid
updates for .com and other base domains? I wish rapid DNS when running
enterprise zone (with dynamic updates) or when running dynamic-dns service
(for those who use dynalic IP's); but for .com and .net, it is just a public
relation useless feature - registration time is 1 year, 5 minutes vs 1/2
day - do not makes any difference.

(I am not saying that it is bad; I just do not see any reason for the
celebration - anyway,  DNS system have caches and delays measured in hours,
and when you register .com you are doing it for a few years).

- Original Message - 
From: "Matt Larson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 09, 2004 12:20 PM
Subject: VeriSign's rapid DNS updates in .com/.net



VeriSign Naming and Directory Services (VNDS) currently generates new
versions of the .com/.net zones files twice per day.  VNDS is
scheduled to deploy on September 8, 2004 a new feature that will
enable VNDS to update the .com/.net zones more frequently to reflect
the registration activity of the .com/.net registrars in near real
time.  After the rapid DNS update is implemented, the elapsed time
from registrars' add or change operations to the visibility of those
adds or changes in all 13 .com/.net authoritative name servers is
expected to average less than five minutes.

The rapid update process will batch domain name adds and domain name
changes every few seconds.  The serial number in the .com/.net zones'
SOA records will increase with each batch of changes applied.  As
described in a message to the NANOG list in January [1], these serial
numbers are now based on UTC time encoded as the number of seconds
since the UNIX epoch (00:00:00 GMT, 1 January 1970).

VNDS will continue to publish .com/.net zone files twice per day as
part of the TLD Zone File Access Program. [2]  These zone files will
continue to reflect the state of the .com/.net registry database at
the moment zone generation begins.

VNDS does not anticipate any negative consequences of deployment of
rapid updates to the .com/.net zones.  However, as a courtesy we are
providing the Internet community with 60 days advance notice of the
change to the update process.

Some questions and answers about rapid updates for .com/.net are
available at http://www.verisign.com/nds/naming/rapid_update/faq.html.

Matt
--
Matt Larson <[EMAIL PROTECTED]>
VeriSign Naming and Directory Services


[1] http://www.merit.edu/mail.archives/nanog/2004-01/msg00115.html

[2] http://www.verisign.com/nds/naming/tld/

Re: VeriSign's rapid DNS updates in .com/.net

[Matt Larson]

On Fri, 09 Jul 2004, Robert Boyle wrote:
> Does this also apply to domains with other registrars?

I'm not sure what you mean by "other registrars".  VeriSign sold the
Network Solutions registrar in November 2003 (although it retains a
15% ownership).

The rapid updates apply to all changes from all registrars.

> Does this apply to authoritative name server changes as well?

Do you mean, does it apply to glue records (i.e., A records for name
servers) in the .com/.net zones?  Yes, it does: a change to a name
server's IP address will be reflected just as fast as a change to a
domain's (er, zone's) NS records.

> Also, does this apply to customers who have had their domains
> suspended due to non-payment?

I'm not sure what you mean here, but I think you're referring to
something that's ultimately a registrar issue.  A domain can be placed
on hold status in the registry and its NS records will not appear in
the .com/.net zones.  There are several different hold statuses and
they all prevent a domain's NS records from being published.  It's
possible a registrar could put a domain on hold for non-payment.  Any
changes to its name servers while it's on hold would be propagated
quickly under this new system, as would changes to its hold status, so
if it it was removed from hold, whatever changes that occurred while
it was on hold would be visible quickly.


One other issue: a few people have sent me private email asking if
we're planning on changing the 48-hour TTL for NS records and A
records in .com/.net.  At this point we're not and the reason has a
lot to do with a little-known DNS behavior called credibility.  It's
described in RFC 2181 ("Clarifications to the DNS Specification"),
Section 5.4.1, although the concept pre-dates that RFC and has been in
the BIND iterative resolver, for example, since version 4.9 (if memory
serves).

In a nutshell, DNS data has different levels of credibility or
trustworthiness depending on where it's learned from.  That's relevant
here because the version of a zone's NS records from the zone's
authoritative servers is more trustworthy than the version obtained
from the zone's parent name servers.  For example, the foo.com NS
records received from a foo.com authoritative server are believed over
the foo.com NS records received from a .com name server.  Most
"positive" responses include the zone's NS records along with the
specific data requested (such as an A record).  So in practice, here's
what happens:

- An iterative resolver chasing down, for example, A records for
  www.foo.com queries a .com name server and caches the foo.com NS
  records (with a 48-hour TTL) it receives.

- The resolver then queries one of the foo.com name servers for the
  www.foo.com A records.

- In the response the resolver receives the www.foo.com A records,
  along with foo.com's own version of the foo.com NS records--and this
  is the important part--which have the TTL set by the foo.com zone
  owner.

- According to the credibility scale, the just-received foo.com NS
  records are more credible than the cached foo.com NS records from
  .com, so the just-received records displace the cached ones, new TTL
  and all.

In other words, for all the iterative resolvers out there that have
this credibility mechanism, the 48-hour TTL on data in .com/.net isn't
particularly relevant.

Matt

Re: VeriSign's rapid DNS updates in .com/.net

[Eric Brunner-Williams]

> Verisign doesn't get a refund from ICANN ...

Deepak,

First, the fee to ICANN is on the order of $0.20/per, as opposed to the
fee we registrars pay to VGRS, which is on the order of $6.00. Second,
the fees paid by both the registries and registrars is subject to some
negociations, which is presently happening with much more energy and
vigor than usual, since ICANN wants to really grow its budget this year,
at the expense of the ... registrars and registries.

Eric

Oh, I just submitted a xfr on a hijacked domain ... sigh.

Re: VeriSign's rapid DNS updates in .com/.net

[Deepak Jain]

The window to be notified and respond probably just shrunk by an
enormous factor. Everything is hijackable.

I wasn't aware you got a notification upon hijack...

You may... you may not. If you don't its definitely a hijack. If you did 
and you were able to prevent it, its not a hijack. It really depends on 
the registrar I think.

As far as cancelling domains purchased with jacked credit cards... 
Verisign doesn't get a refund from ICANN or whoever if the domain is 
cancelled after the first two weeks or something... so why should 
Verisign cancel the domain when it helps their total-domains-registered 
rankings and THEY had to pay for it.

DJ

Re: VeriSign's rapid DNS updates in .com/.net

[Valdis . Kletnieks]

On Fri, 09 Jul 2004 20:37:18 -, "Christopher L. Morrow" said:
> all still dependent on the 'its hijackable' to begin with, right? So what
> changed really?

"Hmm... that phone call 2 hours ago sounded fishy.. I better re-double-check"

Working scam for 1 hour 50 minutes with 5 minute updates, good chance
of being stopped before deployment with 12 hour updates.

Yes, on the flip side, the hijacking is *stopped* sooner - but for many
classes of attacks that involve control of a nameserver, a few minutes
can be enough


pgpBPCUyE3DmQ.pgp
Description: PGP signature

Re: VeriSign's rapid DNS updates in .com/.net

[Christopher L. Morrow]

On Fri, 9 Jul 2004, Deepak Jain wrote:

> >
> > all still dependent on the 'its hijackable' to begin with, right? So what
> > changed really?
> >
>
> The window to be notified and respond probably just shrunk by an
> enormous factor. Everything is hijackable.

I wasn't aware you got a notification upon hijack...

Re: VeriSign's rapid DNS updates in .com/.net

[Deepak Jain]

all still dependent on the 'its hijackable' to begin with, right? So what
changed really?
The window to be notified and respond probably just shrunk by an 
enormous factor. Everything is hijackable.

DJ

Re: VeriSign's rapid DNS updates in .com/.net

[Christopher L. Morrow]

On Fri, 9 Jul 2004 [EMAIL PROTECTED] wrote:

> On Fri, 09 Jul 2004 16:00:30 EDT, Deepak Jain said:
>
> > And you can fix hijacked domains in seconds!!
>
> 
>
> Or social-engineer somebody to "fix" a "hijacked" domain in seconds.. :)
>
> 
>

all still dependent on the 'its hijackable' to begin with, right? So what
changed really?

Re: VeriSign's rapid DNS updates in .com/.net

[Valdis . Kletnieks]

On Fri, 09 Jul 2004 16:00:30 EDT, Deepak Jain said:

> And you can fix hijacked domains in seconds!!



Or social-engineer somebody to "fix" a "hijacked" domain in seconds.. :)




pgpfKYj8Ab6Wu.pgp
Description: PGP signature

Re: VeriSign's rapid DNS updates in .com/.net

[Deepak Jain]

Very cool! Kudos! This is good news from Verisign on NANOG for a change. 
:) Does this also apply to domains with other registrars? From your 
message wording above, it appears that is the case which is great news. 
Does this apply to authoritative name server changes as well? Also, does 
this apply to customers who have had their domains suspended due to 
non-payment? That is always tough for our support desk to tell a 
customer they need to pay their bill to registrar X then wait 24-48 
hours. If this will end that mess too, that's even better.

Seconded. This is very cool and something I think everyone has wanted 
for a long time.

[Devil's Advocate Hat On]
So domain hijacking can now take place in seconds in the middle of the 
night?

[Devil's Advocate Hat Off]
And you can fix hijacked domains in seconds!!
DJ

Re: VeriSign's rapid DNS updates in .com/.net

[Robert Boyle]

At 03:20 PM 7/9/2004, you wrote:
time.  After the rapid DNS update is implemented, the elapsed time
from registrars' add or change operations to the visibility of those
adds or changes in all 13 .com/.net authoritative name servers is
expected to average less than five minutes.
Very cool! Kudos! This is good news from Verisign on NANOG for a change. :) 
Does this also apply to domains with other registrars? From your message 
wording above, it appears that is the case which is great news. Does this 
apply to authoritative name server changes as well? Also, does this apply 
to customers who have had their domains suspended due to non-payment? That 
is always tough for our support desk to tell a customer they need to pay 
their bill to registrar X then wait 24-48 hours. If this will end that mess 
too, that's even better.

-Robert
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Good will, like a good name, is got by many actions, and lost by one." - 
Francis Jeffrey