DNS queryen van subdomeinen

[Randomname]

Ik heb een vraag over de manier waarop mijn hosting provider zijn DNS heeft ingericht.

Het blijkt dat het mogelijk is om de DNS server van mijn hosting provider te queryen en daarmee een lijst van alle subdomeinen van mijn domein op te vragen. Hiervoor maak ik gebruik van de website http://www.magic-net.nl/dns-lookup.php. Het valt mij op dat dit queryen voor de meeste websites niet werkt, met de melding "Answer from x.x.x.x ; Transfer failed.". Voor mijn domein komt echter het complete zone record tevoorschijn, inclusief alle sub-domeinen.

Ik wil voorkomen dat de lijst met sub-domeinen publiekelijk opgevraagd kan worden voor mijn domein, net zoals bij veel andere domeinen het geval is.

Mijn vragen zijn:
1. Is het terecht om te stellen dat het opvragen van een lijst van alle sub-domeinen van een (in dit geval mijn eigen) domein - gehost bij een hosting provider - niet zomaar mogelijk zou moeten zijn?

2. Het toestaan van 'allow-transfer' bij de instellingen van een dns-server (en daarmee het ontsluiten van de volledige zone-records), duidt dat op minder professionele DNS-hosting?

3. Zou het een terechte vraag zijn aan mijn hosting provider om de DNS-server zo te configureren dat het queryen van sub-domeinen niet langer toestaat voor 'de rest van de wereld'?

Alvast bedankt voor jullie inzichten.

[fmanders]

Mijn vragen zijn:
1. Is het terecht om te stellen dat het opvragen van een lijst van alle sub-domeinen van een (in dit geval mijn eigen) domein - gehost bij een hosting provider - niet zomaar mogelijk zou moeten zijn?

Is volledig afhankelijk van je hoster, het gaat hier om een zogenaamde AXFR. Vrijwel elke hoster blokkeert deze standaard, echter mogelijk jou hoster niet of deze heeft het toevallig voor de betreffende opvragende server open staan (maar lijkt me niet).

2. Het toestaan van 'allow-transfer' bij de instellingen van een dns-server (en daarmee het ontsluiten van de volledige zone-records), duidt dat op minder professionele DNS-hosting?

Het is (zover bij mij bekend) niet iets wat standaard aan staat, mogelijk hebben ze dit expres open gezet. ik zou zeggen vraag het ze na, mogelijk hebben ze een rede waarom deze voor iedereen open staat.

3. Zou het een terechte vraag zijn aan mijn hosting provider om de DNS-server zo te configureren dat het queryen van sub-domeinen niet langer toestaat voor 'de rest van de wereld'?

In mijn mening is dit een terechte vraag om dit dicht te laten zetten, echter betwijfel ik het dat ze het verplicht zullen zijn. Als je het dicht wil hebben kun je het je hoster altijd vragen natuurlijk

[vDong]

2. Het toestaan van 'allow-transfer' bij de instellingen van een dns-server (en daarmee het ontsluiten van de volledige zone-records), duidt dat op minder professionele DNS-hosting?

Ik denk dat de kern van de vraag hierboven staat en het antwoord nee is.

Het zegt weinig over professioneel zijn, het zegt veel over keuzes maken.
Een amateur heeft dit eerder uit dan aan staan, ik verwacht dat dit een bewuste keuze is geweest.

[vDong]

Denk niet dat het heel schokkend is dat een axfr mogelijk is...
wat is precies de reden dat je zoiets niet zou willlen?

[NikB]

Ik heb een vraag over de manier waarop mijn hosting provider zijn DNS heeft ingericht.

Het blijkt dat het mogelijk is om de DNS server van mijn hosting provider te queryen en daarmee een lijst van alle subdomeinen van mijn domein op te vragen. Hiervoor maak ik gebruik van de website http://www.magic-net.nl/dns-lookup.php. Het valt mij op dat dit queryen voor de meeste websites niet werkt, met de melding "Answer from x.x.x.x ; Transfer failed.". Voor mijn domein komt echter het complete zone record tevoorschijn, inclusief alle sub-domeinen.

Ik wil voorkomen dat de lijst met sub-domeinen publiekelijk opgevraagd kan worden voor mijn domein, net zoals bij veel andere domeinen het geval is.

Mijn vragen zijn:
1. Is het terecht om te stellen dat het opvragen van een lijst van alle sub-domeinen van een (in dit geval mijn eigen) domein - gehost bij een hosting provider - niet zomaar mogelijk zou moeten zijn?

