> On 22 Mar 2021, at 20:41, Willem Toorop <wil...@nlnetlabs.nl> wrote: > > Op 19-03-2021 om 18:03 schreef Pieter Lexis: >> Hi Willem, >> >> On 3/19/21 11:47 AM, Willem Toorop wrote: >>> That'd be nice! >> >> PR is here [1]. >> >>> Do you also have tests for peculiar/corner and failure cases? >> >> I'm a little bit unsure what you men with this :). > > Well, I am wondering how much the parser should just normalize or > produce a syntax error instead. I noticed from the 7th example in your > PR, that you automatically put the SvcParams in the correct order, so > you apply normalization there in the sense that your parser sorts the > SvcParams. So do Net::DNS and (unreleased) ldns b.t.w.
And BIND. > But what about the keys in the "mandatory" SvcParam? Should they be > sorted automatically? Or should the parser produce an error if they are > not sorted? Currently both both Net::DNS and ldns sort them for you. They MUST remain in the entered order unless the specification is changed to say to sort them. BIND preserves the order. > What if keys appear double in the "mandatory" SvcParam? Should the > parser produce an error or remove the doubles? Currently ldns removes > them, but Net::DNS produces and error. It’s an invalid record that should cause the zone load to fail It’s an invalid record when received over the wire. > What if keys that may not appear in "mandatory" (like key0 or mandatory > itself) appear in the "mandatory" SvcParam? Should they be removed > automatically or should they produce and error. It’s a syntax error or an invalid record when received over the wire. Note: key0 is mandatory. > What if keys that are listed in "mandatory" do not appear in the RR. It’s an invalid record that should be rejected by the parser or an invalid record when received over the wire. > What if there is a DNSSEC signature alongside the SVCB or HTTPS RR? > Should normalization be applied to the rdata then? Yes. The signer deals with the wire format, not the text format. > What if the SVCB and/or HTTPS is not parsed by an authoritative, but > received via AXFR or IXFR? Reject the transfer if the records are invalid. > Or dynamic updates? Return FORMERR to the updater. > Also, I love the annotated RFC3597 format that Net::DNS produces and I > think we should use that in the test-vectors! > >> The code is here[2]. >> I've also opened a PR updating our parser for the draft-03 changes for >> multiple values, that one also has some tests for the value parser[3]. >> >> Cheers, >> >> Pieter >> >> 1 - https://github.com/MikeBishop/dns-alt-svc/pull/307 >> 2 - >> https://github.com/PowerDNS/pdns/blob/3a63bb5fca1c45a6e9dee808a56ca6cbea2be0d8/pdns/test-dnsrecords_cc.cc#L209-L230 >> 3 - >> https://github.com/PowerDNS/pdns/pull/10074/files#diff-1c55ae7b2d1073637c05a035de9ef6688ecffb209e50b3bef8b3d9ea1c5a329dR308-R393 >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
