On 1/7/2020 6:01 PM, Wessels, Duane wrote:
On Jan 6, 2020, at 6:15 PM, Michael StJohns <m...@nthpermutation.com> wrote:
5) 3.1.2 - This is I believe different than how DNSSEC does it? If it's the
same, then this is fine, otherwise this protocol should be calculating the
RRSet wire representation the same as DNSSEC does it.
In my experience, duplicates are suppressed either when a zone is loaded or
when it is signed. ZONEMD matches DNSSEC.
Here's how named-checkzone behaves:
$ named-checkzone -i none -o /dev/fd/1 example.com /dev/fd/0
$ORIGIN example.com.
@ 60 SOA a b 1 2 3 4 5
@ 60 NS ns
NS 60 A 192.168.1.1
@ 60 A 127.0.0.1
@ 60 A 127.0.0.1
zone example.com/IN: loaded serial 1
example.com. 60 IN SOA a.example.com.
b.example.com. 1 2 3 4 5
example.com. 60 IN NS ns.example.com.
example.com. 60 IN A 127.0.0.1
NS.example.com. 60 IN A 192.168.1.1
OK
And in ldns_dnssec_rrs_add_rr() at
https://github.com/NLnetLabs/ldns/blob/develop/dnssec_zone.c#L46 you can see at
the end that equal RRs are silently ignored.
Can you provide a cite? Not disagreeing - just curious if its been written
down in an RFC somewhere.
RFC2181 (cited in ZONEMD) says:
Each DNS Resource Record (RR) has a label, class, type, and data. It
is meaningless for two records to ever have label, class, type and
data all equal - servers should suppress such duplicates if
encountered.
DW
And then you have RFC4034 which has
[RFC2181] specifies that an RRset is not allowed to contain duplicate
records (multiple RRs with the same owner name, class, type, and
RDATA). Therefore, if an implementation detects duplicate RRs when
putting the RRset in canonical form, it MUST treat this as a protocol
error. If the implementation chooses to handle this protocol error
in the spirit of the robustness principle (being liberal in what it
accepts), it MUST remove all but one of the duplicate RR(s) for the
purposes of calculating the canonical form of the RRset.
Which I think is the better cite. So basically, the RRSet encoding for
ZONEMD is the same RRSet encoding for DNSSEC. Which answers my question.
Thanks - Mike
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
