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?


















Reply via email to