Skip to content

DNAME support

Petr Špaček requested to merge dname-support into master

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.

Edited by Petr Špaček

Merge request reports