Netværkstjenester

DeiC driver navneservere (DNS-servere), som institutioner på forskningsnettet kan lægge deres domæner på.

DeiC driver et sæt autoritative navneservere, som institutioner på forskningsnettet kan bruge.

Institutioner på forskningsnettet kan vælge at lægge deres domæner på navneservere hos DeiC (eller drive dem selv). Det er muligt at anvende forskningsnettets navneserver ns-soa.darenet.dk som sekundær for en lokal navneserver - med eller uden DNSSEC.

Navneserverne er: ns-soa.darenet.dk, mimer.deic.dk og orion.i2.dk. 

Hver af de tre servere består fysisk af to redundante servere, der kan tilgås på samme IP-adresse.

Serverne for ns-soa er placeret i hhv. Lyngby og Risø. Tilsvarende for mimer. orion er placeret 'udenfor huset' - i et datacenter i Skanderborg og med GlobalConnect IP-tilslutning. 

Forskningsnettet driver endvidere nogle DNS-caches, som kan anvendes til opslag direkte fra brugernes udstyr, herunder fungere som backup for en lokal navneserver. Det bør bemærkes, at Cache-serverne kun kan tilgås fra udvalgte net. Cachen findes på:

130.226.1.2 (2001:878:0:100::2). Cachen er etableret med to servere - én i Lyngby og én i Risø og svarer på samme IP-adresse.

Tjenesteansvarlig

Tjenesteansvarlig er chef for netdrift Jan Ferré.

Support

dns@deic.dk

Computere kan synkronisere deres interne ur med NTP-servere (Network Time Protocol).

Tidsservice fra DeiC gør det let at sikre, at institutionens computere og andre enheder er indstillet til det korrekte klokkeslæt.

DeiC driver en tidsservice baseret på standarden NTP (Network Time Protocol). Det aktuelle klokkeslæt kan hentes på ntp.forskningsnettet.dk, der er en Stratum-2 server. Forskningsnettet har også adgang til en Stratum-1 server, som for eksempel kan bruges til synkronisering af lokale tidsservere.

Support

netdrift@deic.dk

DeiC driver mail.forskningsnettet.dk, der kan bruges som udgående mailrelæ for forskningsnettets IP-adresser.

DeiC driver en mail-tjeneste, som institutioner på forskningsnettet frit kan benytte.

DeiC driver mail.forskningsnettet.dk, der er et udgående mailrelæ for forskningsnettets IP-adresser.

mail.forskningsnettet.dk understøtter TLS1.2.

Alle maskiner, der afleverer mail til mail.forskningsnettet.dk, skal have en PTR-record i DNS.

Alle mails, der udsendes gennem mail.forskningsnettet.dk, skal have en valid afsender fra et domæne med en MX-record og en valid SPF-record, som mindst indeholder "ip4:130.226.1.3".

Det er for vores skyld tilladt at have en afsenderadresse, no-reply@<domæne>, der havner i /dev/null, så længe den modtager mails korrekt.

Support

• Henvendelser til mailrelay@support.deic.dk
• Driftshændelser rapporteres via serviceinfo.dk -> DeiC tjenester -> BasisNet

Med FileSender kan brugere på forskningsnettet sende filer, der er for store til at sende som e-mail. Find en beskrivelse af FileSender i Tjenesteoversigten øverst i menu'en.

Iperf er et redskab til at teste båndbredden på en netforbindelse, samt diagnosticere performance- og kvalitetsproblemer.

Iperf er et redskab til at teste båndbredden på en netforbindelse samt diagnosticere performance- og kvalitetsproblemer.

Iperf er ikke beregnet til kontinuerlig overvågning af netforbindelsen. Iperf giver mere detaljerede oplysninger end båndbreddetesten under Mit forskningsnet.

DeiCs iperf-server findes på adressen iperf.deic.dk. Serveren kan nås fra hele verden. For at tilgå den skal du fra en kommandolinje udføre kommandoen:

iperf -c iperf.deic.dk

For at bruge servicen skal du have installeret en iperf-app på den maskine, du tester forbindelsen fra.

Programmet er open source og kan downloades fra iperf.fr eller fra relevante app-stores for øvrige platforme.

Med Multicast kan store datamængder som video, lyd og andre former for streaming sendes mellem mange brugere på samme tid uden at belaste netværket uforholdsmæssigt.

