Discuss mailing list

[Alejandro Bonet <albogoal AT gmail.com>]

This is good Jeff: "the people who i want to provide the resources to
help maintain their interest".

But i know a guy who translated the whole wiki into spanish, and with
no reasons, this translation is not online eight months after it was
done...

I dont know if this is your project, our project, or the project for
ten "privileged" tlds owners...

But if it is my project i want to see it growing (with more servers,
more tlds, more people and more ideas)...

Quinn: At year 1500, the only one who says "Earth is not the center:
SUN is the center", was Nicolas Copernico.

Nobody understood him then... But he was RIGHT.

Evidently im not Copernico.

But this could be a good example to show us that "The more number of
believers is not necesarily a good measure for the truth, or a good
reason to believe".



2014-07-26 4:28 GMT+02:00, Jeff Taylor <shdwdrgn AT sourpuss.net>:
> Note that in addition to redundancy, you also want to consider
> geographic location.  We have a few T1s in the US, a few in Europe, a
> few in AU... This allows some flexibility for the T2 operators to
> control where their queries fall back to, and help maintain decent
> response times.  If we had 10 T1s all sitting in Germany, then yes I
> would agree this would be overkill and provide nothing to OpenNic. The
> same holds true with T2 servers, and in the past I have spoken to people
> about how pointless it is to run 10 servers out of the same hosting
> facility.  Redundancy is only as good as the diversity it is based on,
> so as long as we keep servers spread out to a wider geographic area,
> having a large number of both T1 and T2 servers is still useful.
>
> And no, the end comments were not directed at you.  I've talked to many
> people on IRC over the years who have come in expecting to
> point-and-click their way to a shiny new TLD, only to leave the channel
> angry when they find out it actually takes 'work' to set up and
> maintain.  This is an ongoing problem, and always has been, so there
> have been rules added over the years to try and prevent people with only
> a passing interest and limited knowledge from being put in a position
> that they can't handle.  Consider if we just let anyone create a TLD on
> the fly...  When the .pirate zone originally opened up, there were
> thousands of domains created by people who never even came back to see
> if they worked (and this is exactly the reason why I enacted the initial
> 28-day registration period on all of the domains I help manage).  It's
> great that people want to come through and play with the toys we have
> created, but we should NOT cater to the requests of people who lose
> interest after 5 minutes of playing around.  If someone is interested
> enough to come back and start asking questions, those are the people who
> I want to help, the people who I want to provide the resources to help
> maintain their interest with the project and make it a fun thing to get
> involved with.  We can set rules to protect the project as a whole
> without making things so difficult that newcomers are driven away.
>
>
> On 07/25/2014 04:37 AM, Alejandro Bonet wrote:
>> Dear Jeff Taylor:
>>
>> This is the key question, we (you and me) will never agree: Your
>> personal point of view and my personal point of view are different in
>> this question.
>>
>> You say: "It is better to distinguish between T1 and T2, because T1
>> are redundant and authoritative, and T2 are not".
>>
>> And i say: "Well, you can 'categorize' the servers as you want, but
>> they are only servers. If you want redundance to get reliability, you
>> dont need 10 T1s redundance for each TLD. You only need two or three
>> servers for each TLD, and you will get almost the same redundance as
>> with ten servers (because when the two or three servers hang
>> simultaneously, then probably the problem is global, and it can hang
>> ten or twenty servers also). And, in respect to authoritative
>> responses, if you have ten authoritative servers for a TLD, the
>> probability of inconsistence in responses, is 5 (or 3.3) times greater
>> than if you only have two or three authoritative servers for that TLD.
>> Also if you need to replicate each complete TLD zone file in each T1
>> server, and requiring a T1 (as authoritative and redundant) server for
>> each TLD, this will run well with ten TLDs, but not with 5000 TLDs."
>>
>> This discussion will never ends: You have your opinion, and i have mine.
>>
>> Both have advantages and disadvantages, at different scales.
>>
>> The main diference is only "in style".
>>
>> (About the "argument of authority" in the sense that "there are people
>> just going walk in and create a new TLD without any knowledge of how
>> BIND works, and sometimes without any understanding of how DNS works",
>> i dont know if you are saying this for me, but i only want to say you
>> i wrote a DNS client for arduino some years ago, and it is running
>> perfectly since that, on many installations, 24h/365d).
>>
>>  From scratch. Building and parsing complete DNS-QUERY/RESPONSE UDP
>> packets, field by field, bit by bit, on 16 bit tedious microprocessor
>> assembler language, with redudant compression of domains, of course.
>>
>> Alejandro Bonet
>> albogoal AT gmail.com
>>
>> http://registro.ibu
>>
>> ns1.ibu: 87.216.170.85
>> ns2.ibu: 185.16.40.143
>>
>> Since August 2013
>>
>>
>> 2014-07-14 17:48 GMT+02:00, Jeff Taylor <shdwdrgn AT sourpuss.net>:
>>> If we were trying to maintain our own copy of the .com zone, size would
>>> be an issue.  That file is over 9GB, and it would present a significant
>>> bandwidth problem to many users.  The .bit zone that is being discussed
>>> is only 1MB... its so small it fits on a floppy disk.  I still don't
>>> understand why you think it is a problem to transfer this small of file
>>> to the T1 and T2 servers?
>>>
>>>> "Hey men, there is no reason to mantain copy of all the tld zones in
>>>>> each T1 server: We only need to mantain pointers to the authoritative
>>>>> servers for each tld, and recurse them..."
>>> Well yes, there IS a reason to maintain a copy of the TLD zone files on
>>> every T1 server.  That is exactly the point of the T1 servers -- to be
>>> authoritative for all of our TLDs.  If you take that away, then a T1 is
>>> no different from a T2.  Many years ago OpenNic was run with the policy
>>> that only the master for a TLD would answer.  There were no backup
>>> copies maintained on other T1 servers.  Guess what happened every time
>>> one of the master servers went offline?  All resolution for every domain
>>> registered under that server's TLD became unavailable.  What you are
>>> proposing is that we move backwards and give up redundancy and
>>> reliability.  Why would anybody want that?
>>>
>>>> Resolvers are trivial to set up compared to a tier 1 server. People
>>>> who decide to create a TLD need to be competent at running it by
>>>> themselves, and this is why we request them to have a tier 1 server to
>>>> prove as such. This hasn't been a barrier of entry to anyone so far I
>>>> don't think.
>>> Actually it HAS been a barrier, and it is supposed to be a barrier. As
>>> you say, there needs to be a certain amount of competency with running
>>> DNS and maintaining a server in general before someone should be allowed
>>> to operate a TLD.  We've had our share of problems in the past, and new
>>> rules are created in response to those problems.  I see a lot of emails
>>> come across the mailing list where people think they're just going to
>>> walk in and create a new TLD without any knowledge of how BIND works,
>>> and sometimes without any understanding of how DNS works.  OpenNic is a
>>> project about learning, and many of us are more than happy to help
>>> people learn how to set up new TLDs on their own personal network, but
>>> the public DNS space is not the place to be experimenting and trying
>>> figure it out as you go... when we offer a public TLD for domain
>>> registration, people expect it to work.
>>>
>>>
>>>
>>>
>>> --------
>>> You are a member of the OpenNIC Discuss list.
>>> You may unsubscribe by emailing
>>> discuss-unsubscribe AT lists.opennicproject.org
>
>