Make the receiver a pointer so that the uptdateStubZones map update will
retain the stubzones found, unlike the current case where the update
will be applied and then promptly forgotten, because it is working on a
copy.
Add test/etcd_test.go to test a large part of the code. This didn't
catch the chaos middleware hack though. The chaos middleware zones are
now *not* automatically added. You have to take care of that by yourself
(docs updates).
When using debug queries and falling through to the next middleware in
etcd, restore the original (with o-o.debug) query before passing it on.
With this you can retreive the raw data that the etcd middleware
used to create the reply. The debug data is put in TXT records
that are stuffed in the CH classs. This is only enabled if you
specify `debug` in the etcd stanza.
You can retrieve it by prefixing your query with 'o-o.debug.'
For instance:
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @localhost -p 1053 SRV o-o.debug.production.*.skydns.local
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47798
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;o-o.debug.production.*.skydns.local. IN SRV
;; ANSWER SECTION:
production.*.skydns.local. 154 IN SRV 10 50 8080 service1.example.com.
production.*.skydns.local. 154 IN SRV 10 50 8080 service2.example.com.
;; ADDITIONAL SECTION:
skydns.local.skydns.east.production.rails.1. 154 CH TXT "service1.example.com:8080(10,0,,false)[0,]"
skydns.local.skydns.west.production.rails.2. 154 CH TXT "service2.example.com:8080(10,0,,false)[0,]"
