Ben Schwartz <bem...@google.com> wrote: > > 1. If TargetName is not in-bailiwick and is not ".", terminate the procedure. > 2. If SvcPriority is 0: > * If TargetName is ".", terminate the procedure. > * Otherwise, perform a SVCB "follow-up" query for TargetName and add all > returned records, including any records added by this procedure. > If any SVCB records were added, terminate. > 3. Perform A and AAAA follow-up queries for TargetName (or for the owner name > if > TargetName is "."), and add all returned records.
I think the actual wording you want here is "in the same zone" not "in bailiwick". The important thing you don't want is to require an auth server to go out to the network to query for address records in a delegated subdomain. The more subtle thing is happens with auth servers that host zones from many customers: they want to avoid cross-zone contamination in additional sections because a careless or malicious customer may have set up a shadow zone for a domains whose NS records point elsewhere. The "bailiwick" term should only be used when discussing whether delegations need glue or not. (See RFC 8499 and DJB's notes on gluelessness that introduced the term http://cr.yp.to/djbdns/notes.html) > If the server does not complete this procedure (e.g. due to response size > limits), it MUST remove any SOA records from the Additional section. > Recursive resolvers MAY use the presence of an SOA record in the Additional > section to enable negative caching of the follow-up queries, as in > {{?RFC2308}}. I'm not sure I understand this paragraph. Truncation is normally from the end of the additional section backwards, so it is really weird to drop records from the authority section first. SOA (start of authority) records go in the authority section not the additional section - the authority section is all about gossiping zone cuts (i.e. SOA records) and nameserver records. I don't understand how negative cacheing is relevant to a positive response for a SVCB query. The DNS doesn't allow a client to know that additional data doesn't exist when it is omitted from a response. It sucks, but that's the way it is. (This is why most SMTP software doesn't actually use the additional section in MX responses.) You could in theory put a DNSSEC proof of nonexistence in the additional section, but I don't know of any software that will make intelligent use of it. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ Southeast Iceland: Southeasterly veering southwesterly 3 to 5. Slight or moderate. Fog patches, rain at times. Moderate or good, occasionally very poor. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
