gimpydog

A whole bunch of new certificates arrived today for various renewals & new reg in Jun/Jul.
Unfortunately they all had a registration date of 2 February 2006, regardless of when the domain was regged.

Anybody else having this problem.
Is it part of the new lo-cost Nominet service? ;p)

tmsdomreg

Yes, we have had a number in today with the same error. Thanks for pointing it out - I hadn't spotted it.

Peter

sneezycheese

...Yep me too - all dated 2nd February 2006.

WHOIS details are thankfully correct though - Lets hope they stay that way!

Regards,

Sneezy.

Jac

Has anybody informed Nominet about this mistake? They cannae do nowt about seeing it doesn't happen again if they don't know chaps.

Regards
James Conaghan

gimpydog

I thought they were members of this forum & would read this section?

</naive>

rob

They used to be - but then some forum members carried on a crusade to prove black was white so Nom got fed up and buggered off.

By the style of some of the posts here I have a feeling quite a few people think that Nominet = Acorndomains, which unless Admin is moonlighting is total tosh.

The best bet is to email or ring Nominet - info on Contact Us

Jac

There are some Nominet employees who may monitor Acorn to keep up with the issues expressed here but there is no official presence per se.

What I meant to suggest was that it might create a more immediate response to your questions if you addressed them to od@nominet.org.uk (Operations Director's office). I'm sure Nominet would want to correct any mistakes like this as soon as possible.

Regards
James Conaghan

Jay Daley

To be clear, I do read AD regularly (as do some others at Nominet) and post regularly. Though I have noticed that even with 200+ posts I'm still not a senior! Anyway, anything I post here is of course 'official', it couldn't really be anything else.

We do know about the letters issue, thanks. This is a problem with our printers that we are discussing with them.

Forgot to say - You are quite right though, if you think we need to know something urgently then please let us know direct, rather than on here.

__________________
Jay Daley
Nominet UK

grandin

Hi Jay,

In your official capacity can you tell me the reason why domain names became renewable?

Lee

__________________
Buy To Let Mortgages Buy To Let mortgages Discount Mortgages landlord insurance
van insurance student loan Commercial Mortgages Fixed Mortgages UK Hotels UK Holidays

Jay Daley

(Apologies in advance - this is a long post)

Of course. In order to answer this I need to go into the mechanisms by which domains are managed and how DNS works. I don't want to assume any particular level of knowledge you might have of these and thereby cause offence so I'm going to err on the side of caution and explain it from the basics, hopefully avoiding being patronising in the process. I will also try to avoid technical jargon, so this might not seem 100% to a technically proficient reader, but it should make it more understandable.

I'm going to split the logic down into two steps
- why we need to charge for service for a domain on an ongoing basis
- why we need to allow domains that are not regularly paid for to be offered to someone else who is willing to pay.

Every operator of a domain name (by 'operator' I mean the entity that decides that changes are made to the zone file, whether or not they actually do it themselves or even understand the technical way it is done) needs two things from the operator of the parent domain. These are

1. They need the parent to run a publicly accessible zone that lists their domain in it and points to the nameservers of the child. The users of the child domains will have to contact the parent's nameservers in order to access the child.
2. They need the parent to accept and action changes to the nameserver entries for the child

So, an example to make this clear. To run 'jayhelpfulexplanations.mytld' I need the operator of 'mytld' to do the things above.

At first sight this might seem simple but real world experience shows that there are some complications that need to be considered. These are:

- The parent needs to run their service sufficiently resiliently to ensure that the child is not inconvenienced by a failure of the parent. This means not doing something wrong themselves and not allowing someone else to interfere by attacking the nameservers.
- They need to ensure that when a request is made to change the nameservers (for the child that the parent points to) then only those requests that genuinely come from the operator of the child are accepted. And of course that no genuine requests are accidentally rejected.
- The number of child domains that any parent needs to deal with varies tremendously, from a couple of hundred in the case of the root, through to 50+ million in the case .com

Now, when the number of domains that a parent has to deal with reaches a certain number, then this leads to some rather inevitable decisions on the nature of the service the parent supplies:

- The parent builds an infrastructure that
-- minimises the potential for downtime for the parent zone by multiple layers of error checking and strong defensive measures
-- allows the operators of the children to get changes made to their domains quickly
- The parent builds systems that
-- allow the authentication of the operators of the children
-- allow the operators of the children to re-establish authentication when things change.

Both of these things cost money and that is how the principle of an ongoing charge is established.

That leaves the second point of why we need to release domains where the ongoing charge is not paid to allow someone else to become the operator and pick up the charges. In order to do this, lets analyse what happens if we did not release these domain and yet the operator chooses not to pay.

- the parent would obviously stop service for the child in their zone file
- the parent would need to maintain their record of how to authenticated the operator of the child in case they decided they did want to use it (after paying the charge) and so that they could reject any false attempts to change it.

This last bit costs money but the operator is not paying for it! You might think it a small sum, but it is not nothing. So the operator of the parent makes the very reasonable decision, which is that if the operator of the child does not pay then the domain will be offered to someone else to use. This is what we call renewal - the parent says "if you want to keep using this and don't want me to offer it to someone else then please pay".

Just one final point. If you recall I said this train of reasoning was usually as a result of the number of the domains that a parent needs to provide service for reaching a certain level. Where the number is small then people are often willing to do this on goodwill, not a charge. It is also the case that 1. and 2. above can quite happily be done by different entities.

I do hope that helps you understand the thought processes here. If there is any part that seems unclear then let me know.

__________________
Jay Daley
Nominet UK