Onderwerp: Bind9 -> "expected a TSIG or SIG(0)"

Ben nu reeds 2 dagen m'm hooft aan het breken over het volgende;

Code:

rndc retransfer <zone>.nl

Log-message;

Code:

zone <domain>.nl/IN: refresh: failure trying master ***.***.***.*** #53 (source 0.0.0.0#0): expected a TSIG or SIG(0)

Reeds meerdere malen een

Code:

/usr/sbin/ntpdate nl.pool.ntp.org

op beide servers gedaan, maar dat blijkt het niet te zijn. (dit doet ie overerigens elk uur)
een

Code:

dig @dns01.<domain>.nl <zone>.nl AXFR -y dns01-dns02.<domain>.nl.:<Secret key>

doet een zone transfer maar waarschuwt me meestal met :

Code:

;; WARNING -- TSIG key was not used.

Het rare vindt ik dat het (heel ) soms wel werkt, maar meestal niet.
Ik begin eraan te twijfelen of het wel verstandig is "ntpdate" te gebruiken met een pool inplaats van gewoon een adres.

Als iemand mij kan vertellen wat dit voor probleem is, en indien mogelijk oplossen, graag
Ook zou ik graag willen weten,

Code:

zone <domain>.nl/IN: refresh: failure trying master ***.***.***.*** #53 (source 0.0.0.0#0): expected a TSIG or SIG(0)

nou verwachte de master een TSIG, of de slave(source 0.0.0.0#0)?
Zou mij al een hoop duidelijkheid verschaffen, alhoewel beide config naar mijn idee helemaal correct zijn.

ok mochten jullie meer willen weten, laat het even weten.
Tnx.

wat is de bedoeling van de ntp in dit verhaal, de zones hebben immers een eigen timestamp ding en als je die handmatig eenmalig op een absurde tijd zet zal de transfer daardoor getriggerd worden. Met daarna dus een normale tijd in de zones.

Uhm, TSIG gebruikt de huidige timestamp om zijn key the hashen.
Als de tijd tussen server en slave niet exact gelijk is krijg je errors.

wel, zorg er dan zeker voor met een ntp-server dat je klokken 1) dezelfde host gebruiken voor time-syncronisatie, en 2) niet elk uur, maar altijd de klokken bijsturen.

Voor debian is het pakket dat je zoekt "ntp-server". Een goeie klok is bvb time.belnet.be.

Oorspronkelijk geplaatst door ikkuh

Uhm, TSIG gebruikt de huidige timestamp om zijn key the hashen.
Als de tijd tussen server en slave niet exact gelijk is krijg je errors.

ah ok, weer wat geleerd

waarom wil TS dan TSIG gebruiken en niet 'gewoon' de zonetransfer doen ?

Mmmm, jammer had gehoop me wat bandbreedte te besparen.
Zal indd dan maar 2 nfs servers insttalleren.
Bedankt voor de tips.

@nzyme
TSIG beschempt mij tegen unautorized zone-transfers en "dns-fishing"
Ik weet zeker dat de slave die de transfer aanvraagt werkelijk de slave is die hiervoor is geauthoriseert (de sleutel bezit)
Voor de Master geld het zelfde, de slave weet zeker dat de master die de request beantwoord, werkelijk de master is die hij beweerd te zijn.