This document obsoletes any older versions of all EFnet server applications.
Below are the agreed-upon guidelines for linking new servers to EFnet.
If after reading these guidelines you feel that EFnet should consider
linking your server, cut out the application at the bottom and respond
to each of the questions. To submit it, contact an administrator of a
current EFnet server to forward the application for you.
What the EFnet admin body is looking for when considering linking
a new server:
a) The IRC Server must be permitted and supported by the
administration of the machine and network that it is
sitting on. Uplink support is required prior to
applying for an EFnet link. The contact address for
an individual at the hosting entity must be given when
applying to verify IRC approval and uplink support.
b) The server administrators must be reasonably knowledgeable
about IRC and UNIX. They should be willing and able
to answer most user questions that they encounter
regarding IRC. Additionally, server administrators
should be familiar with general internet topology.
At the minimum, they should know how they normally
reach each of the major backbones.
c) The machine that the server is running on must be dedicated
hardware and adequate for the job.
The machine should be reasonably modern, and at least
1GB of total RAM is recommended.
It should be dedicated for security reasons. It is
never a good idea to run a public IRCd on the same
machine that has multiple users. Additionally, it
should be dedicated for performance reasons.
In general, the only services that should be running
on the IRCd machine are core kernel services, SSHd, and
clock synchronization such as ntpdate. Services such
as inetd, ftpd, telnetd, httpd and so on should not be
running on an EFnet IRC server.
For clock synchronization, ntpd or ntpdate or similar
must be run, the TS protocol requires that clocks be
kept accurate. If running ntpd, the service should be
restricted to the local system and ideally syncing to a
non-public NTP server.
The machine must be firewalled from outside logins and
protected against common spoofing attacks.
The network admins should be familiar with various
Denial of Service attacks and should know how to
minimize the effects of it.
The nameserver that the machine should be running must
use a secure current version. Information on the latest
version of BIND can be found at http://www.isc.org.
All vulnerabilities in your IRC server's OS should be
patched and updated. Likewise, if a vulnerability
arises in any of the running daemons such as SSHd or
IRCd, those should be updated as soon as possible.
d) Running a server requires the IRC network and community
placing a lot of trust in you. People who are known
not to be trustworthy or who have a history of not
acting in the best interests of IRC networks or its
community will typically be denied server links.
e) New servers will be defined as a Leaf - meaning that they
cannot link in other servers until such a time as it
is deemed that the server and its administration are
ready for such a load, and the server's network
location would provide a well-placed Hub server.
f) New servers may not be compiled in debug mode and all their
operators are not to be given global /kill, gline access
or remote squit/connect access during the trial period.
g) These days, a large EFnet client server can utilize several
mbits/s, which is a large amount of bandwidth for most
small ISPs. Given that large client servers are more
desirable than small 'local' servers, this will be
taken into consideration when reviewing the application.
New servers must be on a multi-homed network.
This multi-homed network should have a minimum
of 20 Gbit to at least two different ASN's.
We must also be able to verify that your server
is on a multi-homed network, via BGP announcements.
Routing on the network on which the IRC Server
resides should allow the server to fully utilize
the multiple links.
The server must be protected from attacks resulting
from ARP hijacking. One way to accomplish this is
by utilizing static arp addressing on your router.
In addition to static arp addressing, an EFnet
server should be on its own IP subnet and VLAN.
h) EFnet IRC Servers tend to attract frequent Distributed
Denial of Service (DDoS) attacks and hack attempts.
DDoS attacks can reach 50Gbps and higher, with
several million packets per second. Often times
these attacks are also not targeted at the servers
directly, but at neighboring routers or machines.
These attacks can often times cripple even the
most robust and diverse networks. New applicants
must be aware of this, and not only be ready to
deal with it, but must be versed in methods of
combating and protecting your server from DDoS
attacks.
i) The server must have their bots/abuse policies clearly
stated in the MOTD and contact information must be
stated in the Admin block. The server administration
should be willing to take measures to minimize
clone-botting by the use of connection limits
in the Class/Auth blocks and/or the use of monitoring
bots (oomon, tcm, etc.) and live operators.
j) All new servers must run an IRCd approved by the EFnet
admin body. The current approved IRCd is:
ircd-ratbox - http://www.ircd-ratbox.org/
k) Servers that intend to be 'closed' servers either by
means of the Auth block, of network announcements,
or by any other means must state this intent at the
time the server application is submitted. Very
few servers are able to justify being a 'closed'
EFnet server. Servers that intend to only
hold a couple of hundred clients due to Auth block
limits or closed announcements are typically denied
a trial or full link.
l) Any server downtime or period of absence must be
announced to the admins list prior to going
down (if applicable). If there is an unforeseen
incident that renders your server absent, notice
must be sent to the admins list as soon as possible.
m) Failure to comply or meet one or more of these guidelines
may end with the denial or termination of your link
to EFnet.
n) Last, but not least, there must be a need for a server
in your network location.
New Server Linking Notes:
An existing operator on another server may be appointed by
EFnet to help the new administration link their new server,
an admin defined as a Mentor. If a Mentor is appointed to you,
the new administration must make sure this Mentor has access
to the machine and account from which the IRCd runs.
The TRIAL period is currently set to 45 days.
During the TRIAL period the server and ALL its opers will
NOT be allowed to:
Participate in votes or admin-level tasks on EFnet.
Be subscribed to admins@ or opers@ lists.
Add spoofs for non-operators (existing operators
on other EFnet servers excluded).
Route/Connect servers other than relinking their own
server to the network.
/kill clients on remote servers.
Participate in GLINE votes (i.e. staff isn't permitted
to hold Global flag options).
At the end of this 45 day trial period, a vote may be called by
any admin to determine whether to delink your server or to extend
your server's trial period. If no questions or votes are called
at the end of your trial period, then you will be considered a
full linked server and eligible to all rights that it includes.
If a server is removed after its trial, or is voted down during the
application phase, it will not be permitted to reapply until 6
(six) months have passed.
After gaining access to IRC operators related mailing lists (and/or
channels), IRC operators must not divulge any sensitive information
transpiring on those, to non operators. This particularly concerns
naming other servers or persons, without express authorization.
---------- CUT ----------
1. Contact Info
1a. Server Admin Full Name:
1b. Server Admin Nick (include previous Nicks):
1c. Server Admin Phone:
1d. Server Admin Email:
1e. Relationship to server hardware and network (ie: employee,
colocation, student, etc):
1f. Sysadmin Contact:
1g. Network Admin Contact:
1h. Server Name:
2. Network Info
2a. Connectivity
Please list the connectivity your network has to various other
uplinks and providers, and this size of the connection to them.
Please also include the IP address of the IRC server, or an
IP address close to it for testing purposes. Any additional
relevant information may also be included:
2b. Does this server utilize static ARP addressing?:
2c. Is this server on its own IP subnet and/or VLAN?:
2d. Do you have uplink network support?:
2e. Hosting networks ASN:
2f. Please describe how (D)DoS attacks will be handled:
3. Machine Info
3a. Processor:
3b. OS and Version:
3c. RAM:
3d. Who has access to run processes on the machine:
3e. What other services are running on the machine (ftp, www,
smtp, pop3, imap, etc):
3f. Describe how ICMP unreachables and redirects are filtered:
3g. Please list nameservers that will be in resolv.conf,
and specify the version of BIND that each runs:
3h. How will you ensure the server's IP address will not be hijacked?
4. IRCd Info
4a. IRCd type and version:
4b. Site IRCd obtained from:
4c. Person responsible for compiling and upgrading IRCd:
4d. Will this server be a "closed" server (via Auth block,
network announcements, etc.) after the completion of
the trial period?:
5. Bot and Abuse Policies
Please detail your policies on Bots and Abusive users, and how you plan
to implement these policies:
6. Initial Opers
Please list: full names, common IRC nicks (including any previous
nicks), e-mail addresses and a personal detailed introduction of all
people who will be operators on your server when it goes online:
7. The Essay Question
How will EFnet benefit from your server being linked?
8. Starting date
Please state the date starting from which the server will be ready to
link to EFnet. In the case of a notification of link acceptance is less
than 2 weeks before the date you have stated, you will be expected to
link within 2 weeks after that notification. Failure to meet the linking
date will result in a cancellation of the link acceptance.
9. Traceroutes
Please include the output of traceroutes to the following sites. Note
that many EFnet servers filter ICMP and UDP packets. Run the
traceroutes as far as you can and make a note that they stopped before
reaching the destination.
a) irc.choopa.net
b) irc.colosolutions.net
c) irc.du.se
d) irc.efnet.pl
e) irc.homelien.no
f) irc.inet.tele.dk
g) irc.mzima.net
h) efnet.port80.se
i) irc.prison.net
j) irc.servercentral.net
k) irc.teksavvy.ca
l) irc.umich.edu
m) irc.underworld.no
10. All information provided will be validated before any
application will be considered. We reserve the right to reject
an application for any reason.