SRV disabled services erlauben

Bei SRV records, zum Beispiel für rfc6186 kann man einen Service als nicht-existent markieren.

Dafür muss man aber . als FQDN angeben:

_imap._tcp     SRV  0 0 0   .

das ist allerdings aktuell nicht setzbar, da die Referenzdaten ungültig sind. Kann man hierfür einen Sonderfall bauen?

added API Feature Request labels

wie wichtig ist das jetzt? oder nur nice to have?

erste gedanken:

https://www.rfc-editor.org/rfc/rfc2782:

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

der 2. abschnitt steht aber im widerspruch zur praxis, weil . keine address records hat (wenn ich das richtig gesehen habe?)

glaub, das geht bei uns in der netdb nur mit dem extref-trick... dh. in diesem fall ist der SRV-RR sogar ein singleton-type? ginge dann auch nur mit spezialrechten, also dbrt/dbnt via extref.

Ich denke das die beiden Abschnitte getrennt sind und der untere einen Sonderfall darstellen soll bei dem es keine Adresse gibt.

wie wichtig ist das jetzt? oder nur nice to have?

wir waren gerade dabei mal zu schauen, ob wir alle Records vom HaDiKo in die Netdb importieren können und aktuell scheitert es vor allem noch daran. Ist jetzt nicht so extrem akut.

gibts da evtl. eine moeglichkeit, das mit SVCB-RRs abzubilden? ich konnte zwar auf die schnelle nix finden, aber das sagt ja nix.

Nein, meines Wissens nach nicht. SVCB ist kein 1:1 Ersatz für SRV-Records, auch wenn man ähnliche Funktionen theoretisch damit abbilden kann. Selbst wenn das gewollt wäre, würde es wahrscheinlich viele Jahre dauern, bis der Support in den Anwendungen da wäre. Und dafür müssten ja erstmal alle Standards angepasst werden, wo SRV-Records verwendet werden.

Aus meiner Sicht kommen wir nicht drum herum, vollständigen Support für SRV zu haben.

gerade zufaellig entdeckt (bei der suche nach dem quote-bug in dnspython fuer SVCB-rr-data port="443"): lt. https://www.rfc-editor.org/rfc/rfc9460.pdf#name-special-handling-of-in-targ ist das auch bei SVCB-rrs vorgesehen.

warum laesst sich 'service not available' nicht durch weglassen des SRV-rr erreichen? m.e. traegt man doch nur dienste ein, die man bedienen will, aber nicht solche, die man nicht bedienen will.

Nein, das hilft so nicht. Weil im Zweifel probiert der Dienst ersteinmal den Port auf dem AAAA/A-Record. Wenn der entsprechende SRV-Record da ist, wird dieser Fallback nicht probiert.

So unschön es ist, müssen wir wohl hier eine Sonderbehandlung machen, dass jeder "." eintragen darf.

added workflowrefinement label

mit folgenden modifikationen (oder gebastel?) scheint es zu funktionieren (4.2, devel, bsp: _imap._tcp.scc.kit.test. mit unprivilegiertem user eingetragen):

• root-fqdn . wird auf namenstyp 'extern' gesetzt und bekommt einen rr des internen typs REF-FQDN
• in der permission-abfrage des target-namensraums (nur schreibrechte) wird der fqdn . festcodiert erlaubt (https://gitlab.net.scc.kit.edu/scc-net/net-suite/db-pgsql-app/-/blob/v4_2/wapi_4_2/_create_dns.pgsql?ref_type=heads#L1531)
• in dns.record.list wird der target-fqdn . festcodiert erlaubt (https://gitlab.net.scc.kit.edu/scc-net/net-suite/db-pgsql-app/-/blob/v4_2/wapi_4_2/_create_dns.pgsql?ref_type=heads#L3099)
• der betroffene DBRT meta:10000,ext:10000,0000,SRV wird fuer den basiszugriff freigegeben

seiteneffekte:

• durch die festcodierte erlaubnis, . als target-fqdn zu verwenden, koennen im prinzip auch rrs aller namensbasierten rr-typen, deren target-DBNT 'extern' ist (z.b. CNAME, ...), . als target-fqdn bekommen.
• leserechte auf . entsprechen nicht den DBRT-basisrechten. dh. . ist im lesezugriff nicht mit basisrechten sichtbar; aber rrs, die auf . zeigen, sind sichtbar.
• hoffe, dass es keine verschlechterung der sql-performance bei dns.record.list gibt.

noch als info, falls relevant: der basiszugriff bei DBRTs mit externen target-fqdn-typen ist momentan nicht durchgaengig eingestellt. wir haben aktuell (prod) nur basiszugriff bei SVCB, aber keinen basiszugriff bei CNAME, MX, NAPTR, PTR, SRV. letzterer RRT wird oben angepasst, so dass wir auf devel nun folgendes bild haben:

• mit basiszugriff: SRV, SVCB
• ohne basiszugriff: CNAME, MX, NAPTR, PTR

ich weiss jetzt nicht, ob wir das vereinheitlichen wollen oder es einfach so lassen, wie es ist.

changed milestone to %API 4.2 Release