SVCB and HTTPS support

[pieterlexis]

Short description

PR to add SVCB and HTTPS support.

ToDo:

• Implement SvcParam class for internal representation of service parameters
• Add SVB
  • qtype.cc/hh
  • dnsrecords.cc/hh + reportOtherTypes
• Add HTTPS to QTypes and dnsrecords
  • qtype.cc/hh
  • dnsrecords.cc/hh + reportOtherTypes
• Implement Reading/Writing SvcParams (xfrSvcParamKeyVals)
  • RecordTextReader
  • RecordTextWriter
  • DNSPacketWriter
  • PacketReader
• Add pdnsutil tests for SVCB/HTTPS correctness
• Implement auth additional processing
  • Add tests for auth additional processing
• Implement rec additional processing
  • Add tests for rec additional processing

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)
• checked that this code was merged to master

[pieterlexis]

After a discussion with @Habbie, some features will be moved to a next iteration so this initial code can land in auth 4.4.0-alpha1. These features will be:

• Recursor additional processing
• CNAME processing for additional records (requires a refactor of packethandler::doQuestion)

[Habbie]

upgrading.rst notes that IPSECKEY is no longer unknown; it should note the same for SVCB and HTTPS.

[zeha]

idk, but newer records apparently stopped with the 'first char downcase' rule already, so lets not continue it? (cf EUI64Record)

[Habbie]

Per Howard Chu: don't know why people do that, probably historical. Conformity in a schema is a good thing. Also, they are case-insensitive.

Please uppercase :)

[rgacogne]

A few nits but the code looks solid. ❤️ the tests :-)

[zeha]

some initial nits.

Also: the draft suggests that svcParamKeys need to be in increasing numeric order. Is this something the code should do?

[zeha]

Also: the draft suggests that svcParamKeys need to be in increasing numeric order. Is this something the code should do?

To answer my own question: within the RR this is already done.

[zeha]

Might make sense to add an API test (didn't verify this works):

diff --git a/regression-tests.api/test_Zones.py b/regression-tests.api/test_Zones.py
index e2069d8ef..2a4c62717 100644
--- a/regression-tests.api/test_Zones.py
+++ b/regression-tests.api/test_Zones.py
@@ -1462,6 +1462,25 @@ $ORIGIN %NAME%
                                headers={'content-type': 'application/json'})
         self.assert_success(r)  # user should be able to create DNAME at APEX as per RFC 6672 section 2.3

+    def test_rr_svcb(self):
+        name, payload, zone = self.create_zone()
+        rrset = {
+            'changetype': 'replace',
+            'name': 'svcb.' + name,
+            'type': 'SOA',
+            'ttl': 3600,
+            'records': [
+                {
+                    "content": 'mandatory=alpn alpn=h2,h3 ipv4hint=192.0.2.1,192.0.2.2 echconfig="dG90YWxseSBib2d1cyBlY2hjb25maWcgdmFsdWU="',
+                    "disabled": False
+                },
+            ]
+        }
+        payload = {'rrsets': [rrset]}
+        r = self.session.patch(self.url("/api/v1/servers/localhost/zones/" + name), data=json.dumps(payload),
+                               headers={'content-type': 'application/json'})
+        self.assert_success(r)
+
     def test_rrset_ns_dname_exclude(self):
         name, payload, zone = self.create_zone()
         rrset = {