Correct response to NS request in case of dual delegation when one delegation returns REFUSED

[Ondřej Surý]

Hi,

> 1) client asks Bind: what is NS for "cluster"?
> 2) Bind seems to issue requests to both "storage1" and "storage2" for "NS cluster", one of which always returns "REFUSED"
> 3) Answer of Bind to client does not contain the one that was "refused".


no, I think it’s different problem.

Both storage1 and storage2 need to return the full set of NS for the cluster query
because the NS set from child zone will override the delegation from the parent.

DNS protocol works this way, when you ask for cluster.<parent> NS record:
1. Ask for cluster to the parent zone (<parent>), both NS records are returned as delegation (and cached)
2. Ask for cluster to the child zone (cluster.<parent>), single NS record is returned and it overrides the cache, so only single record is there

You can verify that by issuing these request manually using dig.

Beyond that, if you need more help, you’ll need to go into more details.

> My conclusion is that Windows DNS is an abomination. And relying on an inherently faulty behavior leads straight to hell.


I cannot confirm or deny this conclusion...

Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 18. 5. 2022, at 9:36, Marki <bind-users at lists.roth.lu> wrote:
> 
> Hello,
> 
> We are currently working with a product called Superna Eyeglass which can be used for DR purposes on Powerscale (Dell storages).
> 
> Quick background: Powerscale leverages DNS to create redundant and load-balanced frontend access. Without going into many details, Powerscale replies to DNS requests on a service IP (SSIP) indicating which node of the cluster should be used for the incoming connection. To that end, it requires you to delegate one (or more) zones to that SSIP.
> 
> Now Eyeglass (the DR product) recommends using "dual delegation" for failover purposes (there are two distinct clusters (active/passive) which are not necessarily in-sync at any given moment in time).
> 
> What they tell you to do is: Create a service name with two delegations/NS records pointing to both storages' SSIPs, the one currently not active will return REFUSED.
> 
> i.e. you have
> cluster IN NS storage1
> cluster IN NS storage2
> 
> Now they have "readiness" checks where they try to determine if that dual delegation is set up correctly.
> 
> However, Bind only seems to return one of those nameservers when asked for it. Example:
> 
> 1) client asks Bind: what is NS for "cluster"?
> 2) Bind seems to issue requests to both "storage1" and "storage2" for "NS cluster", one of which always returns "REFUSED"
> 3) Answer of Bind to client does not contain the one that was "refused".
> 
> Therefore that readiness check is not working. They claim this is normal and that they only support Windows DNS for that check.
> 
> My conclusion is that Windows DNS is an abomination. And relying on an inherently faulty behavior leads straight to hell.
> 
> Am I missing something? Is Bind behaving correctly?
> 
> Thanks,
> Marki
> 
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220518/a9fb5edb/attachment.sig>