Med Multicast kan store datamængder som video, tv, lyd og andre former for streaming sendes mellem mange brugere på samme tid uden at belaste netværket uforholdsmæssigt. Filosofien i Multicast er, at data kun skal passere et link én gang - uanset om der er 1 eller 100, der ønsker at modtage disse data.

Forskningsnettet understøtter Multicast. Men da der i praksis ofte er forhindringer i form af firewalls, har Multicast ikke nogen betydende rolle. Det betyder også, at man ikke skal stole på, at Multicast rent faktisk kommer igennem, uden at man foretager en grundig test først.

Der har været afholdt Multicast-koncerter, hvor data fra et symfoniorkester i udlandet er blevet reproduceret ved en auditiv og visuel koncert på Københavns Universitet.

IP multicast, information fra Wikipedia

DNSSEC er en sikkerhedsfunktion til navnesystemet DNS. Den er designet til at beskytte enheder mod forfalskede DNS-data.

DNSSEC udvider domænenavnesystemet med sikkerhed via digitale signaturer.

Det oprindelige design af DNS (Domain Name System) indeholdt ikke nogen form for sikkerhed, men var derimod planlagt til at være et skalerbart og fordelt system. DNSSEC (Domain Name System Security Extensions) forsøger at tilføje den manglende sikkerhed samtidig med, at det er bagudkompatibelt.

DNSSEC er designet til at beskytte internetklienter mod forfalskede DNS-data, der f.eks. kan blive indlagt via angreb af typen "DNS cache poisoning".

Alle DNSSEC-svar er signeret digitalt. Ved at kontrollere den digitale signatur er en DNS resolver i stand til at sikre sig, at informationen er identisk (korrekt og komplet) med den information, som findes på den tilhørende autoritative DNS-server.

Selvom sikringen af IP-adressen er det primære formål for mange brugere, så kan DNSSEC også beskytte al anden information, som kan lagres i en DNS-server. Det kan f.eks. være webcertifikater, DKIM-nøgler til mail og SSH-nøgler.

• DNSSEC giver ikke fortrolighed for data og beskytter ikke mod DoS-angreb.
• DNS zone transfer mellem servere er ikke beskyttet (men 'Best Practise' er at forbyde det - vi tillader derfor ikke zone transfer generelt)

DeiC tilbyder DNSSEC på vores autoritative DNS-servere.

Det giver institutionerne på forskningsnettet mulighed for at sikre deres egne domæner med DNSSEC. Institutioner kan enten lade forskningsnettet stå for vedligehold af domænet eller lade forskningsnettet være slaveserver for institutionens eget domæne.

Slaveserver for institutionernes eget domæne

For at komme igang med autoritativ DNSSEC med sit eget DK-domæne skal institutionen gennem følgende trin.

Vi forudsætter her, at man anvender BIND 9.18 eller nyere som DNS.

• Serveren sættes til at køre DNSSEC (dnssec-enable yes; )
• Zonefilen indlægges på serveren på traditionel vis.
• Der genereres to nøgler, ZSK og KSK, hver med en offentlig og en privat del (dnssec-keygen)
• Konfigurationsfilen for zonen justeres (auto-dnssec maintain; inline-signing yes; }
• Fra KSK-nøglen udtrækkes en "DS key" (dnssec-dsfromkey), som installeres hos Punktum.dk (tidl. DK-Hostmaster) via deres selvbetjeningsside.

Derefter startes BIND, som automatisk foretager en signering af domænet/zonen og overfører den signerede zone til eventuelle slaveservere, f.eks. forskningsnettets DNSSEC-servere.

Selve signeringen af zonen er blevet meget simpel, idet serveren kan foretage en såkaldt "inline signing". Der er dog fortsat behov for en jævnlig fornyelse af ZSK- (typisk hver tredie måned) og KSK- (typisk hver 12. måned) nøglerne i en såkaldt "rollover" proces. OBS: KSK-rollover kræver opdatering af DS key (som sidste punkt i installationen).

Det er vigtigt, at alle autoritative slaveservere kører DNSSEC for et givet domæne.

Forskningsnettets autoritative navneservere kan benyttes som autoritative slaveservere med DNSSEC. Henvendelse til dns@deic.dk.

DNSSEC cache

For at komme i gang med en cache DNSSEC server for sine lokale brugere vil nyere BIND 9-servere blot kræve følgende linier i serverens konfigurationsfil:

dnssec-enable yes; dnssec-validation yes;

Aftale

For at institutionen kan anvende DeiCs DNSSEC-servere, skal der indgås en aftale om det. Henvendelse bedes sendt til dns@deic.dk.

