Wat verwacht jij van BIND 10?

[burema]

Beste forum leden,

Zoals jullie allemaal weten (of nu weten) is de ontwikkeling van BIND (Berkeley Internet Name Domain) versie 10 gestart. Nou ben ik benieuwd welke dingen jullie als verwachten in deze nieuwe versie, bijvoorbeeld standaard DNSSEC of welke functies jullie nog missen in BIND. En misschien zijn er zelfs leden op het forum die hier al meer van weten

# BIND
http://nl.wikipedia.org/wiki/BIND
# DNSSEC
http://en.wikipedia.org/wiki/Dnssec
# BIND 10
https://www.isc.org/bind10/project
# SIDN Helpt mee
http://www.sidn.nl/ace.php/c,727,605...e_BIND_10.html

Voor alle PowerDNS liefhebbers, Ga A.U.B niet lopen roepen "PowerDNS is beter" wat daar hebben hier niks aan. Het gaat hier over BIND en niet over welke name server beter is!

[Randy]

Voor DNSSEC is gestart met OpenDNSSec, iets waar de SIDN en NLNetLabs in Nederland ook een bijdrage aan leveren.

Met betrekking tot BIND10 ben ik blij dat ze opnieuw beginnen en het geen 'patch' is. Er zijn wat - nu gezien - fundamentale fouten gemaakt met de ontwikkeling die we 10 jaar terug nog niet konden voorzien. Ik weet niet hoeveen letches BIND9 gehad heeft, maar bij 10 criticals ben ik gestopt met tellen.

Een groter probleem krijg je met de BIND's (en mDNSresponders) in de thuisroutertjes. Het gaat nog jaaaren duren voordat deze vervangen en geupdate zijn. Pas dan zal een hele DNSSEC-chain goed werken, evenzo geldt eigenlijk ook voor de IPv6 slag die straks begint in de consurouter markt.

En niet iedereen heeft een Juniper SSG-5 als thuisrouter

[PimEffting]

BIND is al jarenlang geplaagd door security problemen.
Ik hoop dat ze dat nu eindelijk eens onder de knie krijgen...

[The-BosS]

Een supermaster systeem zoals in powerdns zou wel handig zijn, of dan op zijn minst toch een systeem om nsupdate uit te voeren zonder eerst eigen ssh scripts te moeten uitvoeren.

Wat meer support voor ipv6 zou ook mooi zijn, voornamelijk het GENERATE commando voor reverse of default AAAA records zoals oplopende reeksen (bvb: <ip>.static.<hoster>.<tld>).

[Randy]

Een supermaster systeem zoals in powerdns zou wel handig zijn, of dan op zijn minst toch een systeem om nsupdate uit te voeren zonder eerst eigen ssh scripts te moeten uitvoeren.

Welk deel van AXFR-transfers heb jij gemist?

Sep  7 14:57:01 sv01 named[19037]: loading configuration from '/etc/named.conf'
Sep  7 14:57:01 sv01 named[19037]: zone ispi.nl/IN: loaded serial 2009090700
Sep  7 14:57:01 sv01 named[19037]: zone ispi.nl/IN: sending notifies (serial 2009090700)
Sep  7 14:57:02 sv01 named[19037]: client 212.79.238.133#58964: transfer of 'ispi.nl/IN': AXFR started
Sep  7 14:57:02 sv01 named[19037]: client 212.79.238.133#58964: transfer of 'ispi.nl/IN': AXFR ended
Sep  7 14:57:02 sv01 named[19037]: client 212.79.238.133#58965: transfer of 'ispi.nl/IN': AXFR started
Sep  7 14:57:02 sv01 named[19037]: client 212.79.238.133#58965: transfer of 'ispi.nl/IN': AXFR ended

[luser]

Welk deel van AXFR-transfers heb jij gemist?

Sep  7 14:57:01 sv01 named[19037]: loading configuration from '/etc/named.conf'
Sep  7 14:57:01 sv01 named[19037]: zone ispi.nl/IN: loaded serial 2009090700
Sep  7 14:57:01 sv01 named[19037]: zone ispi.nl/IN: sending notifies (serial 2009090700)
Sep  7 14:57:02 sv01 named[19037]: client 212.79.238.133#58964: transfer of 'ispi.nl/IN': AXFR started
Sep  7 14:57:02 sv01 named[19037]: client 212.79.238.133#58964: transfer of 'ispi.nl/IN': AXFR ended
Sep  7 14:57:02 sv01 named[19037]: client 212.79.238.133#58965: transfer of 'ispi.nl/IN': AXFR started
Sep  7 14:57:02 sv01 named[19037]: client 212.79.238.133#58965: transfer of 'ispi.nl/IN': AXFR ended

Dit is puur als je updates doet in de master zone en slave al configed is. Bij het toevoegen van een nieuwe zone op je master moet je ook manueel je slave configureren.

[phreak]

Hm, wat native SQL support (en niet met een lading patches erbij) zou wel erg fijn zijn..

[burema]

Ja maar zou het niet erg exploit gevoelig daar door worden? denk aan SQL injecties.

[phreak]

Ja maar zou het niet erg exploit gevoelig daar door worden? denk aan SQL injecties.

BIND != html ofzo..

Ik denk niet dat dat een issue zal zijn, maar het zone-file idee is naar mijn mening wel outdated (en ja, zie bijvoorbeeld de backend van pdns).

[burema]

Oke maar exploit kan ook via een telnet of netcat

nc -v ns1.nameserver.nl 53

En dan RFC´s gaan lezen.

[phreak]

En wat heeft dat verder met het backend te maken, enlighten me please..

[Japje]

Oke maar exploit kan ook via een telnet of netcat

nc -v ns1.nameserver.nl 53

En dan RFC´s gaan lezen.

<offtopic> en dan hopen dat je klaar bent met RFC's lezen voor je een timeout krijgt?</offtopic>

ik gebruik geen bind, dus zou het niet durven zeggen wat ze er allemaal in moeten stoppen... denk dat er tegenwoordig veel vraag is naar een database backend.

Ben zelf nog steeds geen voorstander van DNSSEC.. dat word straks een leuk zooitje

Wat ik zelf een leuke feature vind aan tinydns (djbdns) is dat je records kunt timen.. dus dat ze op tijd X ingaan... als ze dan toch nieuwe features zoeken mogen ze dat er wel instoppen

[t.bloo]

denk dat er tegenwoordig veel vraag is naar een database backend

maar dan wel dat het ook makkelijk nog anders kan, voor je het weet is de ene service afhankelijk van tientallen andere componenten die ook goed moeten draaien

[Apoc]

BIND != html ofzo..

Ik denk niet dat dat een issue zal zijn, maar het zone-file idee is naar mijn mening wel outdated (en ja, zie bijvoorbeeld de backend van pdns).

Het punt is dat op veel servers (neem bijvoorbeeld alle cPanel/Plesk/etc servers) zowel een DNS server (BIND) als webserver (Apache) draait. Als deze beide gebruik maken van dezelfde SQL server, zou dat een probleem kunnen zijn.

[phreak]

Het punt is dat op veel servers (neem bijvoorbeeld alle cPanel/Plesk/etc servers) zowel een DNS server (BIND) als webserver (Apache) draait. Als deze beide gebruik maken van dezelfde SQL server, zou dat een probleem kunnen zijn.

Klopt, maar dan zou je je als programmeur toch moeten afvragen waar je mee bezig bent, zeker in het oogpunt van security test je dat toch zeker van te voren. Sowieso is je customer backend al afgeschermd van "het grote publiek"