Delegation woes

[ Edited ]
Posts: 1
9169     1



First post, and of course with a problem. I'm working with an Infoblox GRID and I'm trying to create a delegation for one of the zones hosted on it. Sounds easy enough, and for sure I can actually create a delegation without issue. Looking in the parent zone I see an NS record for my subzone and an A record to go with it. Except, whatever I do, I keep getting NXDOMAIN when trying to resolve the NS records for that delegation.


dig NS

; <<>> DiG 9.10.3 <<>> NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55465
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;                IN      NS

;; Query time: 22 msec
;; WHEN: Wed Apr 26 09:26:12 West-Europa (zomertijd) 2017
;; MSG SIZE  rcvd: 51


What I'd expect is the NS records returned for the delegation I just made.


I don't quite understand what is going on here, as far as I can tell it should simply work. I'm not in any way, shape or form new to DNS, but I haven't done much with Infoblox. Maybe there's some special trick to this I haven't found yet? Sofar this has taken way more time than it should've for a simple delegation Smiley Sad


For now I solved this with a forward, which does work, but a delegation should work too, darn it!


I know it's a lot to ask, but does anyone have an easy to follow step-by-step guide to creating a delegation in Infoblox which does not involve me digging through the 1400 page NIOS admin guide?

Re: Delegation woes

[ Edited ]
Posts: 81
9169     1

Hi FOTempel,


Once you has recursion enabled (that's why your forward zone works) in the member who provides the delegation for other name servers inside the delegation zone, Infoblox will try to resolve by itself any query for the delegated zone in the delegated server. The NXDOMAIN is in fact a reply from the delegated server from a forwarded query of Infoblox. In this case, I recommend you to check the delegated server configuration. 


If you do not enable recursion, Infoblox will reply any query with the NS records for the delegated zone (the same records that are visible in the parent zone).


Delegated zones do not need any special parameters to be used.


Hope this helps.

Paulo Costa

Re: Delegation woes

Posts: 356
9169     1

To add to this, you can force the NS records for a delegation to be returned by turning recursion off in your query. With nslookup, enter "set norecurse" prior to running the query. With dig, use the flag "+norecurse" at the end of your query.

Re: Delegation woes

Posts: 69
9169     1

To add to the previous answers, if you have global forwarders configured, the queries may be going to the forwarders instead of the delegated nameservers. To ensure that the queries are sent to the delegated name servers, edit the parent zone, and under "Settings" check the box "Do not use forwarders to resolve queries for subzones".



Re: Delegation woes

Posts: 39
9170     1

I'm facing the same issue.


We've got two grids.

On one I've got configured as authoritive with 'Don't use forwarders to resolve queries in subzones' enabled. In that zone there is a delegation for with the other grids servers as the delegated name servers.

On the other grid I've configured as a forward zone to the first grid and the as authoritive.


When I try a lookup on the first grid's servers I get a 'SERVFAIL'.

On the second grid I do get a resolution.


Is there something I did wrong to get a resolution from the first grid's servers?


Re: Delegation woes

Posts: 157
9170     1

Hello There,



Let me put this across to you with an example :



  • Server A : Authoritative for (With ‘Don't use forwarders to resolve queries in subzones’ enabled).


  • Server A : Has a delegated zone ‘’ delegated to Server B.


  • Server B (Different grid): Has a forward zone pointing Server A.


  • Server B (Different grid): Authoritative for



I’m not sure which query seems to be failing when pointed towards Server A. Is that the queries to the delegated zone( which seems to be failing ? or are you talking about the queries to the authoritative zone( – I guess not) ?



In case if the queries to the delegated zone pointed to Server A is failing, please check the following :



  • Server A should be able to resolve the name of the delegated server (Server B).


  • This is something which you’ve checked, but to be sure, ‘Don't use forwarders to resolve queries in subzones’ should be enabled under the ‘settings’ for’ on Server A.


  • Try performing a query from the CLI of server A pointing server B for the failing query falling into the delegated zone & see if it is able to resolve(It should be able to). By default, this query(The one which you are issuing from the CLI) would be initiated from the LAN1 interface of server A. So in case if the ‘Outgoing query source’ configured for server A is something different from LAN1, please use the ‘-b’ extension to specific that specific interface, while doing this ‘dig’.



I think the best way to go with would be to start simultaneous traffic captures on both the Server A/Server B to confirm :



  • Server A is forwarding the query falling into the delegated zone to Server B as expected.


  • Server B is responding to this query with the expected answer.



If you see anything wrong in flow specified above, then your configuration needs to be reviewed & you may need to engage Infoblox Support on this.



I hope this helps you someway. Please feel free to let us know if you have any questions.



Best regards,

Mohammed Alman.



Re: Delegation woes

[ Edited ]
Posts: 39
9170     1
  • Server A should be able to resolve the name of the delegated server (Server B).


That was my culprit. A typo in the name cause server A unable to resolve server B's name.

I thought it wouldn't matter as the IP was configured together with the name.


Thanks for the lesson.

Your step by step delegation instructions was the best I've encountered.

Showing results for 
Search instead for 
Did you mean: 

Recommended for You