DeiC driver en mail-tjeneste, som institutioner på forskningsnettet frit kan benytte.

DeiC driver mail.forskningsnettet.dk, der er et udgående mailrelæ for forskningsnettets IP-adresser.

mail.forskningsnettet.dk understøtter TLS1.2.

Alle maskiner, der afleverer mail til mail.forskningsnettet.dk, skal have en PTR-record i DNS.

Alle mails, der udsendes gennem mail.forskningsnettet.dk, skal have en valid afsender fra et domæne med en MX-record og en valid SPF-record, som mindst indeholder "ip4:130.226.1.3".

Det er for vores skyld tilladt at have en afsenderadresse, no-reply@<domæne>, der havner i /dev/null, så længe den modtager mails korrekt.

Support

• Henvendelser til mailrelay@support.deic.dk
• Driftshændelser rapporteres via serviceinfo.dk -> DeiC tjenester -> BasisNet

DDPS står for DDoS Protection Service og er et tilbud til autoriserede netværksadministratorer om at kunne lægge deres egne firewall-regler ind i Forskningsnettets centrale routere, som et supplement til institutionens egne firewalls. Dette sker i real tid og der er både en web-baseret brugergrænseflade og en API-adgang som kan kobles sammen med institutionens evt. IDS.

Formålet med DDPS

DDoS-angreb er ofte kortvarige og for at gøre en forskel er hurtig reaktion vigtig. Man kan fortsat henvende sig til netdriften og få sat filtre i Forskningsnettets routere, lavet null-routninger og andre tiltag, men det kan, selv i bedste fald, nemt tage en del minutter før den slags manuelle tiltag har virkning. DDPS er Forskningsnettets tilbud om at den, der er ramt af at angreb kan implementere filtre selv, og disse regler har virkning med sekunders varsel.

Sikkerhed

Brugerne på DDPS kan potentielt set med få klik - også ved en fejl - let blokere for hele institutionens internettrafik. Derfor er der en kort introduktionsprocedure, som går ud på at sikre sig at der kan kan blokeres for trafik til net som den pågældende er netværkadministrator for. Der logges ind til tjenesten gennem eduVPN som vi bruger til at sikre os at brugeren stadig har et gyldigt WAYF-login og dermed at brugeren stadig er tilknyttet institutionen.

Vi anbefaler iøvrigt at man sidder fysisk på sin institutions net når man bruger DDPS og ikke på en VPN hjemmefra, da man ellers utilsigtet kan komme til at udelukke sig selv fra adgang til systemet.

Teknik

DDPS virker ved bruge BGP FlowSpec (RFC 5575) til at injicere regler i Forskningsnettets centrale routere. Det er ambitionen på sigt at disse regler også bliver implementeret i NORDUnets routere, men sådan er det ikke lige nu. Reglerne er baseret på IP-adresseblokke, så hvis man ønsker at blokere for et eller flere BGP-prefixes skal man selv oversætte dette til IP-adresser først. Her kan man så få reglerne til at virke på TCP, UDP, ICMP og andre typer af trafik, ligesom man kan specificere portnumre og reglen kan så implementere båndbreddebegrænsning eller sørge for at den pågældende trafik helt droppes.

Der er et begrænset antal regler som samlet set kan rummes i routerne, og derfor vil der også være en grænse for hvor mange regler den enkelte institution kan have aktive på samme tid. Pt er grænsen 500 samtidige regler pr. institution og maksimalt 500 nye regler pr. minut. Disse tal er vi villige til at ændre, hvis det er hensigtsmæssigt. Fra en regel er aktiv i DDPS til den faktisk kan ses at blive blokeret i trafikken, går der mellem 10 og 20 sekunder.

Hvad koster DDPS?

DDPS er kun relevant, hvis man i forvejen er koblet op på Forskningsnettet, og tjenesten er inkluderet i det som institutionen allerede betaler for tilslutning til Forskningsnettet. Tjenesten kræver at institutionen er tilsluttet WAYF, men det er jo også inkluderet i tilslutningen til Forskningsnettet.

Hvordan kommer jeg igang?

Processen med oprettelse og autorisation af brugeren starter med at man sender en mail til ddps-info@deic.dk.

Support

De få autoriserede brugere får relevant dokumentation tilsendt, herunder information om support i drift.

Der er ikke oprettet en kanal vedr DDPS i Serviceinfo, hvor vi indtil videre forventer at sende driftsinformation om DDPS ud Basisnet-kanalen.