[PHP] Hoe ca 70.000 domeinen controleren?

[Verwijderd]

Ik moet ca 70.000 domeinen eenmaal per dag controleren of het domein onze nameservers gebruikt of niet, dit wil ik via een PHP script doen en het resultaat dan in een database stoppen.
Echter het probleem is dat het PHP script er na ca 1,5 uur vanzelf mee stop (draait via een cron), in de cron log staat geen error.

Het script zelf doet in die tijd ca 20.000 domeinen controleren.
code wat ik gebruik doe ik via een functie:

PHP:

function checknameserver($domein) {
    $checkex = shell_exec("dig NS $domein +short +time=1 +tries=2 +retry=2"); 
    $result = explode("\n",$checkex);
    $result1 = trim($result[0]);
    $ip = gethostbyname("$result1");
    if ( $ip=="123.456.789.000")
        {
        return 1;
        } else {
        return 0;
        }
    }

(ik heb het $ip waarde aangepast, het vermelde IP is dus niet het echte ip wat ik gebruik)

Via een "while" haal ik dus ca 70.000 domein namen uit een mysql database, vervolgens check ik 1 voor 1 het domein via de bovenstaande functie, het resultaat wordt dan weer direct terug in een database weg geschreven.

Mijn vraag is nu eigenlijk is er geen betere(snellere) manier om deze domeinen te controleren en wat zonder problemen alle domeinen kan controleren?

[Tofu]

Enkele scripts parallel laten lopen, en in de db bijhouden waar je gestopt bent?

[simon]

waarom doe je 't niet in verschillende batches?

edit: te laat

[ Voor 15% gewijzigd door simon op 09-05-2008 22:44 ]

[[ash]]

Is er een specifieke reden waarom je dit met PHP wil doen? Kan je er niet beter een shell script van maken welke simpelweg via textfiles de status bij houdt. Je kan dan altijd met PHP deze files geregeld uitlezen en in een database opslaan.

Misschien is het zelf een idee om MyDNS te gebruiken? Deze DNS server slaat zijn informatie op in een MySQL database. Enige wat je dan moet doen is elke dag die 70.000 records queryen en zorgen dat deze dns server het cached. Dan kan je met PHP weer die database uitlezen.

[Verwijderd]

ja dat moet haast wel, vraag me alleen af waarom ie stopt
Is daar toevallig een reden voor?

Zou ik geen problemen kunnen krijgen als ik elke dag zoveel domeinen DIG, bv door een block op de root servers (of zoiets)?

[Johnny]

Ik moet echt even reageren op je code, die kan zo in het topic met slechte voorbeelden. Een if-statement met vervolgens een return true/false is echt een overbodige constructie, net zoals variabelen tussen aanhalingstekens zetten. Je kan je regel 4 t/m 11 met dit vervangen wat precies hetzelfde doet:

PHP:

    $ip = gethostbyname(trim($result[0]));
    return $ip == "123.456.789.000"

Verder kan je IP's ook gewoon als integer opslaan en verwerken in plaats van strings, zowel PHP als MySQL hebben daar ingebouwde functies voor.

[Verwijderd]

Wij gebruiken al een DNS met mysql backend (powerdns)

De reden dat ik wil doen is dat wij als beheerders direct willen kunnen zien of domeinen welke bij ons in de DNS staan ook daadwerkelijke onze nameservers gebruiken, als ik dit vanuit het panel zelf wil laten doen dan duurt het beeld opbouw veel te lang.
Ik wil dus voordat we beginnen s' morgens via een cron een script draaien wat onze gehele DNS scant en kijkt of het domein onze NS gebruikt of niet, omdit via een cron te doen heb je geen vertraging in de frontend, de resultaten worden immers uit de database gehaald.

In princiep kan dit ook met een ander soort script mits het result maar direct in de mysql DB wordt gestopt.

[pistole]

dat PHP ermee kapt zou misschien aan geheugen gebruik kunnen liggen; gebruik dus batches enzo (en liever shell scripts, maar dat terzijde).

Waarom zou je eigenlijk dig gebruiken en niet `host -t NS $domain`? Je kan dan een check doen of je de nameserver krijgt die je verwacht, en gebruikt daarvoor niet per sé de root servers. Pas als je afwijkende antwoorden krijgt zou je kunnen gaan diggen.

[AndriesLouw]

Houd in ieder geval bij waar je script gebleven is, zoals eerder genoemd bijvoorbeeld in een DB. Sla de tijd/datum op van de laatste controle als timestamp, en laat het PHP script alles wat minder dan 24 uur geleden is gecontroleerd opnieuw checken (gesorteerd op timestamp, dus oudsten eerst). Laat daarbij dit script bijvoorbeeld elke 5 minuten X stuks controleren, zodat je een beetje de load kunt managen.

