My intention was not to call you ignorant and I apologies that you took it that way.
I was using your responses to demonstrate that OpenSRS do not appreciate what some fundamental real world requirements are. Understanding technically DNS (expert or not) is not sufficient, an understanding of how DNS is used is equally important. You stated "it is just one of the *reasonable* ways that *most* of the users would accept as they mostly care about not loosing their mail than not being able to retrieve mail within next 5 minutes." Advocating a loss of service for longer than is necessary is simply unacceptable in this line of business and this simply reinforces my challenge that OpenSRS are so wide off the mark in understanding a Service Provider or ISP's requirements in this instance that it is frankly scary. Regards Rob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yura Pismerov Sent: 03 February 2004 18:03 To: [EMAIL PROTECTED] Subject: Re: Managed DNS Service concerns Rob wrote: > I do not agree - the only reason that the capability for editing the > TTLs is not present is due to a conscious decision by OpenSRS either > to not implement this capability or that it should not be edited - I > think it is fairly clear from the comments a number of people have > made on this list that this was a bad decision and does indicate a > lack of understanding on how DNS is being used in the real world. > > If the ability to add editing the domain contact can be implemented so > quickly why cannot editing the other TTL values be implemented at the > same time ? > I cannot see why this should require any significant technical effort > from OpenSRS to achieve. > > Your previous comments regarding email and the fact that you seem to > think that TTL issues are in someway related to wanting a Dynamic DNS > service demonstrates a complete and fundamental misunderstanding of > what is being asked for and of DNS itself. Ok, I never call call myself an expert in any area and I honestly don't like people who do that. But I am not an ignorant person either and I do know what Dynamic DNS is and in which cases it might be useful. All I wanted to say is that everything is doable, but it is going to be another level of service (and obviously another price). Dynamic DNS is just an example of *another* service, I am sorry that you took it too literally. You can't create a super-product that would satisfy anybody's needs and would be reasonable priced at the same time. I hope I did not say anything new. Once again, the limit for the TTL value is just a limitation of the current state of the product that we offer. It does not mean it is frozen and will not change. I did not mean to say that what we do is the only way of doing things - it is just one of the *reasonable* ways that *most* of the users would accept as they mostly care about not loosing their mail than not being able to retrieve mail within next 5 minutes. You are trying to prove that I am wrong - this is perfectly normal situation. But please do not call me ignorant. > > Regards > Rob > > ------------------------------------------------------------------------ > From: Yura Pismerov > Sent: Tue 03/02/2004 17:07 > To: Rob > Cc: Bruce Dorland; [EMAIL PROTECTED] > Subject: Re: Managed DNS Service concerns > >Rob wrote: > >> I do disagree about email, end users will not be able to get to their >> mail sever until DNS resolves the new IP. >> >> This is beginning to look worryingly like OpenSRS not actually >> understanding how DNS is used in the real world. > > > Rob, let's put it simple way. I hope you agree that no matter how >good the service is there are always certain limitations of the product >that one may not be satisfied with. Let's just be realistic. There might >be a day when you will be able to do everything you want to with the DNS >service offered by Tucows. We are just not there yet. After all, if you >really want to operate with lower TTL values, you might consider Dynamic >DNS (but again, we do not offer it yet). > As for your statement about us not understanding how DNS works, I >hope you did not mean it. >I don't think OpenSRS/Tucows deserved reputation of offering services >that they have no clue about. > > > >> >> ------------------------------------------------------------------------ >> From: Yura Pismerov >> Sent: Tue 03/02/2004 15:20 >> To: Rob >> Cc: Bruce Dorland; [EMAIL PROTECTED] >> Subject: Re: Managed DNS Service concerns >> >>Rob wrote: >> >>> SOA REFRESH >>> Agreed >>> >>> SOA EXPIRE >>> This also applies to servers that have the data in cache, ie ISP's DNS >>> servers that their customers talk too. >>> Having expire set too low will both increase the load on all the DNS >>> servers in the chain and will also make transient of brief outages >>> more visible. >>> >> >> Right, but I don't think it is the case since the SOA EXPIRE set to >>a far larger value than TTL in our case. >>But your comment is still valid. We should consider coordination of SOA >>EXPIRE if we decide do allow customers to edit the TTL. >>Having TTL value greater than EXPIRE does not make much sense. >> >>> SOA MINIMUM TTL >>> Similar issues to EXPIRE >>> >>> The TTL values for individual records should also be editable 5 >>> minutes is excessive if you are switching over mail servers etc as it >>> will cause a noticable outage whereas a much lower TTL during the >>> switch over will have far less visible impact >> >> Speaking of the mail service, you may disagree, but I don't see a >>problem here. We all know that the mail systems are designed to handle >>temporary DNS outages and to defer mail delivery by responding with a >>temporary failure codes (ie. 451 SMTP code). >>Temporary failure would cause the sending side to queue mail and re-try >>later. Of course it will cause some delivery delays, but in most cases >>the are not significant since most of the MTAs will re-try in a few >>minutes. Only after that the delay will increase to a few hours. >>At this point, 5 minute default TTL is still acceptable. You should >>also keep in mind that allowing customers to assign lower TTLs will >>imply potential load on our services in case everybody starts lowering >>it without good reasons (I am 100% sure this would happen). Obviously >>the only way we can control it is apply some limits on the TTL values. >>The current limit is set to 5 minutes. Yes I know that it is rather >>default, not a limit, but it does not mean it will stay like this >>forever - we may consider changing it at some point, but any change like >>this must be well justified. >> >>> >>> What has not been answered is why a decision was made not to provide >>> the ability to edit TTL values per domain, what is appropriate for one >>> customer/environment may not be appropriate for others and I cannot >>> see a valid technical for preventing customers managing this as they >>> see fit and believe that OpenSRS need to address this. >>> >>> Regards >>> Rob >>> >>> ------------------------------------------------------------------------ >>> From: Yura Pismerov >>> Sent: Tue 03/02/2004 12:35 >>> To: Rob >>> Cc: Bruce Dorland; [EMAIL PROTECTED] >>> Subject: Re: Managed DNS Service concerns >>> >>>Rob wrote: >>> >>>>Hi Bruce, >>>>Thanks for the response >>>> >>>>TTL >>>>I don't see why users should not be able to define what they feel are >>>>appropriate TTL values for their own zones, I don't think 5 minutes is a >>>>good default for all the settings >>>>SOA REFRESH RFC1912 2.2 recommends a value between 1200 to 43200 seconds >>>>(20 minutes to 12 hours). >>>>SOA EXPIRE RFC1912 recommends 2-4 weeks. >>>>SOA MINIMUM TTL RFC2308 suggests a value of 1-3 hours. >>>> >>>> >>>Hi Rob, >>> >>>"SO REFRESH" and "EXPIRE" values are irrelevant since we do not allow >>>any zone transfers off of our servers at this point. >>>Read Jim's McAtee comment on the topic - he explained it well. >>>In other words those values are useful if you host a secondary DNS >>>yourself and use our services as the source for zone updates. >>>As for the internal zone exchange, our servers don't use zone transfers >>>mechanism at all. >>>Regarding the TTL, Bruce mentioned in his message that we assign TTL an >>>a per record basis and we believe it is sufficient since the >>>record based TTL takes precedence in any case. >>>Let me know if you have further questions. >>> >>>>Global Distribution >>>>Can you tell us whether the next step is short, medium or long term ? >>>> >>>>Provisioning Client Code for Managed DNS: >>>>I did mean dns_manage.cgi when is dns_register.cgi due to be included in >>>>the client code ? >>>> >>>>Other Features Under Consideration: >>>>IMHO >>>>Mandatory Features are >>>>- Reverse DNS >>>> >>>>- Custom name server support >>>>- Complete record type support including srv >>>>- Online help >>>>- Refined web interface so that when an end user enters a fqdn without >>>>the terminating "." the "." is handled rather than returning a rather >>>>unhelpful error. (End users understanding A, MX, NS, CNAME and PTR >>>>records is one thing - understanding that a "." terminator is required >>>>is another). I can see this generating many support calls from end >>>>users. >>>> >>>>Major Selling Points are >>>>- Secondary DNS (I doubt this is a major selling point without global >>>>distributed name servers but it would then fit in very well with >>>>Resellers existing/alternative solutions) >>>>- Dynamic DNS >>>> >>>>- More automated tools for migrating zones (i.e., import bind-compatible >>>>zone, zone transfer) >>>>- Further customization to Domain For Sale and Domain Under Construction >>>>pages >>>>- Enhancements to the public managednsservice.com interface (e.g., >>>>search >>>>functionality) >>>> >>>>Regards >>>>Rob >>>> >>>>-----Original Message----- >>>>From: Bruce Dorland [mailto:[EMAIL PROTECTED] >>>>Sent: 02 February 2004 22:20 >>>>To: Rob; [EMAIL PROTECTED] >>>>Subject: FW: Managed DNS Service concerns >>>> >>>> >>>>Hey Rob, >>>> >>>>I've tried to summarize answers to your questions in this email - let me >>>>know if I've missed anything. In terms of the DNS service, I'd be >>>>interested to know what you think is missing, what enhancements you'd >>>>like to see, etc. Feel free to contact me directly if you prefer.... >>>> >>>>TTL: >>>>The TTL value for the Managed DNS Service is 300 seconds(5 minutes) and >>>>updates from the DNS application to the service's name servers actually >>>>occur in approximately 2 minutes or less. The TTL of 86400 is the zone >>>>default that is set, however this is over-written with a value of 300 in >>>>the record level TTL. It appears that the TTL is longer because when a >>>>SOA query is performed, only the zone defaults appear. Because the TTL >>>>is set at such a low value, we didn't believe there was significant >>>>value in making the SOA values editable. However, if you have an >>>>alternative viewpoint, I'm happy to listen. >>>> >>>>Contact in SOA >>>>The contact for the SOA record is not editable currently. However, >>>>we're making a change today to change the contact to >>>>[EMAIL PROTECTED] to further hide the Tucows name. This will >>>>be changed for all existing zones also. >>>> >>>>Name Servers for mdnsservice.com: >>>>We're looking into changing the name servers for mdnsservice.com so that >>>>they aren't on ns1/ns2/ns3.tucows.com. >>>> >>>>.DE: >>>>The SOA settings have already been modified and promoted to LIVE to >>>>comply with the .de requirements, so .de zones are now fully supported. >>>> >>>>Global Distribution of Name Servers: >>>>In terms of global distribution, you're right that our name servers are >>>>not globally distributed at this point. They are on separate backbones. >>>>Having globally distributed name servers is certainly a next step for >>>>the service, but at this point we haven't made any commitments as to >>>>when this will happen. We are in the process of finalizing our DNS SLA, >>>>so this should help increase your confidence level in our system. >>>> >>>>Provisioning Client Code for Managed DNS: >>>>We have yet to release the provisioning client code for Managed DNS, so >>>>I'm not sure how you're using the register_dns.cgi? At this point, >>>>provisioning is only available through the Reseller Web Interface and >>>>the API. There is client code for DNS Management however. >>>> >>>>Coming Soon for DNS (dates will be announced later) >>>>- A number of small enhancements to make the services more user friendly >>>>- Bulk Zone Change feature - We'll be introducing a Bulk Zone Change >>>>function in the Reseller Web Interface that will allow resellers to >>>>perform advanced bulk additions, modifications and deletions to zones in >>>>their profile. >>>>- Client code for provisioning DNS - Client code for provisioning DNS >>>>will be released >>>> >>>>Other Features Under Consideration: >>>>Would love to hear your feedback on these....feel free to contact me >>>>directly if you prefer. >>>>- Secondary DNS >>>>- More automated tools for migrating zones (i.e., import bind-compatible >>>>zone, zone transfer) >>>>- Further record type support (e.g., TXT records) >>>>- Further customization to Domain For Sale and Domain Under Construction >>>>pages >>>>- Online help >>>>- Enhancements to the public managednsservice.com interface (e.g., >>>>search >>>>functionality) >>>>- Dynamic DNS >>>>- Reverse DNS >>>>- Custom name server support >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: [EMAIL PROTECTED] >>>>[mailto:[EMAIL PROTECTED] Behalf Of Rob >>>>Sent: Sunday, February 01, 2004 3:10 PM >>>>To: [EMAIL PROTECTED] >>>>Subject: RE: Managed DNS Service concerns >>>> >>>> >>>>The TTLs are >>>>REFRESH value: 86400 >>>>RETRY value: 86400 >>>>EXPIRE value: 86400 >>>>TTL value: 86400 >>>>According to the documentation SOA values are not editable - I assume >>>>that includes the contact The service won't work with .de domains (they >>>>think they might have fixed this but don't know !) Wildcard subdomains >>>>are not supported From what I can tell only forward DNS is supported >>>> >>>>I don't have a real issue with not having support for wildcard >>>>sub-domains but do not see any valid reason why the other features >>>>should not be available. >>>> >>>>mdnsservice.com is meant to be the "white label" DNS service but its >>>>name servers are ns1 to ns3.tucows.com. >>>> >>>>-----Original Message----- >>>>From: [EMAIL PROTECTED] >>>>[mailto:[EMAIL PROTECTED] On Behalf Of Jim McAtee >>>>Sent: 01 February 2004 18:38 >>>>To: [EMAIL PROTECTED] >>>>Subject: Re: Managed DNS Service concerns >>>> >>>> >>>>----- Original Message ----- >>>>From: "Rob" <[EMAIL PROTECTED]> >>>>To: <[EMAIL PROTECTED]> >>>>Sent: Sunday, February 01, 2004 7:46 AM >>>>Subject: Managed DNS Service concerns >>>> >>>> >>>> >>>> >>>>>When the Managed DNS service was originally launched I was under the >>>>>impression that it would be >>>>> >>>>>a) A white label solution >>>>>b) Globally distributed >>>>>c) I assumed (reasonably I think) that the zone would be 100% editable >>>>> >>>>> >>>> >>>> >>>> >>>>>- but it is not (ttl's etc) >>>>> >>>>> >>>> >>>> >>>>My understanding was that ttl's were universally 5 minutes. I suppose >>>>to minimize caching/propogation problems and lessen the need for anyone >>>>to worry about dropping ttl's prior to making changes. It's probably >>>>the easiest way to deal with potential problems. >>>> >>>>What other data can't be managed? Can you change the contact email >>>>address in the SOA? >>>> >>>> >>>> >>>> >>>>>A simple nslookup clearly identifies Tucows as the provider >>>>> >>>>> >>>> >>>> >>>>In what sense - the domains in which the name servers reside? >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >
