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. 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. 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. 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. What if keys that are listed in "mandatory" do not appear in the RR. What if there is a DNSSEC signature alongside the SVCB or HTTPS RR? Should normalization be applied to the rdata then? What if the SVCB and/or HTTPS is not parsed by an authoritative, but received via AXFR or IXFR? Or dynamic updates? 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
