Note on topological-sort of CNAMEs
This commit is contained in:
parent
42280b8d91
commit
d33e251dd7
|
@ -179,7 +179,15 @@
|
||||||
;; rr-set->list : SetOf<RR> -> ListOf<RR>
|
;; rr-set->list : SetOf<RR> -> ListOf<RR>
|
||||||
;; Like set->list, but places all CNAME records first.
|
;; Like set->list, but places all CNAME records first.
|
||||||
;; This is apparently to work around bugs in old versions of BIND?
|
;; This is apparently to work around bugs in old versions of BIND?
|
||||||
|
;;
|
||||||
;; TODO: Perhaps the CNAMEs even need to be in topologically-sorted order?
|
;; TODO: Perhaps the CNAMEs even need to be in topologically-sorted order?
|
||||||
|
;; http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dns-response-taxonomy.html
|
||||||
|
;; has this to say on this topic:
|
||||||
|
;; "A content DNS server following the algorithm in § 4.3.2 of RFC
|
||||||
|
;; 1034 will insert this chain in first-to-last order in the
|
||||||
|
;; response. The response parsing code in most resolving proxy DNS
|
||||||
|
;; servers and DNS client libraries expects this order. However,
|
||||||
|
;; the actual text of RFC 1034 itself does not guarantee it."
|
||||||
(define (rr-set->list rrs)
|
(define (rr-set->list rrs)
|
||||||
(append (set->list (filter-by-type rrs 'cname))
|
(append (set->list (filter-by-type rrs 'cname))
|
||||||
(set->list (set-filter (lambda (rr) (not (eqv? (rr-type rr) 'cname))) rrs))))
|
(set->list (set-filter (lambda (rr) (not (eqv? (rr-type rr) 'cname))) rrs))))
|
||||||
|
|
Loading…
Reference in New Issue