Hi Tuomo and David, On Fri, Jul 07, 2023 at 12:31:50PM +0200, David Vasek wrote: > Yes, it is likely that the missing unique-id's are the only problem. I was > able to reproduce the issue with that setup - I'm quite surprised that such > a faulty catalog zone actually worked with 3.0.5. > > So, Daniel, try adding the unique-id's first.
Yeah that did it. Not sure how I missed that, I was read over that bit in the docs like three times :) When I set this up I was probably just too lazy to assign IDs and was happy when it worked without. On 2023-07-07 12:20, Tuomo Soini wrote: > you can select any method to generate uniqueid. We originally decided > to use uuid but after initial testing we moved to md5sum of > "domain.tld.primary.server.dns-name." so we can re-generate always same > uniqueid. Problem with uuid was we'd need to have separate database to > store uuid domain.tld. combinations. you could use any "salt" instead > of primary.server.dns-name. but for our purposes server dns name was > unique. > > Some kind of hash of domain is not enough in case you need to handle > moving domain from one system to another where catalog interpreter can > be secondary server for multiple different primary servers. I write the catalog zone by hand so hashing or whatnot is a big hassle, for now I'll just go with a-z then. AFAIU this shouldn't be a problem since I don't do dnssec signing and don't care if zone state is purged in the future. Thanks, --Daniel --
