Seems that NSI has a new policy on lame delagations. I never heard
anything about this. Anyone else?
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell (800) 299-1288 v
CTO (925) 377-1212 v
NameSecure (925) 377-1414 f
Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Patrick Greenwell wrote:
Seems that NSI has a new policy on lame delagations. I never heard
anything about this. Anyone else?
Interesting. Their policies state you must have the name servers for a
domain up and running before you apply for a domain, but they clearly do
not enforce that... Sounds like they're adding checking after the fact.
It still would be nice if they queried the name servers you told them
were to be used during the application process, though.
Dan
Seems that NSI has a new policy on lame delagations. I never heard
anything about this. Anyone else?
ancient policy, possibly new mechanism.
there should be no lame delegations.
rnady
Sorry, I should have been more specific. I knew the policy existed, but I
had never, until today heard of it being implemented in any way, shape, or
form. The last message from NSI I remember seeing stated something to the
effect that they never implemented it because there was not sufficient
community consensus on how to do so. I do not object to the implementation
of the policy in the slightest.
What worries me is that policies might just start being implemented "all
of a sudden" without notification to the community, which is why I was
asking if anyone else was aware of any previous implementation of this
policy or announcement of same.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell (800) 299-1288 v
CTO (925) 377-1212 v
NameSecure (925) 377-1414 f
Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
What worries me is that policies might just start being implemented "all
of a sudden" without notification to the community, which is why I was
asking if anyone else was aware of any previous implementation of this
policy or announcement of same.
the policy has not changed since when the nic moved to sri. mechanisms have
changed. follow the policy, and the mechanism for implementing it will not
be of concern.
randy
Randy,
While an interesting statement in philosophy, I fail to understand the
practical applicability of your advice in real world operations.
Mechanisms for implementation aren't really the issue IMO. The greater
issue is that there is any implementation at all, when there was none
previously.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell (800) 299-1288 v
CTO (925) 377-1212 v
NameSecure (925) 377-1414 f
Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
The greater issue is that there is any implementation at all, when there
was none previously.
your assertion is widely known to be false.
randy
FWIW, About 3 months ago I registered a domain with two nameservers, only
the primary wasn't listed in the whois database at the time. For about 2
days, the whois record only listed the secondary nameserver (but both NS
records were listed when looked up in the root servers).
-- _______________
Chris Josephes __/ MRNet \
chrisj@mr.net __/ http://www.mr.net/
\________________/
there should be no lame delegations.
Agreed. However, testing sometime after registration (as they seem to be
doing) is much more user friendly than testing before registration.
The reason I say this is that some folks automatically reload their
nameservers which have tens of thousands of domain names once a day and
have clients that want domains registered on the same day they request
them. (queuing is not an option.)
+------------------- H U R R I C A N E - E L E C T R I C -------------------+
there should be no lame delegations.
Agreed. However, testing sometime after registration (as they seem to be
doing) is much more user friendly than testing before registration.
depends to which user you are trying to be friendly. there is a clear
responsibility to the internet at large.
there should be no lame delegations.
The reason I say this is that some folks automatically reload their
nameservers which have tens of thousands of domain names once a day and
have clients that want domains registered on the same day they request
them. (queuing is not an option.)
if they intend to serve those clients, as opposed to pretending to do so,
then they should load thier servers when they are pretending to do so.
randy
if they intend to serve those clients, as opposed to pretending to do so,
then they should load thier servers when they are pretending to do so.
So you are recommending that if they take 300 new accounts in a day they
should reload their nameservers 300 times that day?
Remember these aren't nameservers that serve 5 domains, figure tens of
thousands. Perhaps I am not being clear. Reloads, even a HUP, cause
named, even the new version, to pause for a while before being able to
serve requests again. All the relevant nameservers for the domains would
have to be reloaded 300 times a day in this case. It isn't good if named
stops responding that often because it slows access to the web sites
domains by inserting a dropped DNS query timeout every time the reloading
server is queried (50% or 33% depending on 2 or 3 nameservers. If the
reload takes 30 seconds then reloading 300 times == each nameserver is
down for 150 minutes a day. Not good.
Just so the nameservers aren't lame for even a moment?
Doesn't being down 150 minutes a day make a nameserver atleast as bad as
being lame for a single domain?
Or do you suggest delaying client domain name registrations 24 hours?
Customers aren't being unreasonable when they want timely registration...
Anybody who has missed getting a specific domain name by a day can
appreciate this. I've seen it happen many times.
Explain to me the pretending part.
+------------------- H U R R I C A N E - E L E C T R I C -------------------+
Remember these aren't nameservers that serve 5 domains, figure tens of
thousands. Perhaps I am not being clear. Reloads, even a HUP, cause
named, even the new version, to pause for a while before being able to
serve requests again.
That will change in 8.1.2++, btw. "ndc" will use a socket, not signals.
All the relevant nameservers for the domains would
have to be reloaded 300 times a day in this case. It isn't good if named
stops responding that often because it slows access to the web sites
domains by inserting a dropped DNS query timeout every time the reloading
server is queried (50% or 33% depending on 2 or 3 nameservers. If the
reload takes 30 seconds then reloading 300 times == each nameserver is
down for 150 minutes a day. Not good.
Not bad, either. This is why we have slave servers.
Or do you suggest delaying client domain name registrations 24 hours?
I always put a zone up on the master before I send in the registration.
If the slaves take a day or so to catch up I can live with that.
if they intend to serve those clients, as opposed to pretending to do so,
then they should load thier servers when they are pretending to do so.So you are recommending that if they take 300 new accounts in a day they
should reload their nameservers 300 times that day?
then reload once a day, and be hoinest about it, both to the clients and to
the world (i.e. nic).
this is a no-brainer. people have been doing it for over a decade.
there should be no lame delegations.
rady
Ok, so here's the stupid question of the month (and I ask this with all
due regard for the time and effort Paul has put into BIND)...
Given (for example) PostGreSQL, is there any reason why someone hasn't
ported the algorithms of BIND on top of something like it? It seems to
me that it ought to be possible to keep a nameserver running whilst one
is doing maintenance on it...
(and PS: I realize that the answer to this may amount to Nameserver
101; if you think so, respond privately; I'll summarize to any one who
cares...)
Cheers,
-- jra
The practical applicability is that you should always set up nameservice
for a new domain and then send in the Internic application. With the
automated systems that most ISPs are using these days it should be no
problem to do this. There is no good technical reason to wait until a
domain registration is processed before setting up nameservice.
So you are recommending that if they take 300 new accounts in a day they
should reload their nameservers 300 times that day?
There is a technical solutions to this problem.
Fix BIND so that you can tell it to load a new domain without reloading
everything. I'm sure I have heard of people who have customized BIND in
this way. But an alternative to doing it yourself is to send ISC some
money and request an admin interface that you can telnet to and issue
commands like:
LOAD ALL (same as kill -HUP)
LOAD example.com,example.net,weenie.com,blazingxxx.com
STOP (same as kill)
...
Remember these aren't nameservers that serve 5 domains, figure tens of
thousands.
On the other hand, maybe there is another solution. Don't put all your
eggs in one basket. Run at least two nameservers. Add all new domains to a
nameserver that has a small enough number of zones that it can easily
handle being reloaded every hour. Then every week, transfer them all to
your HUMUNGO server.
Which is rather silly, since their clients should be made aware that the
providers HAVE TO go through a third party, and although NetSol has been
very good about getting new registrations done *very* promptly, there is
no guarantee that the registrations will be complete the same day (nor,
imho, should there be; if I was running the registry I wouldn't guarantee
that).
On the other hand, maybe there is another solution. Don't put all your
eggs in one basket. Run at least two nameservers.
This is a no-brainer.
1. If you're running only a primary and no secondaries, your DNS is an
accident waiting to happen.
2. You're required to have at least two nameservers operational for each
domain anyhow. This is true of the InterNIC, it's true of USC-ISI (the .US
TLD), and I'm sure it's true of the foreign registries too.
If you ARE running at least one secondary, it can pick up the slack while
the primary is relaoding.
Add all new domains to a
nameserver that has a small enough number of zones that it can easily
handle being reloaded every hour. Then every week, transfer them all to
your HUMUNGO server.
And I think this is an excellent idea.
I submit that this is a process issue. There is a manual process as well as
an automated one. The two of them have to coordinate. The problem is that
part of the process is non-deterministic and is thus very difficult to
automate. Until someone definitively solves the non-deterministic part
there will always be some uncertainty in the domain name
submission/approval process. This can be largely countered by proper
education, by the ISP, of the Domain Name requestor. Basically, lag times
need to be considered on both sides of the issue. The requestor can't
consider their domain, as theirs, until they get confirmation, from the
registrar. Conversely, the reqistrar can't require there to be existing
name servers until the requestor has recieved confirmation of the domain
name. I submit that it is incumbent on the requestor to inform the
registrar when such servers are ready, this is a process step that is not
included in the current process. At such time, the registrar can then
reasonably expect the new name servers to be running and perform the
process-step of fully activating the domain.
Randy,
Thank you for your extremely helpful answer. Once again, since when has
NSI been enforcing such a policy?
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell (800) 299-1288 v
CTO (925) 377-1212 v
NameSecure (925) 377-1414 f
Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/