SOA (Start of Authority)

Vind uw SOA record en zorg ervoor dat het juist is.

ACHTERGROND: De SOA record is essentiële informatie over uw zone. Zij bepaalt welke server je primaire nameserver, uw contactgegevens (e-mail), hoe uw secundaire nameservers krijgen bijgewerkt, en de standaard (minimum) Time-To-Live-waarden voor uw administratie.

Vind uw SOA gegevens. Om SOA uw gegevens optevragen, kunt u gebruiken maken van nslookup of DIG (of een ander programma of een website, dat kan query DNS-records van een nameserver die u kiest). Moet u uw domein als de domeinnaam op te vragen, query voor het SOA record, een keer voor elke nameserver op de lijst u hebt opgeschreven.

Met gebruik van nslookup, voer "server nameserver.example.com" (doe dit een keer per nameserver op uw lijst, ter vervanging van "nameserver.example.com" met een nameserver op een moment). Typ 'set type = SOA ". Ten slotte, typt u uw domeinnaam ( "example.com"). U ziet het SOA-record voor uw domein.

DIG gebruiken, voert u uw domein naam als de domeinnaam op te vragen, en voert u elke server uit de lijst die u schreef (een tegelijk), en kijken naar de SOA of "Zone van Autoriteit "sectie.

Probleem? Zorg ervoor dat het SOA record geretourneerd door elke naam server is identiek. Als de nummers verschillend zijn, zult u moeten wachten tot het aantal seconden in de "refresh" van de nameserver met het lagere serienummer voor haar te krijgen bijgewerkt (of meer tijd als de secundaire nameserver niet kunnen bereiken de primaire). Als de primaire nameserver heeft een lager nummer dan een tweede, je hebt een serieus probleem dat je zal moeten oplossen. Als de serienummers zijn hetzelfde, maar andere gegevens is anders, je hebt een serieus probleem - je primaire is bijgewerkt zonder actualisering van het serienummer (update van het serienummer en het probleem zal vast).

Probleem? Het SOA record moet de eerste record in uw zone file, en moet ook het laatste record in de zone file. Het moet alleen die twee keer, en beide van de inzendingen moeten identiek zijn. Dit kan worden geverifieerd correct alleen op de nameserver zelf; de procedure varieert afhankelijk van de software die u gebruikt.

Controleer uw gegevens SOA

• MNAME ( "Primaire NS") - Dit is de domeinnaam van de server die naam was het oorspronkelijke bron van de gegevens (dit item MOET je primaire nameserver). Dit is je primaire nameserver, en moet de enige server die je ooit update. U moet niet bijwerken de secundaire server (s) - zullen ze automatisch worden bijgewerkt op basis daarvan het SOA record. Probleem? Dit moet een volledig gekwalificeerde domeinnaam.
• RNAME ( "verantwoordelijke persoon") - Dit is een domeinnaam die duidt op de E-mail adres van de persoon die verantwoordelijk is voor deze zone. Het moet in het formaat username.domain.tld; IE "jimmy.example.com" als de E-mail adres is "jimmy@example.com". Probleem? Als dit record heeft een "@"-teken in, is het mis! (sommige programma's, zoals Sam Spade, dan kan het "@"-teken daar bij het weergeven van het - de werkelijke SOA record om zeker te zijn). Probleem? Als deze plaat niet is voorzien van een domeinnaam in het (dus alleen "hostmaster"), is het mis!. Het wordt aanbevolen [RFC1912 2,2] voor het gebruik van het formaat "hostmaster.example.com", natuurlijk ervoor te zorgen dat "hostmaster@example.com" is een geldig e-mail adres! Als het e-mailadres heeft een "." bevat, moet er een "\" voor hem (bijvoorbeeld 'scott \ \ \ \ \ \ \ \. perry.example.com "voor" scott.perry @ example.com " ). Probleem? Zorg ervoor dat er geen sprake is van "@"-teken in dit item, anders is er een fout.
• SERIAL - Dit is een serienummer (32-bit unsigned integer) die moeten worden verhoogd op de primaire naamserver wanneer een verandering wordt aangebracht. De aanbevolen [RFC1912 2-2] waarde voor deze is een 10-cijferig nummer in de vorm YYYYMMDDnn (jaar, maand, datum, herziening). Bijvoorbeeld, als u de eerste op 4 juni 2001, zou je voer 2001060401. Als u hem nog een keer die dag, je zou 2001060402. Met behulp van dit formaat (in plaats van 1, 2, 3, 4, ...) is zeer nuttig, zoals u kunt bepalen de laatste dag van het bestand is gewijzigd (dat is handig bij het bekijken van het cachegeheugen vermeldingen in andere DNS-servers). Het kan ook worden gebruikt om dubbel te controleren of u vergeten om het serienummer wanneer u voor het laatst een verandering. Probleem? Zorg ervoor dat er niet een decimale punt in het serienummer - zo ja, het zal niet werken als je denkt [RFC1912 2-2].
• REFRESH - Het aantal seconden (32-bit integer) tussen het moment dat een secundaire naam server krijgt een kopie van de zone (of ziet dat het niet is veranderd), en de volgende keer dat zij de controle om te zien of het moet een nieuw exemplaar. Dit moet worden ingesteld op de hoeveelheid tijd die je denkt dat het OK is voor uw secundaire om out-of-date informatie wanneer u uw primaire server. Een uur of twee misschien een goede waarde. Als die te kort is (zeg, 1 minuut), zal leiden tot meer verkeer. Als een te lange (zeg, 1 dag), de secundaire servers kunnen geven van oude gegevens tot een dag. Probleem? Zorg ervoor dat deze waarde niet erg hoog is, zeg een week of meer, of anders zal het een lange tijd voor uw secundaire nameservers te werken wanneer u wijzigingen aanbrengt.
• RETRY - Het aantal seconden (32-bit integer) dat de primaire naam server (s) moeten wachten, als een poging om te vernieuwen is mislukt, alvorens een nieuwe poging te vernieuwen. Als uw primaire nameserver betrouwbaar is, mag deze waarde nooit nodig.
• EXPIRE - Het aantal seconden (32-bit integer) waarmee de secundaire naam server (s) weten hoe lang ze kunnen de informatie voordat het wordt niet langer beschouwd gezaghebbend. Een goede waarde kan worden 2 tot 4 weken [RFC1912 2-2]. Het moet lang genoeg zijn om de gegevens tijdens een grote uitval. Probleem? Zorg ervoor dat de waarde groter is dan het minimum en probeer tussenpozen, anders worden de gegevens onmiddellijk te vervallen indien de secundaire server niet kunnen bereiken van de primaire server.
• MINIMUMVOORSCHRIFTEN ( "Minimum TTL") - Het aantal seconden dat de records in de zone zijn geldig voor (time-to-live, of TTL), tenzij de records hebben een hogere TTL-waarde. Dit is erg belangrijk! Ik zou aanraden om deze instelling op een dag, of minder als u uw DNS vaak (merk op dat RFC1912 2,2 suggereert ten minste 3 dagen als je DNS is redelijk stabiel). Als u zelden veranderen van uw DNS en hebben veel van het verkeer, kon je meer geld op deze enigszins te minimaliseren verkeer. Probleem? Zorg dat deze waarde niet te lang is (bijvoorbeeld een week of meer), anders wanneer u om een wijziging aan een van uw servers, dan zal dit lang voordat iedereen weet over het - en u mag niet dat veel tijd. Als u over te maken van een DNS veranderen, kunt u de waarde lager is tijdelijk, wacht de oude standaard TTL, breng je de wijzigingen op en verhogen zij weer terug.