Ik zie sowieso niet zozeer het nut van deze informatie via een cron, tenzij je gebruikers een mailtje wilt sturen als ze niet je nameservers gebruiken, kun je beter deze informatie pas opvragen als de klant iets in zijn DNS wil wijzigen.

Edit:
Je wilt dit dus wel in een panel tonen, probeer het dan alleen af te scheiden van de beeldopbouw, laat bijvoorbeeld op de achtergrond een proces lopen wat de domeinen checkt van een klant, en zodra de informatie beschikbaar is toon je die in de reeds opgebouwde pagina (AJAX is wellicht handig).

Edit 2:
En breid mijn eerste edit uit met een caching mechanisme, zodat het bijvoorbeeld maar eens in de 24 uur opnieuw opgevraagd kan worden.

[ Voor 26% gewijzigd door AndriesLouw op 09-05-2008 23:07 ]

[Verwijderd]

Johnny schreef op vrijdag 09 mei 2008 @ 22:58:
Verder kan je IP's ook gewoon als integer opslaan en verwerken in plaats van strings, zowel PHP als MySQL hebben daar ingebouwde functies voor.

Nee dit kan niet, ik mag de bestaande database structuur niet aanpassen
Het is dus een werkende DNS omgeving, de reeds aanwezig rijen mag ik niet aanpassen, ik moet het dus doen met de bestaande structuur.

[Verwijderd]

De info is niet voor de gebruikers maar voor ons zelf, maar de reden dat we dit willen doet er niet toe.

Ik wil het liefst NIET onze nameservers gebruiken, deze geven immers altijd retour dat het domein onze NS gebruikt, dat is dus wat ik juist eruit wil filteren. Als ik dus een dig doe dan moet dit op een externe server zijn. Als het domein nog in onze DNS staat maar het is bv opgeheven of verhuisd en ik doe een dig hierop dan komt altijd een resultaat retour dat dit domein onze nameserver gebruikt terwijl dit dus al niet meer het geval is, vandaag de check op externe NS.

[Bergen]

Voor elke return weer opnieuw gethostbyname aanroepen is ook niet echt efficient he? Als 't nou voor een paar hosts is, maar voor 70,000? Dan zou ik toch eens wat gaan cachen. Maak een array $known_hosts aan ofzo en kijk bij elke return of hij in die array voor komt. Zo niet, roep dan gethostbyname aan en voeg hem toe aan de array. Ik gok zo dat je daarmee een ENORME tijdswinst behaalt, want gethostbyname is niet echt snel.

[ Voor 16% gewijzigd door Bergen op 09-05-2008 23:22 ]

[pistole]

Verwijderd schreef op vrijdag 09 mei 2008 @ 23:08:
Ik wil het liefst NIET onze nameservers gebruiken, deze geven immers altijd retour dat het domein onze NS gebruikt, dat is dus wat ik juist eruit wil filteren.

Dat snap ik, maar je kan toch wel een andere nameserver gebruiken? Van je bandbreedteprovider wellicht? Scheelt een hoop tijd en traffic, vermoed ik.

@hieronder: 30.000 records opzoeken in een databaseje mag het probleem niet vormen, dat is peanuts natuurlijk... String of int.

[ Voor 14% gewijzigd door pistole op 09-05-2008 23:14 ]

[Jaap-Jan]

In plaats van shell_exec() zou ik gebruik maken van ingebouwde functies van PHP: dns_get_record().

En eigenlijk wel met Johnny, het opslaan van een IP- adres als string is een rare structuur. Die string is een representatie bedoeld voor mensen, de 32- bits integer is de manier waarop het eigenlijk opgeslagen moet worden.

Verder vind ik het gebruik van explode() nogal inefficient als je alleen de eerste regel nodig hebt, al heb je daar geen last meer van als je gebruik maakt van dns_get_record().

[Infinitive]

Dat je script er mee stopt kan te maken hebben met het bestaan van een tijdslimiet op de executie van je script:

http://nl2.php.net/function.set-time-limit

Hoewel ik zou verwachten dat de tijdslimiet veel lager is dan anderhalf uur...

[kmf]

Als je met cron dit doet, neem ik aan dat je php-cgi gebruikt? Waarom dan niet simpelweg het werk verdelen in x-aantalen en parallel uitvoeren? Dus bv 14 aanroepen en dan elk 5000 domeinnamen laten checken of zo?

