Reply

Delegation woes

[ Edited ]
FOTempel
Techie
Posts: 1
1346     1

Hello!

 

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 delegation.example.com NS

; <<>> DiG 9.10.3 <<>> delegation.example.com 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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;delegation.example.com.                IN      NS

;; Query time: 22 msec
;; SERVER: 172.30.7.1#53(172.30.7.1)
;; 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 ]
Expert
Posts: 81
1346     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

Adviser
Posts: 217
1346     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

Adviser
Posts: 62
1346     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

Authority
Posts: 36
1346     1

I'm facing the same issue.

 

We've got two grids.

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

On the other grid I've configured 192.168.0.0/24 as a forward zone to the first grid and the 192.168.0.128/25 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

Adviser
Posts: 70
1346     1

Hello There,

 

 

Let me put this across to you with an example :

 

 

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

 

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

 

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

 

  • Server B (Different grid): Authoritative for 192.168.0.128/25.

 

 

I’m not sure which query seems to be failing when pointed towards Server A. Is that the queries to the delegated zone(192.168.0.128/25) which seems to be failing ? or are you talking about the queries to the authoritative zone(10.192.0.0/24 – 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 192.168.0.0/24’ 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.

 

 

Highlighted

Re: Delegation woes

[ Edited ]
Authority
Posts: 36
1346     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 
Do you mean 

Recommended for You