> On 1 Nov 2021, at 21:57, libor.peltan <libor.pel...@nic.cz> wrote: > > Hi, > > I'm just not sure if this requested SHOULD->MUST change would actually have > any consequences.
The primary would refuse to load the record and it would have been corrected. The primary would refuse to accept in as part of an UPDATE message and return FORMERR. > It still doesn't say anything about what authoritative, and recursive servers > should do. > > The draft's sections about authoritative server behavior are somewhat brief, > but that may be OK. > > In general, they tend to expect that the authoritative server passes through > any SVCB/HTTPS records without too much verification. Just check syntax in > order to be able to translate zonefile <--> wire format. If priority == 0 && service params != empty then reject the zone. This is what you are supposed to do on load error according to STD13. > The semantic consistency seems to be expected only between the record author > and the client, which seems to be OK. Authoritative servers have been rejecting broken records at load time since RFC 1034 and RFC 1035 where published. > Libor > > Dne 31. 10. 21 v 2:03 Mark Andrews napsal(a): >> In AliasMode, records SHOULD NOT include any SvcParams, and >> recipients MUST ignore any SvcParams that are present. >> >> >> Today we had the following record like this >> >> example.com IN HTTPS 0 . alpn=h2 ipv4hint=192.0.2.1 ipv6hint=2001:DB8: >> >> interpreting this as described leads to “0 .” which indicates >> NO SERVICE OFFERED. Rejecting this at load time would be much >> safer but the weasel wording of "SHOULD NOT” makes this difficult. >> >> Please make this MUST NOT. >> >> Mark >> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
