Op 22-03-2021 om 15:50 schreef Ben Schwartz:
> On Mon, Mar 22, 2021 at 5:41 AM Willem Toorop <wil...@nlnetlabs.nl
> <mailto:wil...@nlnetlabs.nl>> wrote:
> 
>     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.
> 
> 
> The draft says:
> 
>    The presentation "value" SHALL be a comma-separated list
>    (Appendix A.1) of one or more valid SvcParamKeys, either by their
>    registered name or in the unknown-key format (Section 2.1).  Keys MAY
>    appear in any order, but MUST NOT appear more than once.
> 
> and
> 
>    In wire format, the keys are represented by their numeric values in
>    network byte order, concatenated in ascending order.
> 
> Hopefully that's clear enough.

Sure, so this:

x8.example.     3600    IN      SVCB    16 foo.example.org. (
        key853="test" key123="some other text"
        ipv4hint=192.0.2.1 mandatory=ipv4hint,alpn,key853,key123
        alpn=h2,h3-19 ipv6hint=2001:db8::1.2.3.4,2001:db8::
        )

is equivalent with

x8.example.     3600    IN      SVCB    ( \# 115 0010
        03666f6f076578616d706c65036f7267 00     ; foo.example.org.
        0000 0008 00010004007b0355
        0001 0009 0268320568332d3139
        0004 0004 c0000201
        0006 0020 20010db8000000000000000001020304
                  20010db8000000000000000000000000
        ; key123=...
        007b 000f 736f6d65206f746865722074657874
        ; key853=...
        0355 0004 74657374
        )

Would be good to have that in a test vector ;).

>     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.
> 
> 
> I think authoritative servers "SHOULD" enforce the zone file
> requirements to the extent possible, but responsibility ultimately lies
> with the zone owner.

Excellent! How SHOULD it enforce? By failing to load or by fixing.
Most here tilt to *failing to load*, so these should fail to load:

; Forbidden key in mandatory
x9.example.     3600    IN      SVCB    0 . mandatory=key0
x10.example.    3600    IN      SVCB    ( \# 9 0000 00
        0000 0002 0000
        )

; Double key in mandatory
x11.example.    3600    IN      SVCB    0 . (
        ipv4hint=192.0.2.1 alpn=h2 mandatory=ipv4hint,alpn,key4
        )
x12.example.    3600    IN      SVCB    ( \# 28 0000 00
        0000 0006 000100040004
        0001 0003 026832
        0004 0004 c0000201
        )

; Key without SvcParam in mandatory
x13.example.    3600    IN      SVCB    0 . (
        ipv4hint=192.0.2.1 alpn=h2 mandatory=ipv6hint,alpn,key4
        )
x14.example.    3600    IN      SVCB    ( \# 28 0000 00
        0000 0006 000100040006
        0001 0003 026832
        0004 0004 c0000201
        )

I think it would be good to have this added to the test-vectors appendix.

Should this fail to load too?

; Wireformat has SvcParams unordered
x15.example.    3600    IN      SVCB    ( \# 26 0000 00
        0004 0004 c0000201
        0001 0003 026832
        0000 0004 00010004
        )

or am I stretching it now...

Cheers,
-- Willem

> 
>     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.
> 
> 
> The draft says:
> 
>    For self-
>    consistency (Section 2.4.3), listed keys MUST also appear in the
>    SvcParams.
> 
> and (in Section 2.4.3)
> 
>    Zone-file implementations
>    SHOULD enforce self-consistency.  Clients MUST reject any RR whose
>    recognized SvcParams are not self-consistent, and MAY reject the
>    entire RRSet.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to