2. Het toestaan van 'allow-transfer' bij de instellingen van een dns-server (en daarmee het ontsluiten van de volledige zone-records), duidt dat op minder professionele DNS-hosting?

3. Zou het een terechte vraag zijn aan mijn hosting provider om de DNS-server zo te configureren dat het queryen van sub-domeinen niet langer toestaat voor 'de rest van de wereld'?

Alvast bedankt voor jullie inzichten.

Hallo Webhostingtalk,
Ik ben de eigenaar van http://www.magic-net.nl/ Normaal gesproken mag een DNS server geen kopies van zones aan derden sturen.
Volledige zone transfer bevat alle severs die horen bij een bepalde domein. Dat makt werk van een hacker veel makkelijker, omdat hacken is voor grote deel is gevullige informatie besparen.
Ik denk dat iedereen met mij eens zou zijn dat een a record for www of voor mail is niet zo grote geheim, maar records zoals payments, admin, phpmyadmin, ideal, secure, test is niet wat voor derden bekend hoort te zijn.

Het is ook een goede idee om te zorgen dat iets wat je geheim wilt houden niet in google komt, want als een DNS server goed ingericht is, je kan nog googelen voor subdomains.

Dus antwoord op je derde vraag is Ja.

Groet.

[vDong]

<KNIP>
Normaal gesproken mag een DNS server geen kopies van zones aan derden sturen.

Kan jij me aanwijzen in welke RFC dat staat?

Volledige zone transfer bevat alle severs die horen bij een bepalde domein. Dat makt werk van een hacker veel makkelijker, omdat hacken is voor grote deel is gevullige informatie besparen.
Ik denk dat iedereen met mij eens zou zijn dat een a record for www of voor mail is niet zo grote geheim, maar records zoals payments, admin, phpmyadmin, ideal, secure, test is niet wat voor derden bekend hoort te zijn.

Dit klinkt naar security through obscurity

Het is ook een goede idee om te zorgen dat iets wat je geheim wilt houden niet in google komt, want als een DNS server goed ingericht is, je kan nog googelen voor subdomains.

Als je beveiliging afhangt van het feit dat je dns records geheim blijven mag je je ernstig zorgen gaan maken. subdomeinen komen ook in google als de spider ze tegen komt, dus daar heb je helemaal geen AXFR voor nodig.

Ik snap dat je je businesscase wil verdedigen, maar je kan natuurlijk ook overdrijven.

[NikB]

==> Kan jij me aanwijzen in welke RFC dat staat?
Nee. Er is trouwens ook geen RFC waarin staat dat een goede password is van 12 characters. En er is geen RFC waarin staat dat het better is om gebruik van een firewall te maken en een antivirus op je PC hebben.
Security is een set van instellingen en maatregelen binnen en buiten een organisatie.
In dit geval gaat het om exposure of data http://en.wikipedia.org/wiki/DNS_zone_transfer

==> Dit klinkt naar security through obscurity
Hmm. Je moet toch wel wat ondernemen?
Een vergeten bestand op je site die genereert en error zoals:
Fatal error: Call to a member function on a non-object in /home/www/sDer4567/administrator/components/com_menus/models/item.php on line 212
vertelt aan attacker waar je website zich op server bevindt en hij kan jouw makkelijk hacken via een website die nast jouw site draait. En het maakt niet uit of jouw site wel of niet secure is. Dat is dus weer exposure of data.

==> Subdomeinen komen ook in google als de spider ze tegen komt.
Ja. Maar dat kan ook anders zijn. http://www.seoworkers.com/seo-articl...and-https.html

[vDong]

==> Kan jij me aanwijzen in welke RFC dat staat?
Nee. Er is trouwens ook geen RFC waarin staat dat een goede password is van 12 characters. En er is geen RFC waarin staat dat het better is om gebruik van een firewall te maken en een antivirus op je PC hebben.<knip wiki link>

Dat komt omdat beide dingen niet waar zijn, er is geen enkele reden om 12 charactars te hebben voor een password. Ik zie ook geen enkele dringende reden om een firewall en antivirus op mijn computer te installeren. Wel gebruik ik geen OS dat ongeschikt is voor internet gebruik, dus geen windows in mijn netwerk.

==> Dit klinkt naar security through obscurity
Hmm. Je moet toch wel wat ondernemen?

Dingen proberen te verbergen ipv ze te beveiligen is het slechtste advies wat je kan geven, natuurlijk is het voor jouw website (die je nu al 2x hebt gespammed) een core business, dus ik snap je motivatie

