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; discuss-list@opensrs.org
> 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; discuss-list@opensrs.org
>> 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; discuss-list@opensrs.org
>>> 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:bdorland@tucows.com]
>>>>Sent: 02 February 2004 22:20
>>>>To: Rob; discuss-list@opensrs.org
>>>>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
>>>>hostmaster@mdnsservice.com 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: owner-discuss-list@opensrs.org
>>>>[mailto:owner-discuss-list@opensrs.org]On Behalf Of Rob
>>>>Sent: Sunday, February 01, 2004 3:10 PM
>>>>To: discuss-list@opensrs.org
>>>>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: owner-discuss-list@opensrs.org
>>>>[mailto:owner-discuss-list@opensrs.org] On Behalf Of Jim McAtee
>>>>Sent: 01 February 2004 18:38
>>>>To: discuss-list@opensrs.org
>>>>Subject: Re: Managed DNS Service concerns
>>>>
>>>>
>>>>----- Original Message -----
>>>>From: "Rob" <rob@natweb.net>
>>>>To: <discuss-list@opensrs.org>
>>>>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?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:37:54 EDT