An application I work on utilizes DNS for important aspects of its functionality.  The other day, I wrote a quick and dirty command line application to write zone files for a static set of domains.  The app would allow a developer to double-click an .exe and set up a known set of domains in a local Bind instance for test purposes without having to know how or take any manual steps. It was a one-time-per-developer app so I didn’t put a lot of thought or time into it.

Or, at least, I didn’t mean to put a lot of time into it.  I ran the executable which wrote the zone files, restarted Bind, and ran the following command in an already opened PowerShell terminal to verify that my test domains were being served by my local Bind instance.

PS C:Bindbin> ./dig @localhost ns1.dnstest.dev.local
; <<>> DiG 9.9.4-P2 <<>> ns1.dnstest.dev.local
;; global options: +cmd
 ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45832
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
 ;; QUESTION SECTION:
;ns1.dnstest.dev.local.        IN      A
;; AUTHORITY SECTION:
dev.local.           3600    IN      SOA     dev-ad-01.dev.local. hostmaster.dev.local. 6876 900 600 86400 3600
;; Query time: 4 msec
;; SERVER: 10.0.5.2#53(10.0.5.2)
;; WHEN: Tue Feb 18 18:09:52 Central Standard Time 2014
;; MSG SIZE  rcvd: 131

status: NXDOMAIN in the answer section of the response means the DNS query failed. What gives? Now, if you are a seasoned PowerShell user, you probably already see the problem. As a PowerShell novice at best, I did not. Read more »