Håkan Lindqvist

"More control", but you seem a bit unfamiliar with the whole environment. As long as you are prepared to learn, I guess.

That's kind of my point. This is infrastructure that you have now chosen to run yourself, but you could choose to focus on your thing and use some existing managed service for it instead.

Not saying this to cause offense, but I do get the feeling that from a professional perspective you're in over your head and that unless this is purely for learning purposes you may want to use some managed service instead. Just my 2c.

If there are more domains that you are setting up the same way, I guess you'll want to fix all of them

Well, you were talking about revelhost.net before, and if that also has allow-transfer none, then that certainly explains why what you asked about doesn't work

(I think it was revelhost.net earlier?)

If that is the relevant zone / if the relevant zone looks the same

Yes

facepalm

systemctl restart bind9 would be the more general approach to restarting a service in modern Debian, I guess. But sending HUP ought to work for getting it to reread the config.

(Worth noting, named itself only knows to read /etc/bind/named.conf, the file Debian ships just has include directives pointing to those other files so it reads them all)

And named.conf.local and whatever

Yes...?

Sure

Eg, do you also have allow-transfer on the zone level, overriding the global configuration that you are showing in the question?

So that is one of the IPs listed by Linode, and which the small part of the named config you have shown suggests would be allowed, but for whatever reason it's actually denied. If you are sure that named has been reloaded/restarted after you made those changes, I think you'll have to show what is actually going on in that named config as a whole.

Well, there you go

Something like journalctl -ex -u bind9 maybe, unless you have specifically configured something.

But what do your named logs say?

If the question is about the zone transfers to the Linode nameservers, then it doesn't have to do with it. If it has to do with anything else, then it could possibly be relevant but then I'm not sure what the question actually is.

I would still suggest checking the logs for AXFR attempts from the Linode nameservers. They should be attempting and based on them answering queries with SERVFAIL it would appear they fail to complete the AXFR

The delegation is important in the greater picture but not actually relevant to making the zone transfer work

Correct?

It's the other way around that you are trying to get to work

That was you trying to axfr from one of the linode nameservers. Not the other way around, right?

Regarding what you did... dig axfr @162.159.25.129 revelhost.net (?), I'm not actually sure how that is relevant to anything

Ok, but I don't believe your server is supposed to be allowed (at least not with the config included in the question)?

Okay, but where from was that initiated? And was that source allowed?

Regardless if it's an error or not, anything at all regarding the expected zone transfers?

What do you see in the logs?

I doubt you need anything in "domain transfers" in the Linode zone configuration, but I guess that doesn't hurt

As in that it was already correct? Unless you mean that you just fixed something and it now works, clearly something is wrong either on your end or on their end. What about your logs, any hints as to what happens to their zone transfers?

I meant the operator of the slave servers (Linode in this case, if I understand correctly)

In the earlier version of the question where you had the dig output for a regular query we could see that you get SERVFAIL back which suggests that the zone exists but something is wrong. Quite possibly they are unable to perform the zone transfer. Can you check and double-check that you have given them the correct information about your zone (ie, correct master ip and obviously correct zone name) and check your own logs for traces of their attempted zone transfers?

That doesn't look like a representative query for the problem you were describing. Something like dig @162.159.27.72 example.com +norec, maybe?

What kind of response do you get from the slave servers if you query them directly (using eg dig)?

Good night

And do make sure that all addresses etc are consistent, because it makes little sense to try to spot the error if the actual problem statement is accidentally inconsistent for whatever reason.

I'm going to have to leave for tonight, but I would suggest that you add all the info into the question. If you are going with the forward-zones approach, do add dig output that shows the remaining problem (because it sounded like that solved the initial problem?)

In terms of DNS, what happens? Do they use 192.168.1.5? What does 192.168.1.5 answer? Etc

And what happens on those other servers?

I thought you said that after you added forward-zones=google123.com=192.0.1.7 (I guess actually 192.168.1.5 or something?) it worked when testing with dig?

And that worked?

Ok, so when you tested with dig from one of these clients it was @192.168.1.5 or what?

Afaict dnsdist is on 192.0.1.5?

Just to try to relate this back to the question, what is 192.0.1.7 in relation to the addresses mentioned in the question?

And then "But if i ping any domain, i get error ping: example.com: Name or service not known." which suggests the problem may rather be with how the stub resolver on that host is configured? (Ie, ping using the stub resolver, in contrast to how you had dig query the nameserver directly)

"After dig ANY example123.ru @192.0.1.7 at server in network 192.0.1.0/24 or at dns server dig ANY example123.ru @127.0.0.1 i ger records from Authoritative server." <--- this is what I'm referring to. That sounded like it did work?

If you go with that approach, clients would get authoritative answers for your local zones, like they did before. Not that it's clear from the question that this would matter.

If you want something that will behave more closely to pdns-auth with recursor, I think the "making dnsdist always send queries for your zones directly to pdns-auth" would be it. Not that I know if this would solve your problem, considering it's somewhat unclear what exactly the problem is when using the abovementioned changes compared to the config in the question.