Een vergeten bestand op je site die genereert en error zoals:
Fatal error: Call to a member function on a non-object in /home/www/sDer4567/administrator/components/com_menus/models/item.php on line 212
vertelt aan attacker waar je website zich op server bevindt en hij kan jouw makkelijk hacken via een website die nast jouw site draait. En het maakt niet uit of jouw site wel of niet secure is. Dat is dus weer exposure of data.

Daar zijn gemakkelijke manieren om achter te komen, waaronder gewoon de mysql door z'n connecties heen te jagen.

==> Subdomeinen komen ook in google als de spider ze tegen komt.
Ja. Maar dat kan ook anders zijn. http://www.seoworkers.com/seo-articl...and-https.html

robots.txt is uitsluitend een verzoek om bepaalde gedeeltes niet te indexeren, zo maak je het eventuele hackers nog makkelijker, niet alleen kunnen ze zelf ook spideren, ze weten nu ook gelijk waar de "interessante" gedeeltes staan, dit is dat ook weer typisch een voorbeeld van "security"-advies waarvan het middel erger is dan de kwaal.

[Jurian]

AXFR's blokkeren voor security redenen is nogal on-nuttig. Als je niet wil dat een subdomein bekend wordt, moet je 't niet in de zone opnemen, lijkt me een stuk verstandiger. Subdomeinen proberen te verstoppen door AXFR's uit te zetten, is tijdverspilling. Alles wat in DNS staat is openbaar. Echte hackers vinden het toch wel, in google, in je website stats die perongelijk openbaar beschikbaar staan, in Alexa data (oeps, 1 van je bezoekers had die toolbar geinstalleerd) of op wat voor plek dan ook.

Beveiliging moet je op de juiste plek doen; dat is bijvoorbeeld een firewall die alleen bepaalde IP adressen toestaan op je admin systeem; en/of SSL certificaten voor je server EN je gebruikers die door allebei de kanten geverifieerd worden; of gewoon simpel gebruikersnaam en wachtwoord. Maar niet je handen voor je ogen houden en fluisteren "ik zie jou niet dus jij ziet mij ook niet", dat werkt misschien voor babies, maar zodra je een paar jaar oud bent werkt 't echt niet meer.

... en hij kan jouw makkelijk hacken via een website die nast jouw site draait. En het maakt niet uit of jouw site wel of niet secure is.

Uhm, dus jouw klanten kunnen elkaars sites wijzigen? OK, dan begrijp ik dat je AXFR's uitzet ja, stel je voor dat iemand het subdomein www van 1 van je klanten vindt, dan is gelijk heel je server te hacken...

[Randomname]

Bedankt voor jullie inzichten.

Ik ben het eens met de stelling van vDong dat security through obscurity - door het 'verbergen' van subdomeinen - geen goede manier is om wat dan ook te beveiligen. Wat ik wel belangrijk vind is dat de hosting provider zich bewust is van het feit dat die AXFR aan staat en dat ze kunnen uitleggen waarom dat zo is. Ik ga maar eens een mailtje sturen om er achter te komen.

[gjtje]

In de guidelines van de aptld staat wel degelijk dat een nameserver alleen op een axfr mag reageren wanneer de client één van de nameservers is.
Dan kan je natuurlijk zeggen, prutsers, wat weten zij nou, en een guideline, puh, dat is maar een guideline.

Er is ook nog geen reden genoemd waarom je het niet zou blokkeren. Meer toegang geven dan noodzakelijk is niet nodig.

[PreServer]

Er is ook nog geen reden genoemd waarom je het niet zou blokkeren. Meer toegang geven dan noodzakelijk is niet nodig.

Het syncen van andere dns servers (van andere partijen dan hunzelf)?

[Randy]

 dig @ns1.leaseweb.nl leaseweb.nl axfr

Alex de J, kom er maar in...

Niet echt een partij waarvan je zou verwachten dat ze AXFR vanaf elk IP toestaan.

[DiedX]

cocweb.leaseweb.nl.... Hmmmmmmmm

Afgezien van de discussie "wel of geen security through obscurity" (ik denk dat voor alles wel wat te zeggen is): is er 1 geldige reden om *WEL* AXFR toe te staan?

[Pur]

cocweb.leaseweb.nl.... Hmmmmmmmm

Afgezien van de discussie "wel of geen security through obscurity" (ik denk dat voor alles wel wat te zeggen is): is er 1 geldige reden om *WEL* AXFR toe te staan?

Het secondary draaien na een verhuizing?