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 Rob,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.
"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?
