Network services

DeiC operates name servers (DNS servers) on which research network institutions can place their domains.

DeiC operates a set of authoritative name servers that research network institutions can use.

Research network institutions can choose to place their domains on DeiC name servers (or operate them themselves). It is possible to use the research network's name server ns-soa.darenet.dk as a secondary for a local name server - with or without DNSSEC.

The name servers are: ns-soa.darenet.dk, mimer.deic.dk and orion.i2.dk.

Each of the three servers physically consists of two redundant servers that can be accessed at the same IP address.

The servers for ns-soa are located in Lyngby and Risø, respectively. Similarly for mimer. orion is located 'outside the house' - in a data center in Skanderborg and with GlobalConnect IP connection.

Forskningsnettet also operates some DNS caches that can be used for lookups directly from the users' equipment, including acting as a backup for a local name server. It should be noted that the caches can only be accessed from selected networks. The cache is located at:

130.226.1.2 (2001:878:0:100::2). The cache is established with two servers - one in Lyngby and one in Risø and responds to the same IP address.

Service manager

The service manager is Head of Network Operations Jan Ferré.

Support

dns@deic.dk

Computers can synchronize their internal clock with Network Time Protocol (NTP) servers.

Time service from DeiC makes it easy to ensure that the institution's computers and other devices are set to the correct time.

DeiC runs a time service based on the Network Time Protocol (NTP) standard. The current time can be retrieved at ntp.forskningsnettet.dk, which is a Stratum-2 server. Forskningsnettet also has access to a Stratum-1 server, which can be used, for example, to synchronize local time servers.

Support

netdrift@deic.dk

DeiC operates mail.forskningsnettet.dk, which can be used as an outgoing mail relay for research network IP addresses.

DeiC operates a mail service that institutions on the research network can freely use.

DeiC operates mail.forskningsnettet.dk, which is an outgoing mail relay for the research network's IP addresses.

mail.forskningsnettet.dk supports TLS1.2.

All machines that deliver mail to mail.forskningsnettet.dk must have a PTR record in DNS.

All emails sent through mail.forskningsnettet.dk must have a valid sender from a domain with an MX record and a valid SPF record containing at least "ip4:130.226.1.3".

For our sake, it is allowed to have a sender address, no-reply@, that ends up in /dev/null, as long as it receives mails correctly.

Support

• Inquiries to mailrelay@support.deic.dk
• Operational incidents are reported via serviceinfo.dk -> DeiC services -> BasisNet

With FileSender, users on the research network can send files that are too large to send as email. Find a description of FileSender in the Service overview at the top of the menu.

Iperf is a tool for testing the bandwidth of a network connection and diagnosing performance and quality issues.

Iperf is a tool for testing the bandwidth of a network connection and diagnosing performance and quality issues.

Iperf is not intended for continuous monitoring of the network connection. Iperf provides more detailed information than the bandwidth test under My Research Net.

DeiC's iperf server is located at iperf.deic.dk. The server can be reached from anywhere in the world. To access it, from a command line, execute the command:

iperf -c iperf.deic.dk

To use the service, you must have an iperf app installed on the machine you are testing the connection from.

The program is open source and can be downloaded from iperf.fr or from relevant app stores for other platforms.

With Multicast, large amounts of data such as video, audio and other forms of streaming can be sent between many users at the same time without disproportionately burdening the network.

With Multicast, large amounts of data such as video, TV, audio and other forms of streaming can be sent between many users at the same time without disproportionately burdening the network. The philosophy of Multicast is that data only needs to pass through a link once - whether there is 1 or 100 people who want to receive that data.

The research network supports Multicast. However, as there are often obstacles in the form of firewalls in practice, Multicast does not have a significant role. This also means that you shouldn't rely on Multicast actually getting through without a thorough test first.

Multicast concerts have been held where data from a symphony orchestra abroad has been reproduced in an audio and visual concert at the University of Copenhagen.

IP multicast, information from Wikipedia

DNSSEC is a security feature for the DNS naming system. It is designed to protect devices from forged DNS data.

DNSSEC extends the Domain Name System with digital signature security.

The original design of the Domain Name System (DNS) did not include any form of security, but was planned to be a scalable and distributed system. Domain Name System Security Extensions (DNSSEC) attempts to add the missing security while being backwards compatible.

DNSSEC is designed to protect internet clients from spoofed DNS data that can be introduced, for example, via DNS cache poisoning attacks.

All DNSSEC responses are digitally signed. By verifying the digital signature, a DNS resolver is able to ensure that the information is identical (correct and complete) to the information found on the corresponding authoritative DNS server.

While securing the IP address is the primary purpose for many users, DNSSEC can also protect any other information that may be stored in a DNS server. This includes web certificates, DKIM keys for email and SSH keys.

• DNSSEC does not provide data confidentiality and does not protect against DoS attacks.
• DNS zone transfer between servers is not protected (but best practice is to prohibit it - we do not allow zone transfer in general)

DeiC offers DNSSEC on our authoritative DNS servers.

