Unanswered questions

Hi,i have a problem with my bind server. (Full disclosure, it’s not with my BDDS installation but a non-bluecat named server).When i try to resolve www.semigator.de thouth this server, it works fine. But  after some time, it stops working. It’s not a general Problem, other stuff is still possible to resolve. If i flush the cache, it instanstly works again. I have a suspiction why that is, but i wanted to check with someone. My setup is the following: I run the official docker hub image from isc (https://hub.docker.com/r/internetsystemsconsortium/bind) in v9.20. It runs on an RHEL 9.7 with docker-ce.x86_64 3:29.1.2-1.el9. The container runs it’s networking in host mode (so it attaches directly to port 53 of the OS).Important, i do not have any IPv6 IPs. Thus i overrule the entrypoint with the -4 Option:/usr/sbin/named -f -c /etc/bind/named.conf -u bind -4 When i inspect the cache after first resolving, the nameservers each have two IPs, an v4 and one v6. The v4 has a TTL of 3600, and th

In certain contexts e.g. Azure Authoritative DNS Resource,  there is no granularity at the RR level.So given a larger institution have multiple groups using the same Azure Tenant,  there is no way to limi who can view/change/add RRs.  I.e. using the Azure Dashboard, which has a nice GUI where one can view RRs,  all users can see all the records. Question: Does RBAC help us solve the  problem, Given we have a one to one representation of our data in Integrity?Answer: To the best of my knowledge, No.A View combined with RBAC does not allow granularity down to the RR level.So do others have any solutions to this “problem”. I’ve used artificial subdomain names to branch out the ownership of different groups. E.g. in the case of Azure Resource Domain Names:privatelink.openai.azure.com.345 --→ Engineering Groupprivatelink.mysql.database.azure.com.1123 -→ Web Development and OperationsOne can also put the artificial group names at the other end of the FQDN and use more readable tokens:eng.pri

I’m curious if anyone can speak to what the limiting factors are on BAM’s ability to process notifications?  We’ve experienced some occurrences where it looks like the notification processing has hit a SQL block for a period of time, causing PNA file backlogs on the BAM.  Once the block clears, it takes BAM a certain amount of time to catch back up.  Observing the appliance while it does so, it seems a single postmaster process CPU-bound against a single thread - so depending on the size of the backlog it can take quite a bit of time to catch up, even though the BAM overall is 98% idle.This notification processing is really the only performance-related concern I currently have for our BAMs - and it would be awesome if  notification processing could be improved in such a way as to better consume the available hardware resources.