Zone transfer of primary zone throws error with DNSPython due to nameserver domain

[PseudoResonance]

I have 2 Technitium instances, one has my primary zone example.com, and my other has secondary zone example.com. My primary has a NS record @ pointing to dns2.internal, with a glue address 10.0.0.10 The zone transfer/notify is setup to allow transfers/notify to listed NS records, and it works as expected, with all records from primary being propagated to secondary immediately.

Now I am using DNSPython to interact with the Technitium servers and am attempting to do a zone transfer to get the records. It works as expected for the first few records, but then I get an error name parameter must be a subdomain of the zone origin. Looking into it, it seems that in my zone transfer for example.com, Technitium is returning the record dns2.internal due to the NS record, but because dns2.internal is not a valid subdomain of example.com, DNSPython throws the error. I haven't had this issue with another name transfer program I am using, external-dns for Kubernetes though.

Is this out of spec on Technitium's side? I can't seem to find if it's normal for a zone transfer to include a non subdomain like that. Or is DNSPython being overly strict when it shouldn't be, and I should figure out how to get the issue resolved on that end?

Sorry if this is confusing. Thanks!

Edit: I temporarily disabled the NS record and manually added the DNS server IPs to the zone transfer/notify IP allow lists, and now it all works as expected and DNSPython can process the zone transfer. However it was nice being able to just use a single NS record to keep it more organized.

[ShreyasZare]

Thanks for asking. Its not recommended to set glue records for your zone's NS records. The glue records are required only when you are delegating a subdomain name to another name server. A glue record is sent as an A record in zone transfer which is why the DNSPython is giving you that error.

The proper way to do is to have a "internal" zone with A record for "dns2". The other way is how you configured the zone transfer and notify settings in Zone Options.

[ShreyasZare]

Yes, you have issue with SOA record values here. You have set refresh and retry values to 0 so its going to constantly try to refresh the zone. Update the refresh, retry, and minimum values to something practical and it will fix the issue. Note that these values are in seconds so setting refresh to 300 will mean that the zone will try to refresh every 5 mins.

[PseudoResonance]

OH! I don't know how I missed that, or why it was even set to that in the first place... Maybe I misread something, I don't know... Thank you! 3 requests per second is a lot better than 5000!

[ShreyasZare]

You're welcome. Settings a low value like 3 sec is not recommended at all since its unnecessary. Whenever primary zone is updated, it sends a NOTIFY request to secondary zones automatically. These SOA values are used as a backup just in case the NOTIFY failed or there was some network issue when trying to sync the zone.

[PseudoResonance]

I see. I'm guessing that maybe when I was having trouble with that, I tried setting it to 0 for a bit just to see, then promptly forgot about it. I just set it back to the defaults, of 900, 300, 604800, 900. Thank you very much for all the help! While I can't say the web API is particularly easy to use (all the different query parameters...) I've been really happy with Technitium since I set it up about a month ago. Plus with the standard zone transfer/dynamic updates, I can easily interface with any DNS server, which has been fantastic. Thanks for all your work!

[ShreyasZare]

You're welcome. Thanks for the compliments.