Forum Replies Created
Did u try to enter with a backspace + ?
Also, u can try to use an LDAP browser (ex: Apache LDAp browser) to edit the record manually or if you have some LDAP knoledge u can try to edit the record on ldap from command line.
Yes I had tried escaping the character but didn’t have success. I’m happy with my alternative config for now – it’s easily editable without unnecessary complexities.
Longer term I’ll replace the master with something more….linux
So…come morning the stale record that wouldn’t go away seems to be gone. Still unclear on why it persisted so long after the whole zone was replaced but at least the zone is intact and the TXT values are sane.
Solution: Don’t use ZS as master DNS
Not a great solution, but a solution. Still interested in any light that can be shed on this behaviour – the + character being stripped – I presume that’s the web interface getting in the way, the stale record persisting in responses from slave long after replaced and the services restarted, and there’s much higher zone transfer latency now. Previously I never saw serials out of sync at the slaves, now it seems to be a norm when I make a zone alteration.
Replacement master is an MS DNS
I’ve replaced the master DNS and retired zeroshell as master. The zeroshell slaves _seem_ to be traferring the zone sanely and the missing + character is present using an alternative master DNS
I am getting some unexpected latency however – one of the two slaves is persistently returning the old incorrect record despite the zone having transferred OK and appearing correct when selecting “show” in the slave zone config.
Leaving it till morning. Uncertain why it would be returning what is now a stale record that doesn’t actually exist in the zone anymore.
Have tried restarting slave DNS services and restarting the slave zeroshell instance. Will advise if this second issue (stale record returned) is still present in the morning. (1:00AM here)
Since I can’t see a way to get zeroshell to behave itself with regards this TXT record, I am considering retiring zeroshell for the master DNS. Then if the slaves which are also zeroshell then continue to corrupt the record when replicating from an alternative master I’ll have to completely retire zeroshell from my infrastructure altogether.
I’ve not used these types of cryptographic TXT record keys before hence problem not spotted until I went to use one.
Does anyone have some workaround suggestions? Is replacing my master DNS with something that behaves sanely and retaining zeroshell slaves even viable?