---
title: "InfoBlox NEOS Resolving Issue With VAST Onboard DNS"
slug: "infoblox-neos-resolving-issue-with-vast-onboard-dns"
description: "Following InfoBlox NEOS upgrade to version 9.0.8, resolving to VAST’s delegated domain stopped working."
updated: 2026-10-27T19:37:32Z
published: 2026-10-28T19:52:20Z
canonical: "docs.vastdata.com/infoblox-neos-resolving-issue-with-vast-onboard-dns"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# InfoBlox NEOS Resolving Issue With VAST Onboard DNS

## Info

Issue:

- The customer uses InfoBlox NEOS for their internal DNS infrastructure.
- InfoBlox forwards requests to VAST’s onboard DNS (DNS delegation).
- Following InfoBlox NEOS upgrade to version 9.0.8, resolving to VAST’s delegated domain stopped working, resulting in SERVFAIL.
- Running resolving directly against VAST’s DNS worked normally.
- During the troubleshooting session with InfoBlox support, it was discovered that ECS was enabled on the DNS server, and when disabling this option, the service resumed.
- ECS is not a new feature of 9.0.8, nor is it enabled by the customer as part of the upgrade.

## Analysis

The VAST onboard DNS doesn’t support the ECS functionality but responds correctly to queries containing the ECS OPT. The +subnet arg for the dig command adds the ECS OPT to the DNS request, but the answer from VAST DNS is still correct.

```plaintext
vastdata@v3115lg1:/home/vastdata $ dig @10.141.199.115 vippool-1.vast3115-var.VastENG.lab +subnet=1.1.1.0/24
; <<>> DiG 9.16.23-RH <<>> @10.141.199.115 vippool-1.vast3115-var.VastENG.lab +subnet=1.1.1.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37277
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;vippool-1.vast3115-var.VastENG.lab. IN	A
;; ANSWER SECTION:
vippool-1.vast3115-var.VastENG.lab. 0 IN A	172.27.115.12
;; Query time: 0 msec
;; SERVER: 10.141.199.115#53(10.141.199.115)
;; WHEN: Wed Mar 04 08:02:39 UTC 2026
;; MSG SIZE  rcvd: 68 
vastdata@v3115lg1:/home/vastdata $ sudo tcpdump -vvv -i any host 10.141.199.115
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
08:02:39.416768 eno16895 Out IP (tos 0x0, ttl 64, id 16565, offset 0, flags [none], proto UDP (17), length 114)
    v3115lg1.48839 > 10.141.199.115.domain: [bad udp cksum 0xf4c5 -> 0x5f28!] 37277+ [1au] A? vippool-1.vast3115-var.VastENG.lab. ar: . OPT UDPsize=4096 [ECS 1.1.1.0/24/0,COOKIE 49a1fc56b65d3702] (86)
08:02:39.416967 eno16895 In  IP (tos 0x0, ttl 64, id 18737, offset 0, flags [DF], proto UDP (17), length 96)
    10.141.199.115.domain > v3115lg1.48839: [udp sum ok] 37277*- q: A? vippool-1.vast3115-var.VastENG.lab. 1/0/0 vippool-1.vast3115-var.VastENG.lab. [0s] A 172.27.115.12 (68)
```

Running a DNS request to DNS that supports ECS shows that the DNS reply contains ECS information (not in the dig reply, but in the tcpdump trace.

```plaintext
vastdata@v3115lg1:/home/vastdata $ dig @8.8.8.8 cnn.com  +subnet=1.1.1.0/24
; <<>> DiG 9.16.23-RH <<>> @8.8.8.8 cnn.com +subnet=1.1.1.0/24
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49239
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 1.1.1.0/24/0
;; QUESTION SECTION:
;cnn.com.			IN	A
;; ANSWER SECTION:
cnn.com.		15	IN	A	151.101.131.5
cnn.com.		15	IN	A	151.101.67.5
cnn.com.		15	IN	A	151.101.3.5
cnn.com.		15	IN	A	151.101.195.5
;; Query time: 10 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Mar 04 08:07:15 UTC 2026
;; MSG SIZE  rcvd: 111
vastdata@v3115lg1:/home/vastdata $ sudo tcpdump -vvv -i any host 8.8.8.8
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
08:07:15.062737 eno16895 Out IP (tos 0x0, ttl 64, id 3122, offset 0, flags [none], proto UDP (17), length 87)
    v3115lg1.35028 > dns.google.domain: [bad udp cksum 0x32ba -> 0x84bd!] 49239+ [1au] A? cnn.com. ar: . OPT UDPsize=4096 [ECS 1.1.1.0/24/0,COOKIE cffa5cbcad10f512] (59)
08:07:15.072896 eno16895 In  IP (tos 0x0, ttl 124, id 14225, offset 0, flags [none], proto UDP (17), length 139)
    dns.google.domain > v3115lg1.35028: [udp sum ok] 49239 q: A? cnn.com. 4/0/1 cnn.com. [15s] A 151.101.131.5, cnn.com. [15s] A 151.101.67.5, cnn.com. [15s] A 151.101.3.5, cnn.com. [15s] A 151.101.195.5 ar: . OPT UDPsize=512 [ECS 1.1.1.0/24/0] (111)
```

### Summary:

**RFC 6891 + RFC 7871**

A server must ignore EDNS options it does not understand (such as ECS) and should not fail. VAST does a recursive resolver that sends ECS and should handle responses with or without ECS options; certain versions of Infoblox may not.