zonemaster-engine icon indicating copy to clipboard operation
zonemaster-engine copied to clipboard

Add DNAME support (to Zone objects)

Open tgreenx opened this issue 1 year ago • 3 comments

Purpose

This PR proposes an implementation for the support of DNAME by adding a new attribute to Zonemaster::Engine::Zone objects, instead of modifying Zonemaster::Engine::Recursor.

This means that this PR does not make recursive lookups of Zonemaster follow DNAME records (similar to #1288 for CNAME), but that querying zone data (e.g glue, name servers, etc) for any name (zone) that is an alias (DNAME) will return the proper data for that zone.

TBD:

  • [ ] Discuss this implementation.
  • [ ] Add and update unitary tests, and re-record unit test data

Context

Relates to https://github.com/zonemaster/zonemaster/issues/1075 and https://github.com/zonemaster/zonemaster/issues/472

Depends on https://github.com/zonemaster/zonemaster-ldns/pull/170

Changes

  • Add new attribute 'dname' to Zonemaster::Engine::Zone objects
  • Update implementation to account for that new attribute and make queries to the appropriate zone name, if any

How to test this PR

Unit tests are to be created. So far many existing unit tests will fail because of incomplete unit test data (I haven't re-recorded them yet).

Manual testing (zone: xn--mori-qsa.nz):

$ perl -MZonemaster::Engine -E 'my $zone = Zonemaster::Engine::Zone->new({ name => Zonemaster::Engine::DNSName->from_string("xn--mori-qsa.nz") }); say "zone: ", $zone->name; $zone->dname ? say "dname: ", $zone->dname->name : say "dname: undef"; say "ns:\n\t", join "\n\t", @{$zone->ns} if $zone->dname;'
zone: xn--mori-qsa.nz
dname: maori.nz
ns:
        ns1.dns.net.nz/2001:dce:2000:2::130
        ns1.dns.net.nz/202.46.190.130
        ns2.dns.net.nz/2001:dce:7000:2::130
        ns2.dns.net.nz/202.46.187.130
        ns3.dns.net.nz/2001:dce:d453::53
        ns3.dns.net.nz/202.46.188.130
        ns4.dns.net.nz/2001:dce:d454::53
        ns4.dns.net.nz/202.46.189.130
        ns5.dns.net.nz/185.159.197.130
        ns5.dns.net.nz/2620:10a:80aa::130
        ns6.dns.net.nz/185.159.198.130
        ns6.dns.net.nz/2620:10a:80ab::130
        ns7.dns.net.nz/194.146.106.54
        ns7.dns.net.nz/2001:67c:1010:13::53

tgreenx avatar Apr 05 '23 14:04 tgreenx

I am not convinced that advanced support of DNAME is needed. It is at least not for BASIC01.

matsduf avatar Apr 06 '23 15:04 matsduf

As conluded in https://github.com/zonemaster/zonemaster-engine/pull/1212#issuecomment-1501126691 BASIC01 does not require advanced DNAME function.

If a DNAME record is present in example.com (with target.xa as target) then that will not be seen in queries for records in example.com (unless DNAME is the query type). Queries for sub.example.com (or next.sub.example.com) will result in the DNAME record plus a synthesized CNAME record being included. The CNAME record for our exampel will be sub.example.com. CNAME sub.target.xa. (next.sub.example.com. CNAME next.sub.target.xa.).

Besides the delegation issue handled by BASIC01, Zonemaster can meet synthesized CNAME records for host names (right side) of MX or NS or the SOA MNAME. In those cases Zonemaster can ignore the DNAME and just follow the CNAME until we have a test case that should validate those.

Just as with normal CNAME, DNAME can create a loop. DNAME loop can be handles as a CNAME loop since we get the synthesized CNAME.

The is one special "loop" of DNAME. If we have example.com. DNAME sub.example.com. then that seems to be handled differently on different name server software. If Zonemaster needs any special handling of DNAME then possibly that target of the DNAME record must not be a subdomain of owner name of the record. And such a test should then be done any time a DNAME record is included in the response. That would then be a SYSTEM message since that is not bound to a specific test case.

matsduf avatar Apr 09 '23 13:04 matsduf

Considering the above comments, this work is put on hold until next release.

tgreenx avatar Apr 13 '23 10:04 tgreenx