MaraDNS protects herself from cache poisioning without ever discarding glue
records is by handling out-of-bailiwick records differently, depending on 
where the offending records are.

There are three situtations:

---

The way we process name server referrals with the same names in the
additional section is by ignoring the names, and storing in the cache the       
IPs of the name server(s) in question.

For example, let us suppose that www.killerporn.nasty.foo wants to poison
our cache:

$ dig @ns.nasty.foo www.killerporn.nasty.foo

;; ANSWER SECTION
; blank

;; AUTHORITY SECTION
killerporn.nasty.foo. 123456 IN NS www.google.com.
killerporn.nasty.foo. 123456 IN NS www.cnn.com.

;; ADDITIONAL SECTION
www.google.com. 123456 IN A 10.1.2.3
www.cnn.com.    123456 IN A 10.1.2.4

When MaraDNS, in recursive mode, sees these bad records, what she does is
this:

* She does not change the values for "www.google.com" nor "www.cnn.com" in
  the cache.

* She "links" the records in question, and stores this in the cache:

killerporn.nasty.foo. 123456 IN NS 10.1.2.3
killerporn.nasty.foo. 123456 IN NS 10.1.2.4

---

In the case of a NS record being out of bailiwick, MaraDNS discards the
out-of-bailiwick records.  E.G:

$ dig @ns.nasty.foo www.killerporn.nasty.foo

;; ANSWER SECTION
; blank

;; AUTHORITY SECTION
com.                  123456 IN NS ns1.killerporn.nasty.foo.
killerporn.nasty.foo. 123456 IN NS ns2.killerporn.nasty.foo.
killerporn.nasty.foo. 123456 IN NS ns3.killerporn.nasty.foo.

;; ADDITIONAL SECTION
ns1.killerporn.nasty.foo. 123456 IN A 10.1.2.1
ns2.killerporn.nasty.foo. 123456 IN A 10.1.2.2
ns3.killerporn.nasty.foo. 123456 IN A 10.1.2.3

The "com." record is discarded, and the other two records are added to the
cache.

---

In the case of an answer being an answer for something besides our
question, we discard the answer.

