Great advice Michael. We already do that.
Again, my question is specifically *when* did NSI begin enforcing a lame
delegation policy? On another mailing list NSI is now saying that they
will apply this policy if someone listed a provider nameservers without
their permission, however myself and others on our staff have been told on
more than one occasion by NSI that there was nothing they could do in
these instances.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
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
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Again, my question is specifically *when* did NSI begin enforcing a lame
delegation policy?
day zero. they dropped when it did not scale.
randy
nothing? They can turn off the domain if it was registered with incorrect
information, or if they find that it was registered with nameservers the
registrant is not allowed to use.
I've heard, and this is only something I've heard and I can't substantiate it,
that *officially* speaking, the only reason they turn off domains is for
non-payment....
> 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.
Guess I should have said "run at least two sets of nameservers, i.e. two
primaries and two secondaries. One set for recent additions... etc.".
If you ARE running at least one secondary, it can pick up the slack while
the primary is relaoding.
Actually, I prefer an architecture in which the publicly accessible
nameservers are all secondaries from a private primary nameserver. In
other words, using BIND 4 terminology, the two nameservers registered with
the Internic have only "secondary" records in their named.boot files and
the nameserver with "primary" records is not used for anything except
feeding these "secondary" nameservers. In BIND 8 this terminology changed
to "master" and "slave", probably to avoid confusion with the fact that
people tend to call the first nameserver in the list registered with the
Internic, the "primary" nameserver but this does not mean that it has to
be "primary" or "master" in the named config file.
I'm not convinced they have. I have a customer who's registered >1500
domains in the past year (he even paid NSI for them all), but has not had
us setup DNS for the vast majority of them yet. A quick check of a few of
them turned up none for which NSI has removed the lame DNS server entries.
----don't waste your cpu, crack rc5...www.distributed.net team enzo---
Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or
Network Administrator | nestea'd...whatever it takes
Florida Digital Turnpike | to get the job done.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key________
I am of the opinion that you should have one or two nameservers on site and
work out something with another ISP in another physical location, hanging
off a different backbone, to also use their nameservers. (A lot of people
will do secondaries at no charge, especially if you work out a reciprocal
agreement with them).
The greater issue is that there is any implementation at all, when there
was none previously.
your assertion is widely known to be false.
Thank you for your extremely helpful answer. Once again, since when has
NSI been enforcing such a policy?
isi enforced it. sri enforced it. nsi enforced it when they took over from
sri. that they did not test for correct practice for a while does not make
incorrect practice valid.
welcome to the network slobs' mailing list. where we winge and make excuses
for half-assed practices, and excoriate and hurl innuendo at those who try
to ensure correct practice.
randy
>>> The greater issue is that there is any implementation at all, when there
>>> was none previously.
>> your assertion is widely known to be false.
> Thank you for your extremely helpful answer. Once again, since when has
> NSI been enforcing such a policy?
isi enforced it. sri enforced it. nsi enforced it when they took over from
sri. that they did not test for correct practice for a while does not make
incorrect practice valid.
Who said anything about incorrect practices? My question was when did NSI
begin enforcing the policy. I am not upset at the lame delagation policy
at all. I am all for it.
welcome to the network slobs' mailing list. where we winge and make excuses
for half-assed practices, and excoriate and hurl innuendo at those who try
to ensure correct practice.
Indeed. When are you going to stop?
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
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
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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...
the line of people who have asked for this would stretch out the door and
into the street. bind runs from memory rather than from disk, because it
has to be able to answer at wire speed for large values of "wire". we're
working on a hierarchical storage system, basically a memory cache with
LRU, backed by a database. we're also working on a way to load from sql
databases into memory rather than always having to load from disk. it's
likely that the second of those two projects will be complete a year or
so before the first :-).
in 8.1.2++, though, the goal is to be able to check and/or reload a zone
without having to stat() all the others. for someone with 50K zones on
board, this should be a huge speedup.
Paul Vixie wrote:
> 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...
the line of people who have asked for this would stretch out the door and
into the street. bind runs from memory rather than from disk, because it
has to be able to answer at wire speed for large values of "wire". we're
working on a hierarchical storage system, basically a memory cache with
LRU, backed by a database. we're also working on a way to load from sql
databases into memory rather than always having to load from disk. it's
likely that the second of those two projects will be complete a year or
so before the first :-).
How about simply using libdb.a from SleepyCat Software? It does all
cacheing and can be used with threads. And it also makes dynamic
updates
a breeze.
SQL (or any other kind of relational database for that matter) is
clearly
an overkill.
--vadim
Have you looked at SQL_Bind? I don't know how well that package scales,
but it does work pretty well...
http://www.seawood.org/msql_bind/
Seems that NSI has a new policy on lame delagations. I never heard
anything about this. Anyone else?
FWIW, Msen has been blasting the NIC with phone calls and faxes
as we find lame delegations. In several instances, these are domains
that registered to use us without our permission and in some of them,
its a spamming domain.
I would prefer a guardian object on our nameservers preventing their
unauthorized use and also the ability to remove those objects from
records WITHOUT being a contact for the domain.
But I'm dreaming...
FWIW, Msen has been blasting the NIC with phone calls and faxes
as we find lame delegations. In several instances, these are domains
that registered to use us without our permission and in some of them,
its a spamming domain.
i figure it just adds to the nic's overload. so, when i find a domain
which has been lamely delegated to one of my servers, i just put in an
authoritative zone for it with a short ttl soa and a wildcard mx
* MX 0 some.schmuck.lame.delegated.to.the.host.name.
or the analogous PTR for in-addr zones.
it immediately stops any overload on my server and usually gets fixed
fairly quickly, no muss no fuss.
randy
I might also add that MHSC was using PostgreSQL for a while, until we
started doing some performance/capacity testing. We are looking at Oracle
now. The performance might be there, but the documentation as to how to
tune-in that performance, isn't. Generally, most networking RDBMS's have
trouble performing at the levels required by 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...
the line of people who have asked for this would stretch out the door and
into the street. bind runs from memory rather than from disk, because it
has to be able to answer at wire speed for large values of "wire".
Ok; I'm there... but it seems to me that disk caching, possibly
application tuned, and 3/4 of a shitload of ram should solve that
problem. If you really need to serve that much DNS, you can _afford_ a
4GB Ram Alphaserver, no?
we're
working on a hierarchical storage system, basically a memory cache with
LRU, backed by a database. we're also working on a way to load from sql
databases into memory rather than always having to load from disk. it's
likely that the second of those two projects will be complete a year or
so before the first :-).
Ah, got it.
in 8.1.2++, though, the goal is to be able to check and/or reload a zone
without having to stat() all the others. for someone with 50K zones on
board, this should be a huge speedup.
Quite so.
Cheers,
-- jra