(ik denk dat het probleem meer ligt bij gethostbyname. Toen ik deze ooit probeerde, was het vrij traag.

Johnny schreef op vrijdag 09 mei 2008 @ 22:58:
Ik moet echt even reageren op je code, die kan zo in het topic met slechte voorbeelden. Een if-statement met vervolgens een return true/false is echt een overbodige constructie, net zoals variabelen tussen aanhalingstekens zetten. Je kan je regel 4 t/m 11 met dit vervangen wat precies hetzelfde doet:

PHP:

    $ip = gethostbyname(trim($result[0]));
    return $ip == "123.456.789.000"

offtopic:
Just because it's shorter, doesn't make it better.

Ik vind die if-statement veel simpeler lezen.
Leesbaarheid is ook wat waard. En eenmaal gecompileerd maakt het toch geen filkker uit.

[ Voor 17% gewijzigd door kmf op 10-05-2008 00:28 ]

[simon]

alleen php wordt niet gecompileerd..

[Johnny]

Infinitive schreef op zaterdag 10 mei 2008 @ 00:09:
Dat je script er mee stopt kan te maken hebben met het bestaan van een tijdslimiet op de executie van je script:

http://nl2.php.net/function.set-time-limit

Hoewel ik zou verwachten dat de tijdslimiet veel lager is dan anderhalf uur...

Het wachten op IO en shell scripts, waar in dit geval de meeste tijd in zit wordt niet meegeteld met de execution time van PHP, dus het kan dat de limiet lager is dan anderhalf uur terwijl het script er toch langer over doet.

kmf schreef op zaterdag 10 mei 2008 @ 00:25:

offtopic:
Just because it's shorter, doesn't make it better.

Ik vind die if-statement veel simpeler lezen.
Leesbaarheid is ook wat waard. En eenmaal gecompileerd maakt het toch geen filkker uit.

Het is een sterke aanwijzing dat de maker van het script toch niet erg ervaren is, en dat er waarschijnlijk wel andere vreemde dingen gebeuren die misschien de oorzaak zijn van het probleem.

Verder is de leesbaarheid vogens mij juist verbeterd omdat de complexiteit is afgenomen. Iedere programmeur met een beetje ervaring weet dat een vergelijking met <, > of == gelijk is aan een boolean, daar heb je echt geen 4 regels extra voor nodig.

Een interessant artikel hier over: http://okasaki.blogspot.com/2008/02/boolean-confusion.html

[ Voor 45% gewijzigd door Johnny op 10-05-2008 00:50 ]

[Verwijderd]

Verwijderd schreef op vrijdag 09 mei 2008 @ 22:42:
...

dig kan je in batch modus starten met -f. Op deze manier hoef je dig maar een keer op te starten en kost dit minder resources. Een manier om met zo'n batch modus om te gaan is een co-process in ksh, zie het voorbeeld hieronder. Dit kan vast ook wel in script taal X maar ik heb geen zin om dat nu voor je uit te zoeken.

code:

#!/bin/ksh

# start co-process
dig -f - |&

# dit kan je veranderen naar mysql | while read line etc
# om door de resultaten van een mysql query door te lopen.
while read line
do
    print -p $line
    read -p result
    print $result
    # hier kan je eventueel nog een dig lookup doen om het
    # ip adres op te halen van de NS server.
done < lookups

[kmf]

Johnny schreef op zaterdag 10 mei 2008 @ 00:27:
Verder is de leesbaarheid vogens mij juist verbeterd omdat de complexiteit is afgenomen. Iedere programmeur met een beetje ervaring weet dat een vergelijking met <, > of == gelijk is aan een boolean, daar heb je echt geen 4 regels extra voor nodig.

Dat is nog steeds persoonlijke voorkeur. Ik denk (hoop) niet dat de TS de werking van vergelijkingen niet weet.
Maar om daar op af te gaan dat hij weinig ervaring heeft vind ik te ver gaan. De if-statement zoals hij het gebruikt lijkt meer op natuurlijke taal en leest sneller door.

En tja.. 4 regels ipv 2. Qua cpu-tijd maakt het nog steeds niks uit.

_{(hoewel ik vind dat een return van 1 of 0... vreemd is. Het gaat er om dat zo'n manier van programmeren niet fout is. Zeker als je niet zeker weet of er idd enkel een waarde teruggegeven wordt. Misschien dat ie in de if-statement nog wat dingen laat (gaat) uitvoeren.
Er zijn talloze redenen te bedenken om zo te programmeren.}



Oh, en in de link die je zelf geeft, misschien wel een meer valide reden

Oh, yes, there can definitely be reasons to prefer the more verbose constructions in situations and/or languages when you can't be certain the object in question is a boolean, especially if the interpretation of potential non-boolean values isn't quite the one you want.

[ Voor 17% gewijzigd door kmf op 10-05-2008 02:14 ]

[xces]

Verwijderd schreef op vrijdag 09 mei 2008 @ 23:08:
De info is niet voor de gebruikers maar voor ons zelf, maar de reden dat we dit willen doet er niet toe.

Het lijkt me evident om dit toch te vermelden. Waarom wil je anders een server verkrachten door dagelijks 70.000 records te querien? Als het jullie eigen server is, dan zou ik nl ook de load in de gaten houden tijdens de executie.

Om je toch te helpen;
- het kan geen time_limit zijn aangezien het script al 1,5 succesvol draait.
- je gebruikt php_cli en geen php_cgi, d.w.z. als je het via "/usr/bin/php ..<jescript>" draait.
- als een domein eenmaal op jullie NS draait, en je wil voorkomen dat hij verhuisd zal worden, kun je dit doen dmv een domain lock (op .COM domeinen)

of je zou een soort van secondary DNS kunnen draaien; (die dan als slave draait), en hier bouw je je logica omheen. In deze DNS zet je al je domeinen, en zullen dus automatisch getriggered worden zodra een domein verhuisd en kun je (nog) sneller reageren. Ik weet niet of je hier al aan gedacht had?

[Verwijderd]

kmf schreef op zaterdag 10 mei 2008 @ 02:10:

Oh, en in de link die je zelf geeft, misschien wel een meer valide reden
[...]

Daar heb je toch === en !== voor

[GlowMouse]

xces schreef op zaterdag 10 mei 2008 @ 10:41:
[...]
Om je toch te helpen;
- het kan geen time_limit zijn aangezien het script al 1,5 succesvol draait.

Johnny schreef op zaterdag 10 mei 2008 @ 00:27:
Het wachten op IO en shell scripts, waar in dit geval de meeste tijd in zit wordt niet meegeteld met de execution time van PHP, dus het kan dat de limiet lager is dan anderhalf uur terwijl het script er toch langer over doet.

[Verwijderd]

xces schreef op zaterdag 10 mei 2008 @ 10:41:
[...]

Het lijkt me evident om dit toch te vermelden. Waarom wil je anders een server verkrachten door dagelijks 70.000 records te querien? Als het jullie eigen server is, dan zou ik nl ook de load in de gaten houden tijdens de executie.

Om je toch te helpen;
- het kan geen time_limit zijn aangezien het script al 1,5 succesvol draait.
- je gebruikt php_cli en geen php_cgi, d.w.z. als je het via "/usr/bin/php ..<jescript>" draait.
- als een domein eenmaal op jullie NS draait, en je wil voorkomen dat hij verhuisd zal worden, kun je dit doen dmv een domain lock (op .COM domeinen)

of je zou een soort van secondary DNS kunnen draaien; (die dan als slave draait), en hier bouw je je logica omheen. In deze DNS zet je al je domeinen, en zullen dus automatisch getriggered worden zodra een domein verhuisd en kun je (nog) sneller reageren. Ik weet niet of je hier al aan gedacht had?

PHP draait reeds in cli modus en is in PHP4 (upgraden naar 5 is nu geen optie ivm incompatibiliteit problemen met het aanwezige DNS panel), tevens het gaat er niet om dat domeinen niet verhuisd kunnen worden of dat we dat zien of ze verhuisd worden.

Het gaat erom als een medewerker in de DNS kijkt (meestal voor support) hij direct kan zien of dit specifieke domein wel of niet onze NS gebruikt. Natuurlijk kan de medewerker in kwestie zelf een DIG doen op het domein echter om eventuele support handelingen te versoepelen was er de wens dat in de HUIDIGE dns panel men direct kan zien of een domein wel of niet onze NS gebruikt.

Ook zijn er meerdere NS in gebruik, 3 in totaal echter maar 1 DNS panel op 1 server.
Deze server doet verder ook niets anders als de DNS regelen en het panel wat erbij hoort (geheel in PHP4 met een mysql database).

Bedankt voor de "tips" hoe het "ook anders kan" maar dat is niet de bedoeling, het is dus gewoon de bedoeling zodra je een domein naam ingeeft (via een zoek opdracht) in het bestaande DNS panel (waar dus ca 70.000 domeinen in zitten) dat je DIRECT te zien krijgt of dat ene domein of alle domeinen van je zoek opdracht wel of niet onze NS gebruiken.

Mijn idee wat dus om elke nacht een cron te laten draaien welke de gehele DNS checked zodat deze check voor 9.00u in de ochtend klaar is voor gebruik voor de medewerkers.
Op dit moment wordt dit nog gedaan IN het panel zelf via elke zoek opdracht, bij een paar domeinen gaat dit wel maar als je zoek resultaat bv meer als 20 tot 30 domeinen geeft treedt er een zeer irritante vertraging op wat ik wilde oplossen via deze cron.

[CyBeR]

Kijk eens naar de verschillende DNS functies in php, zoals checkdnsrr(). Lijkt me een stuk beter dan steeds dig exec()en.

[Verwijderd]

deze meeste van deze functies werken alleen onder PHP5, zoals al vermeld draait er PHP4 op deze server en is een upgrade naar PHP5 op dit moment helaas geen optie (het DNS panel werkt niet goed onder PHP5), al had ik dit wel graag gewild.

[Gomez12]

Mwah, je begrijpt dat je nog steeds een vertraging genereert van 24 uur?

Ik zou eerder kiezen voor een oplossing die in de locale dbase kijkt wat de laatste status van de afgelopen 24 uur, is deze er niet toon dan de pagina direct, laat op de achtergrond php de domeinen checken en in de dbase zetten, via ajax zet je de waardes weer in je getoonde pagina.

Dan heb je direct een pagina om te tonen aan de gebruiker, je controleert alleen degenen die opgevraagd worden en niet elke dag 70.000.

Maar als je toch elke dag 70.000 records wil checken, doe het batchgewijs.

[Jaap-Jan]

Waar komt die 'vertraging' dan vandaan? Als de medewerker de status wil weten, dan hoeft toch alleen dát domein gecontroleerd te worden? Als je het hebt over 20 tot 30 zou dat peanuts moeten zijn.

[Verwijderd]

Verwijderd schreef op vrijdag 09 mei 2008 @ 22:42:
Ik moet ca 70.000 domeinen eenmaal per dag controleren of het domein onze nameservers gebruikt of niet, dit wil ik via een PHP script doen en het resultaat dan in een database stoppen.
Echter het probleem is dat het PHP script er na ca 1,5 uur vanzelf mee stop (draait via een cron), in de cron log staat geen error.

Zet is wat debug opties aan van PHP; of draai php zelf in een debugger.

Het script zelf doet in die tijd ca 20.000 domeinen controleren.
code wat ik gebruik doe ik via een functie:

PHP:

function checknameserver($domein) {
    $checkex = shell_exec("dig NS $domein +short +time=1 +tries=2 +retry=2"); 
    $result = explode("\n",$checkex);
    $result1 = trim($result[0]);
    $ip = gethostbyname("$result1");
    if ( $ip=="123.456.789.000")
        {
        return 1;
        } else {
        return 0;
        }
    }

(ik heb het $ip waarde aangepast, het vermelde IP is dus niet het echte ip wat ik gebruik)

Dit is natuurlijk heel erg inefficient, je start 70 000 keer dig op wat erg veel cpu tijd kost. Zoals ik in een paar posts hier boven heb aangegeven kan je dit oplossen m.b.v. een co-process.

Via een "while" haal ik dus ca 70.000 domein namen uit een mysql database, vervolgens check ik 1 voor 1 het domein via de bovenstaande functie, het resultaat wordt dan weer direct terug in een database weg geschreven.

Mijn vraag is nu eigenlijk is er geen betere(snellere) manier om deze domeinen te controleren en wat zonder problemen alle domeinen kan controleren?

Niet alle domeinen controleren maar een wrapper maken voor dig die het voor een enkel domein opzoekt.

[Gomez12]

Jaap-Jan schreef op zaterdag 10 mei 2008 @ 20:17:
Waar komt die 'vertraging' dan vandaan? Als de medewerker de status wil weten, dan hoeft toch alleen dát domein gecontroleerd te worden? Als je het hebt over 20 tot 30 zou dat peanuts moeten zijn.

Als je praat over 20 / 30 losse checks van .1 seconde praat je toch over 2 / 3 seconden. Is dit met elke pagina zo, dan lijkt het hele systeem traag.

[Confusion]

Verwijderd schreef op vrijdag 09 mei 2008 @ 23:08:
Ik wil het liefst NIET onze nameservers gebruiken, deze geven immers altijd retour dat het domein onze NS gebruikt

Dat zou niet zo moeten zijn. Jullie nameserver zal van google.com immers ook niet zeggen dat het jullie nameserver gebruikt. Als iemand een andere nameserver voor zijn domein heeft ingesteld, dan hoort jullie nameserver te zeggen dat die andere nameserver de 'authoritative' nameserver voor dat domein is.

[CyBeR]

Confusion schreef op zaterdag 10 mei 2008 @ 22:34:
[...]

Dat zou niet zo moeten zijn.

Jawel.

Jullie nameserver zal van google.com immers ook niet zeggen dat het jullie nameserver gebruikt. Als iemand een andere nameserver voor zijn domein heeft ingesteld, dan hoort jullie nameserver te zeggen dat die andere nameserver de 'authoritative' nameserver voor dat domein is.

Niet als jouw nameserver denkt dat hij zelf authoritative is voor een domein.

[Verwijderd]

Mwah, je begrijpt dat je nog steeds een vertraging genereert van 24 uur?

Nee hoezot, als het zou werken dan wordt er s' morgens (rond 6~7 uur) een check gedaan van alle domeinen, als men om 8 of 9 uur begint te werken dan is deze check dus maar max 2 uur oud. Dit noem ik toch echt wel "actueel", als men naar de details kijkt van het domein (de records) wordt nu al een "live" check gedaan dus kan met de actuele status zien.

Confusion schreef op zaterdag 10 mei 2008 @ 22:34:
[...]

Dat zou niet zo moeten zijn. Jullie nameserver zal van google.com immers ook niet zeggen dat het jullie nameserver gebruikt. Als iemand een andere nameserver voor zijn domein heeft ingesteld, dan hoort jullie nameserver te zeggen dat die andere nameserver de 'authoritative' nameserver voor dat domein is.

Jawel dus, als ik in onze DNS het domein google.com zou toevoegen en ik doe een DIG op dit domein en specificeer dat ik dit moet checken op onze nameservers dan krijg ik netjes retour dat google.com onze nameservers gebruikt. Dit is ook de reden dat ik dus via een externe NS wil controleren waar het domein exact draait.

Jaap-Jan schreef op zaterdag 10 mei 2008 @ 20:17:
Waar komt die 'vertraging' dan vandaan? Als de medewerker de status wil weten, dan hoeft toch alleen dát domein gecontroleerd te worden? Als je het hebt over 20 tot 30 zou dat peanuts moeten zijn.

Niet bij een zoek opdracht.
Als ik een zoek opdracht geef bv van een domein met daarin het woord "sex" krijg ik een paar duizend resultaten terug, men wil dus in het overzicht lijst al kunnen zien welke NS er wordt gebruikt.
Het zelfde geld als ik bv opvraag alle domeinen met een bepaald IP adres of alle domeinen van een bepaalde klant, al dit soort zoek functies geven vaak veel resultaten retour wat dus een vertraging veroorzaakt welk ongewenst is.

Ik ben het met je eens dat deze vertraging er niet is bij 1 domein of bv bij maar 10 zoek resultaten, maar het komt in de praktijk helaas vaak voor dat er VEEL meer resultaten zijn, dus is het "live" opvragen niet echt een optie.

Ik ga eens een beetje spelen met de diverse oplossingen die genoemd zijn en kijken wat het beste werkt (in een test omgeving), de code optimaliseren zal ik ook uitvoeren echter ik denk niet dat dit enig merkbaar effect zal hebben met dit probleem.

[ Voor 33% gewijzigd door Verwijderd op 11-05-2008 03:19 ]

[burne]

Verwijderd schreef op vrijdag 09 mei 2008 @ 22:42:
Ik moet ca 70.000 domeinen eenmaal per dag controleren of het domein onze nameservers gebruikt of niet

Je maakt een extreem fundamentele denkfout. Je heb ooit je domeinen gechecked op authoritieve nameservers en bent er achter dat dat niet werkt. Het is nooit in je opgekomen om zelf een niet-authoritieve nameserver (een caching nameserver) op te zetten. Nu zoek je een manier om anderen op te zadelen met je gebrek aan begrip wat nameservers zijn.

In plaats van je voor te laten lichten over hoe je anderen opzadelt met de last van je eigen onbegrip van het verschijnsel DNS lijkt het me beter dat je eens wat tijd steekt in het uitzoeken van de verschillen tussen authoritief en resolver.

Je kunt ieder aspect van je probleem zelf oplossen zonder DDoS op de nameserver van andere ISP's. Doe dat dan ook, en hou op met anderen laten betalen voor jouw problemen.

[Confusion]

CyBeR schreef op zaterdag 10 mei 2008 @ 23:15:
Niet als jouw nameserver denkt dat hij zelf authoritative is voor een domein.

Ahja, een NS die denkt dat hij authoritative is, zal nooit DNS requests voor een van 'zijn' domeinen naar een andere NS zal sturen. (En zal er daardoor nooit achterkomen dat die andere NS later als 'authoritative' is gezet voor dat domein, als er al een mechanisme was om dat soort conflicten op te lossen). Logisch, maar ik had het me nog niet gerealiseerd.

@B3rt:
Overigens, dat 'dig' commando geeft bij mij al een IP terug. Daar is dus geen gethostbyname nodig? Waarschijnlijk wordt het script dan al een stuk sneller.

Verwijderd schreef op zondag 11 mei 2008 @ 03:10:
Ik ben het met je eens dat deze vertraging er niet is bij 1 domein of bv bij maar 10 zoek resultaten, maar het komt in de praktijk helaas vaak voor dat er VEEL meer resultaten zijn, dus is het "live" opvragen niet echt een optie.

Live opvragen, met caching nadat het is opgevraagd? Het opvragen naar de achtergrond delegeren en de pagina updaten met gevonden resultaten 'so far'. Dan zal het voor de eerste paar bevragingen en voor grote zoekvragen traag zijn, maar gedurende de dag vanzelf sneller worden. De pagina zal ook meteen alle beschikbare informatie tonen en ASAP de benodigde DNS informatie. De meeste mensen zullen die niet eens nodig hebben. Is eleganter, maar veel meer werk.

Een punt met je huidige aanpak is dat als het script 's nachts een keer vastloopt (wat ongetwijfeld zal gebeuren, door een korte network outage, etc.), dan moet je het overnieuw draaien, wat weer 5 uur kost. Tot die tijd mis je de nieuwe informatie dus. Je moet dus de oude informatie behouden tot de nieuwe compleet is, kunnen 'verdergaan waar je gebleven was', etc.

Daarnaast inderdaad wat burne zegt: je kan natuurlijk zelf die nameserver verzorgen die je wilt gaan ondervragen.

[ Voor 4% gewijzigd door Confusion op 11-05-2008 10:40 ]

[Bergen]

Confusion schreef op zondag 11 mei 2008 @ 10:38:
[...]

@B3rt:
Overigens, dat 'dig' commando geeft bij mij al een IP terug. Daar is dus geen gethostbyname nodig? Waarschijnlijk wordt het script dan al een stuk sneller.

Dat verschilt per domein lijkt mij. Het is maar net wat er in de zone is ingevoerd bij de NS-records, daar kun je zowel hostnames (A-records) als IP-adressen invullen. (Alhoewel, ik begin ook al te twijfelen of dat wel mag, het zou best eens kunnen dat NS-records beslist naar A-records moeten wijzen.)

[ Voor 13% gewijzigd door Bergen op 11-05-2008 10:59 ]

[paulh]

Jaap-Jan schreef op vrijdag 09 mei 2008 @ 23:13:
En eigenlijk wel met Johnny, het opslaan van een IP- adres als string is een rare structuur. Die string is een representatie bedoeld voor mensen, de 32- bits integer is de manier waarop het eigenlijk opgeslagen moet worden.

Nou ik niet. Zulke suboptimalisaties zijn totaal nutteloos en leveren geen significante tijdwinst op. Waarschijnlijk gaat het je alleen maar tijd kosten als je een keer met de hand door de tabel gaat struinen staan er allemaal integers waar je een ip nummer totaal niet in herkent. Nee, doe mij maar herkenbaar en duidelijk.

[burne]

Bergen schreef op zondag 11 mei 2008 @ 10:45:
(Alhoewel, ik begin ook al te twijfelen of dat wel mag, het zou best eens kunnen dat NS-records beslist naar A-records moeten wijzen.)

Glue-records moeten IP's zijn.

[CyBeR]

burne schreef op zondag 11 mei 2008 @ 12:55:
[...]

Glue-records moeten IP's zijn.

Een glue record is een A record. Een NS record moet altijd naar een A record wijzen.

[Gomez12]

paulh schreef op zondag 11 mei 2008 @ 12:53:
[...]
Nou ik niet. Zulke suboptimalisaties zijn totaal nutteloos en leveren geen significante tijdwinst op. Waarschijnlijk gaat het je alleen maar tijd kosten als je een keer met de hand door de tabel gaat struinen staan er allemaal integers waar je een ip nummer totaal niet in herkent. Nee, doe mij maar herkenbaar en duidelijk.

Waarom zou je door een tabel heen moeten struinen? Als je daar al rekening mee gaat houden...
Zorg dat het goed en snel werkt. Wil er dan ooit eens iemand door de db heenstruinen, dan maak je maar een view aan die je int omzet naar een string..

[Archiebald]

Verwijderd schreef op zondag 11 mei 2008 @ 03:10:
[...]
Niet bij een zoek opdracht.
Als ik een zoek opdracht geef bv van een domein met daarin het woord "sex" krijg ik een paar duizend resultaten terug, men wil dus in het overzicht lijst al kunnen zien welke NS er wordt gebruikt.
Het zelfde geld als ik bv opvraag alle domeinen met een bepaald IP adres of alle domeinen van een bepaalde klant, al dit soort zoek functies geven vaak veel resultaten retour wat dus een vertraging veroorzaakt welk ongewenst is.

Ik ben het met je eens dat deze vertraging er niet is bij 1 domein of bv bij maar 10 zoek resultaten, maar het komt in de praktijk helaas vaak voor dat er VEEL meer resultaten zijn, dus is het "live" opvragen niet echt een optie.

Ik ga eens een beetje spelen met de diverse oplossingen die genoemd zijn en kijken wat het beste werkt (in een test omgeving), de code optimaliseren zal ik ook uitvoeren echter ik denk niet dat dit enig merkbaar effect zal hebben met dit probleem.

Heb je ook gedacht aan paginanummering?
Gebruik je pagina's van 30 domeinen per pagina. Dus het aantal blijft beperkt.
Men moet alleen wel een paar handelingen extra verrichten als het domein wat zij zoeken op bijv. pagina 3 staat.

Wat je ook kan doen.
Je slaat op welke NS er wordt gebruikt. Als de medewerkers zoeken naar een bepaald domein, zien zij de opgeslagen NS met de datum waarop het als laatst gecontroleerd is. Hierbij kan dan een linkje/ajax-achtig iets staan met: Controleer NS. Als ze daarop klikken wordt de NS gecontroleerd en opgeslagen in de DNS database (en natuurlijk weergegeven). De volgende keer zien ze die NS en datum erbij staan, met de welbekende link

[ Voor 0% gewijzigd door Archiebald op 11-05-2008 13:39 . Reden: typo ]

[Jaap-Jan]

paulh schreef op zondag 11 mei 2008 @ 12:53:
[...]
Nou ik niet. Zulke suboptimalisaties zijn totaal nutteloos en leveren geen significante tijdwinst op. Waarschijnlijk gaat het je alleen maar tijd kosten als je een keer met de hand door de tabel gaat struinen staan er allemaal integers waar je een ip nummer totaal niet in herkent. Nee, doe mij maar herkenbaar en duidelijk.

Het gaat me niet eens om de tijdwinst. Om te beginnen, voor de herkenning gebruik je duidelijke tabelnamen. Als je je tabeldata moet nakijken om te weten wat de betekenis is van de inhoud, dan heb je geen goede naamgeving gebruikt voor je kolommen.

Twee, wat betreft tijdswinst: je ip- adres is nu 4x zo groot. Dat is, als je meer kolommen tegelijk ophaalt, niet significant en het omzetten naar een dotted quad adres met long2ip() kost ook tijd. Of het echt tijdwinst oplevert zou gebenchmarked moeten worden, ik durf daar geen uitspraak over te doen, eerlijk gezegd.

Tot slot ik kan in een VARCHAR(15), die een IPv4 adres voorstelt (bijna, soms wel soms niet) een IPv6 adres opslaan. Nou is dat niet verschrikkelijk voor voor 70.000 adressen (maximaal 700kB), maar ik zie eigenlijk geen reden waarom je het niet zou doen.

[ari]

Verwijderd schreef op zondag 11 mei 2008 @ 03:10:
Ik ben het met je eens dat deze vertraging er niet is bij 1 domein of bv bij maar 10 zoek resultaten, maar het komt in de praktijk helaas vaak voor dat er VEEL meer resultaten zijn, dus is het "live" opvragen niet echt een optie.

Je kunt ook de pagina gewoon laden, met een 'laden'-icoontje voor het resultaat van je check (bij elk zoekresultaat dus). Dan kun je vervolgens met een AJAX-oplossing je checks laten doen en die later inladen op de plek van je 'laden'-icoontje. Bijvoorbeeld als de pagina klaar is met laden, of bij een onClick/onMouseOver.

Je hebt dan wel een snelle pagina, je moet alleen na het laden wachten op het resultaat van je checks.

[burne]

CyBeR schreef op zondag 11 mei 2008 @ 13:10:
Een glue record is een A record. Een NS record moet altijd naar een A record wijzen.

Hum.

code:

$ dig +short NS ns.nl
ns2.nl.ignite.net.
ns1.ns.nl.

We zouden allebei dus wat duidelijker moeten formuleren.

NS-records zijn ofwel RR's, ofwel IP's, en in het laatste geval noemt men ze glue records. Een RR van een NS mag alleen maar resolven naar een A of AAAA, niet naar een CNAME.

Zoiets?

[xces]

Verwijderd schreef op zaterdag 10 mei 2008 @ 18:45:
[...]

Het gaat erom als een medewerker in de DNS kijkt (meestal voor support) hij direct kan zien of dit specifieke domein wel of niet onze NS gebruikt. Natuurlijk kan de medewerker in kwestie zelf een DIG doen op het domein echter om eventuele support handelingen te versoepelen was er de wens dat in de HUIDIGE dns panel men direct kan zien of een domein wel of niet onze NS gebruikt.

Ook zijn er meerdere NS in gebruik, 3 in totaal echter maar 1 DNS panel op 1 server.
Deze server doet verder ook niets anders als de DNS regelen en het panel wat erbij hoort (geheel in PHP4 met een mysql database).

Is het geen idee om een slave DNS erbij te plaatsen, ook op SQL gebaseerd? Je hoeft dan enkel een query op die MySQL database te doen. Supersnel en aan de last update tijd kun je wel een waarde koppelen (alsin; het domein staat al 23 uur op onze NS servers).

edit: deze NS moet je dan wel laten draaien op een andere server...

[ Voor 3% gewijzigd door xces op 11-05-2008 20:07 ]