Re: that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net ) (longish)
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
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: VeriSign's rapid DNS updates in .com/.net
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
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
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
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
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
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 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
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
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
... 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
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
that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net )
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
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
Re: that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net ) (longish)
-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: that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net ) (longish)
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: VeriSign's rapid DNS updates in .com/.net
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: VeriSign's rapid DNS updates in .com/.net
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
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
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
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
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
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
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
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
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 (fwd from ml)
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
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)
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 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
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
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
- 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
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
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
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
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
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
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
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
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
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
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, http://nms.lcs.mit.edu/papers/dns-imw2001.html. 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
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
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
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
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
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 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
Re: VeriSign's rapid DNS updates in .com/.net
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 slide correctly), NANOG covers more than just routing in North
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 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 not seem to contain any
RE: VeriSign's rapid DNS updates in .com/.net
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
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
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
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 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
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
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
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
Re: VeriSign's rapid DNS updates in .com/.net
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
On Fri, 09 Jul 2004 16:00:30 EDT, Deepak Jain said: And you can fix hijacked domains in seconds!! Devil's Advocate Hat On Or social-engineer somebody to fix a hijacked domain in seconds.. :) Hat Off pgpfKYj8Ab6Wu.pgp Description: PGP signature
Re: VeriSign's rapid DNS updates in .com/.net
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!! Devil's Advocate Hat On Or social-engineer somebody to fix a hijacked domain in seconds.. :) Hat Off all still dependent on the 'its hijackable' to begin with, right? So what changed really?
Re: VeriSign's rapid DNS updates in .com/.net
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
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
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
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
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
