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,]"
Return a delegation when seeing one while traversing the tree in
search of an answer.
Put the SOA and NS record in the zone.Apex as these are to be handled
somewhat special.
Lowercase record on insert to make compares easier. This lowercases
all RR that have domain names in their rdata as well.
