SVCB support for IANA list incomplete, Workaround with keyNNNN does not work

[MikeAT]

• [X ] This is not a support question, I have read about opensource and will send support questions to the IRC channel, GitHub Discussions or the mailing list.
• [X ] I have read and understood the 'out in the open' support policy

• Program: Authoritative
• Issue type: Bug report

Short description

PDNS supports only SVCB parameter 1-6, 7-9 are not implemented (according to https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml), they should be added via keyNNNN.

When trying to add the ohttp option (ID 8), which is a flag without any parameter, PDNS-API returns

"Failed updating rrsets: Record xxxx.at./SVCB '1 example.com. key008': Parsing record content (try 'pdnsutil check-zone'): expected '=' after key008"

Maybe a more generic approach for SVCB without parsing the content might be a better solution. SVCB is extensible by design, so new options/features will be added in the future and cause problems with older PDNS versions. Adding the content and serving it "as it is" might be more future proof and does not trigger #9870 too.

This is also a documentation bug, I could not find the keyNNNN in den PDNS documentation, its is only mentioned in the DNSDIST documentation.

Environment

• Operating system: Ubuntu 24.04.1 LTS
• Software version: 4.9.2-noble
• Software source: Ubuntu-Repo

Steps to reproduce

adding an SVCB Record with the ohttp Option:

PATCH http://<server>:<port>/api/v1/servers/localhost/zones/xxxx.at

{
  "rrsets": [
    {
      "comments": [],
      "name": "xxxx.at.",
      "records": [
        {
          "content": "1 example.com. key008",
          "disabled": false
        }
      ],
      "ttl": 86400,
      "type": "SVCB",
      "changetype": "REPLACE"
    }
  ]
}

Expected behaviour

200 OK, Record in Database

Actual behaviour

API returns

422 Unprocessable Entity {"error": "Record xxxx.at./SVCB '1 example.com. key008': Parsing record content (try 'pdnsutil check-zone'): expected '=' after key008"}

Other information

[pieterlexis-tomtom]

RFC 9460 section 2.1 indeed says

When the optional "=" and SvcParamValue are omitted, the value is interpreted as empty.

Arbitrary keys can be represented using the unknown-key presentation format "keyNNNNN" where NNNNN is the numeric value of the key type without leading zeros. A SvcParam in this form SHALL be parsed as specified above, and the decoded value SHALL be used as its wire-format encoding.

I wonder if the "no leading zeroes" part has been implemented as well...... (all blame goes to me I guess)

[zeha]

I wonder if the "no leading zeroes" part has been implemented as well...... (all blame goes to me I guess)

I see code for it in svc-records.cc.

[zeha]

https://github.com/zeha/pdns/tree/svcb has some initial code for key 7-9, but is incomplete and probably broken.

Haven't looked at a generic thing yet, but I imagine whatever we do will have the same backwards compat issues like TYPExxx.

[klaus-nicat]

https://github.com/zeha/pdns/tree/svcb has some initial code for key 7-9, but is incomplete and probably broken.

Haven't looked at a generic thing yet, but I imagine whatever we do will have the same backwards compat issues like TYPExxx.

IIRC you have implented "upgrade-unknown-types" some time ago. Maybe a similar "upgrade-unknown-svcb-params" option is needed as well, that will be enabled for PDNS upgrades and can be disabled once all SVCB records were upgraded.

[zeha]

As mentioned on IRC, I'm now confused if leading zeroes should be supported (maybe for interop?), or should be rejected.

[pieterlexis-tomtom]

@zeha in my comment I link to the text of the RFC that says that leading zeroes are not allowed (although there is not MUST NOT in the text).