This allows institutions on the research network to secure their own domains with DNSSEC. Institutions can either let the research network take care of domain maintenance or let the research network be a slave server for the institution's own domain.

Slave server for the institutions own domain

To get started with authoritative DNSSEC with its own DK domain, the institution must go through the following steps.

We assume that BIND 9.18 or later is used as DNS.

• The server is set to run DNSSEC (dnssec-enable yes; )
• The zone file is added to the server in the traditional way.
• Two keys are generated, ZSK and KSK, each with a public and a private part (dnssec-keygen)
• The zone configuration file is adjusted (auto-dnssec maintain; inline-signing yes; }
• A "DS key" (dnssec-dsfromkey) is extracted from the KSK key and installed at Punktum.dk (formerly DK-Hostmaster) via their self-service page.

Then BIND is started, which automatically signs the domain/zone and transfers the signed zone to any slave servers, such as the research network's DNSSEC servers.

The actual signing of the zone has become very simple, as the server can perform a so-called "inline signing". However, the ZSK (typically every three months) and KSK (typically every 12 months) keys still need to be renewed regularly in a so-called "rollover" process. Note: KSK rollover requires updating the DS key (as the last step in the installation).

It is important that all authoritative slave servers run DNSSEC for a given domain.

The Research Grid's authoritative name servers can be used as authoritative slave servers with DNSSEC. Please contact dns@deic.dk.

DNSSEC cache

To get started with a cache DNSSEC server for its local users, newer BIND 9 servers will only require the following lines in the server configuration file:

dnssec-enable yes; dnssec-validation yes;

Agreement

For the institution to use DeiC's DNSSEC servers, an agreement must be made. Henvendelse bedes sendt til vil gerne anvende DeIC nets DNSSEC servere som / for domænet <.....dk>">dns@deic.dk.

DeiC operates a mail service that institutions on the research network can freely use.

DeiC operates mail.forskningsnettet.dk, which is an outgoing mail relay for research network IP addresses.

mail.forskningsnettet.dk supports TLS1.2.

All machines that deliver mail to mail.forskningsnettet.dk must have a PTR record in DNS.

All mails sent through mail.forskningsnettet.dk must have a valid sender from a domain with an MX record and a valid SPF record containing at least "ip4:130.226.1.3".

For our sake, it is allowed to have a sender address, no-reply@, that ends up in /dev/null as long as it receives mails correctly.

Support

• Inquiries to mailrelay@support.deic.dk
• Operational incidents are reported via serviceinfo.dk -> DeiC services -> BasisNet

DDPS stands for DDoS Protection Service and is an offer for authorized network administrators to be able to add their own firewall rules to the Research Network's central routers as a supplement to the institution's own firewalls. This is done in real time and there is both a web-based user interface and an API access that can be connected to the institution's IDS.

The purpose of DDPS

DDoS attacks are often short-lived and to make a difference, quick response is important. You can still contact network operations and have filters set in the Research Grid's routers, null routing and other measures, but even in the best case scenario, it can easily take several minutes for these manual measures to take effect. DDPS is the Research Network's offer that anyone affected by an attack can implement filters themselves, and these rules take effect with seconds notice.

Security

The users on DDPS can potentially block the entire institution's internet traffic with just a few clicks - even in error. Therefore, there is a short introductory procedure to ensure that traffic can be blocked to networks for which the user is the network administrator. The service is accessed through eduVPN, which we use to ensure that the user still has a valid WAYF login and thus that the user is still connected to the institution.

We also recommend that you physically sit on your institution's network when using DDPS and not on a VPN from home, otherwise you may inadvertently exclude yourself from accessing the system.

Technology

DDPS works by using BGP FlowSpec (RFC 5575) to inject rules into the central routers of the Research Network. The ambition is that these rules will eventually also be implemented in NORDUnet's routers, but this is not the case right now. The rules are based on IP address blocks, so if you want to block one or more BGP prefixes, you have to translate this to IP addresses first. You can then make the rules work on TCP, UDP, ICMP and other types of traffic, just as you can specify port numbers and the rule can then implement bandwidth limitation or ensure that the traffic in question is dropped completely.

There is a limited number of rules that can be accommodated in the routers, and therefore there will also be a limit to how many rules each institution can have active at the same time. Currently, the limit is 500 simultaneous rules per institution and a maximum of 500 new rules per minute. We are willing to change these numbers if it is appropriate. From the time a rule is active in DDPS until it can actually be seen to be blocked in traffic, it takes between 10 and 20 seconds.

What does DDPS cost?

DDPS is only relevant if you are already connected to the Research Network and the service is included in what the institution already pays for connection to the Research Network. The service requires the institution to be connected to WAYF, but this is also included in the connection to Forskningsnettet.

How do I get started?

The process of creating and authorizing the user starts by sending an email to ddps-info@deic.dk.

Support

The few authorized users will be sent relevant documentation, including information about support in operation.

No channel has been created for DDPS in Serviceinfo, where we currently expect to send operational information about DDPS out the Basisnet channel.