Commit graph

3 commits

Author SHA1 Message Date
Miek Gieben
d8714e64e4 Remove the word middleware (#1067)
* Rename middleware to plugin

first pass; mostly used 'sed', few spots where I manually changed
text.

This still builds a coredns binary.

* fmt error

* Rename AddMiddleware to AddPlugin

* Readd AddMiddleware to remain backwards compat
2017-09-14 09:36:06 +01:00
Miek Gieben
02955d7594 Dns.join (#944)
* Add dnsutil.Join

* Create dnsutil.Join

Create Join helper function and move bits in the code over.
2017-08-19 15:22:09 +01:00
Eric Yan
d2268d3030 middleware/file: add DNAME support (#651)
* Test DNAME handling

If the DNAME itself matches the QTYPE, and the owner name matches QNAME,
the relevant DNAME RR should be included in the answer section.

Other parts of RFC 6672 are not implemented yet and hence left untested.

* Implement the DNAME substitution

As specified in RFC 6672, a DNAME substitution is performed by replacing
the suffix labels of the name being sought matching the owner name of
the DNAME resource record with the string of labels in the RDATA field.
The matching labels end with the root label in all cases. Only whole
labels are replaced.

* Handle DNAME redirection

A CNAME RR is created on-the-fly for the DNAME redirection. Be aware
that we do not have all the edge cases covered yet.

* Test DNAME owner name matching the QNAME

A DNAME RR redirects DNS names subordinate to its owner name; the owner
name of a DNAME is NOT redirected itself.

* Ignore names next to and below a DNAME record

According to RFC 6672, resource records MUST NOT exist at any subdomain
of the owner of a DNAME RR. When loading a zone, those names below the
DNAME RR will be quietly ignored.

* Streamline DNAME processing

Instead of checking DNAMEs during lookup, we use a preloaded list of
DNAME RRs to streamline the process without any runtime performance
penalty:

 * When loading the zone, keep a record of any DNAME RRs.
 * If there aren't any DNAMEs in the zone, just do the lookup as usual.
 * Only when the zone has one or more DNAME records, we look for the
   matching DNAME and ignore confronting subdomain(s) in the process.

* Make it easier to trace back through test errors

* Make DNAME handling part of lookup routine

DNAME processing is invoked only if the zone has at least one DNAME RR.

* Put DNAME resolution inside the searching of a hit

We can drop some of the other ideas; we don't need to track if we
have DNAMEs in the zone it just follows naturally from the current
lookup code.

See also: #664
2017-05-26 10:37:06 +01:00