DNAME support
Closes: #234 (closed)
High-level contents of the MR (in order of request resolution):
iterator
It follows CNAMEs as usual. Here we rely on the fact that servers MUST also include the generated CNAMEs along with DNAMEs.
In the CNAME-following loop it newly needs to also discover (applicable) DNAMEs to:
- select them (and their RRSIGs) into
answ_selected, so they can be validated and included in answer; and to - recognize which CNAMEs are generated (mark for use in caching).
It might be surprising that CNAMEs get followed and resolved before they get validated; that's unchanged (not as "easy" to do).
validator
CNAMEs without RRSIGs may be generated from a DNAME, so the new task is to validate them that way. As CNAME may appear before its DNAME, we may fall back to two passes through the list to validate. (Validator never touched RRsets that were already ranked as secure.)
cache
Generated CNAMEs can't be saved into cache, so we use the flag set by iterator. It would be useless to save them, as they can be generated from their DNAMEs. The problem was that for efficiency reasons, the first checks are for exact-name matches with same type or CNAME type, so the generated CNAME was discovered first and used in reply without its DNAME.
New function answer_dname_hit() is added that includes generation
of the CNAME.
A tweak in order of checking was needed when searching for best-match answer. On each name, zone cut existence was checked before DNAME, so that apex DNAMEs would often not be considered.
Merge request reports
Activity
added bug label
added 1 commit
- e88f2183 - WIP: DNAME support - avoid caching occluded CNAMEs
Eh, the validation success still depends on CNAME not occurring before its DNAME, which seems not required by the RFC and 9.9.9.9 even reorders records this way (sometimes). I'll have a look at it.
Edited by Vladimír Čunátadded 1 commit
- c411f5ae - WIP: DNAME support - fix if CNAME occurs after DNAME
changed milestone to %5.1.0
-
High-level contents of the MR (in order of request resolution):
iterator
It follows CNAMEs as usual. Here we rely on the fact that servers MUST also include the generated CNAMEs along with DNAMEs.
In the CNAME-following loop it newly needs to also discover (applicable) DNAMEs to:
- select them (and their RRSIGs) into
answ_selected, so they can be validated and included in answer; and to - recognize which CNAMEs are generated (mark for use in caching).
It might be surprising that CNAMEs get followed and resolved before they get validated; that's unchanged (not as "easy" to do).
validator
CNAMEs without RRSIGs may be generated from a DNAME, so the new task is to validate them that way. As CNAME may appear before its DNAME, we may fall back to two passes through the list to validate. (Validator never touched RRsets that were already ranked as secure.)
cache
Generated CNAMEs can't be saved into cache, so we use the flag set by iterator. It would be useless to save them, as they can be generated from their DNAMEs. The problem was that for efficiency reasons, the first checks are for exact-name matches with same type or CNAME type, so the generated CNAME was discovered first and used in reply without its DNAME.
New function
answer_dname_hit()is added that includes generation of the CNAME.A tweak in order of checking was needed when searching for best-match answer. On each name, zone cut existence was checked before DNAME, so that apex DNAMEs would often not be considered.
- select them (and their RRSIGs) into
Seemingly working Deckard test for unsigned case: iter_dname_insec.rpl
It fails in weird situation where auth sends two DNAME RRs for the same owner in the same answer and the test expects SERVFAIL but gets both records and NOERROR. I'm a bit worried that this could cause problems down the road. What do you think?
