Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-01.txt
> From: Tony Finch > I've had a look through and I have a few comments. Thanks. > Regarding smallest MTUs, I understand from Geoff Huston that it's common > for IPv6 breakage to start at 1281 bytes. Then, without path MTU discovery, IPv6 default path MTU value should equal to the IPv6 minimum link MTU size 1280. How about IPv4 ? > I would find it easier to understand the recommendations if the > requirements for responder and requester were separated. In particular I > don't know how a responder can do MTU discovery (though a simplified > version might be possible). Then, separate real recommendations to "3.1 Recommendations for UDP requestors" and "3.2 Recommendations for UDP responders". > Here's my understanding of your recommendations: > > Requester: > > * should have a default EDNS buffer size no more than 1500 bytes (smaller > than the 4096 that is currently typical, but bigger than the flag day > recommendation) > > * should probe to discover the real MTU per destination, which can be less > than the default, and use the discovered MTU for the EDNS buffer size in > queries (resolvers already do this) In my opinion, if path MTU discovery to works, then use the value (minus header sizes) as Requestor's Payload Size in EDNS0. Otherwise, use "good" default EDNS buffer size (for example, 1232). > * at the moment UDP timeouts don't cause fallback to TCP, but this should > be added to the list of recovery tactics > > * requesters are supposed to guess (how?) the size of response before > sending a query, so that they can skip UDP and go straight to TCP If requestors set good EDNS Requestor's Payload size, responders can set TC bit if response size exceeds the EDNS0 size. (Otherwise, fragmented responses may lose.) > * should set the DONTFRAG option, though it's unlikely they are sending > a query big enough for this to matter. (UPDATE clients need to care, > though.) > > Responder: > > * should have a default UDP response size limit of no more than 1500 bytes > (smaller than the 4096 that is currently typical, but bigger than the > flag day recommendation) To avoid packet loss caused by IP_DONTFRAG, if responders know real path MTU value, responders compose packets fit in the path MTU. Otherwise, at least, IP_DONTFRAG works well. I think that most of DNS servers are located at 1500-octets MTU area. > * should limit response sizes by based on the minimum of the request's > EDNS buffer size and the server's limit (servers already do this) If operators of DNS servers know that the network does not support 1500-octet MTU, operators should consider good UDP response size limit. > * should use minimal responses > > * should set the DONTFRAG option on responses And responders should set TC=1 (and re-compose smaller response) if sendto returned EMSGSIZE. > * should listen for ICMP frag needed packets, and react by re-sending the > response (which is embedded in the ICMP packet) with a TC bit set It is a part of path MTU discovery. > Network: > > * should send rate-limited ICMP frag needed messages to DNS servers when > appropriate I don't know. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
On 8/5/20 11:13 PM, Mark Andrews wrote:
>> On 6 Aug 2020, at 04:51, Pieter Lexis wrote:
>> On 8/5/20 8:03 PM, Brian Dickson wrote:
>>> (I am not sure of the question/issue of including the SOA, or where that
>>> would go, but I'll defer to anyone who knows or has an opinion. My gut
>>> says, do whatever gets done for CNAME.)
>>
>> The SOA MUST go in the packet. As a compliant resolver talking to an
>> auth that does not implement SVCB will follow the chain and the auth
>> will respond with NODATA (and thus the SOA).
>
> You make a SVCB query you will get a CNAME if it exists at the QNAME, SVCB
> if it exists at the QNAME or you will get NODATA if neither exists.
If you
> find a CNAME you repeat at the target of the CNAME.
>
> If the server is SVCB aware it will then process the SVCB RRset and
add those
> records to the additional section, if any of those trigger additional
section
> processing those records too get added to the additional section. This is
> consistent with STD 13 that says words to the effect of “add anything
useful” (I’m
> not going to look up the exact words). The additional section rules
for SVCB say
> to add CNAME, SVCB, A and to the additional section.
The semantic rules for the Alias form lead me to believe that an SVCB at
the targetname *is* an answer to the question (no other SVCB at that
ownername, at the very least no Service mode SVCB at that name).
The end-clients (browsers, other programs actually querying for
SVCB/HTTPS)
Looking at section 5.4.1 ("Ranking Data") of RFC 2181, a non-SVCB
recursor might accept the data in the answer section:
[…]
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
On the other hand, a non-SVCB-aware resolver might even choose to drop
both the data in the ANSWER and ADDITIONAL section that do not match the
original QNAME. Thus only serving its client the SVCB alias record in
the ANSWER section, leading to the end-client re-querying for the
targetname SVCB record.
It would be good to know what most implementations do when they
encounter in-bailiwick data with a different owner name in both the
ANSWER and ADDITIONAL sections. Then the SCVB draft can pick the right
method:
* Semantically correct (chained SVCB in ANSWER, using 'CNAME chasing')
* Backwards compatible (All related data in ADDITIONAL)
Best regards,
Pieter
--
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries
Dear Peter, Matt and Paul, What does it mean for a resolver to be primed, or for a resolver to not be primed? For example, is a resolver considered primed only if it has all root server names and IP addresses? 50%? At least 1? Priming is the act of finding the list of root servers from a configuration that lists some or all of the purported IP addresses of some or all of those root servers. A recursive resolver starts with no information about the root servers, and ends up with a list of their names and their addresses. If that were true it would be impossible for the resolver to find anything. It definitely starts with some information about the root servers. Maybe change "no information" to "this information". Thanks, Andrew On 1 Jul 2020, at 1:39, Paul Hoffman wrote: Greetings again. Since RFC 8109 has been published, there has been more discussion of what DNS priming means. This has caused the document authors to see a few places where RFC 8109 could be clarified and improved. Please see: https://datatracker.ietf.org/doc/draft-klh-dnsop-rfc8109bis/ Comments are welcome. If the WG wants to adopt this work, that would be grand as well. --Paul Hoffman___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
> On 6 Aug 2020, at 20:28, Pieter Lexis wrote:
>
> On 8/5/20 11:13 PM, Mark Andrews wrote:
>>> On 6 Aug 2020, at 04:51, Pieter Lexis wrote:
>>> On 8/5/20 8:03 PM, Brian Dickson wrote:
(I am not sure of the question/issue of including the SOA, or where that
would go, but I'll defer to anyone who knows or has an opinion. My gut
says, do whatever gets done for CNAME.)
>>>
>>> The SOA MUST go in the packet. As a compliant resolver talking to an
>>> auth that does not implement SVCB will follow the chain and the auth
>>> will respond with NODATA (and thus the SOA).
>>
>> You make a SVCB query you will get a CNAME if it exists at the QNAME, SVCB
>> if it exists at the QNAME or you will get NODATA if neither exists.
> If you
>> find a CNAME you repeat at the target of the CNAME.
>>
>> If the server is SVCB aware it will then process the SVCB RRset and
> add those
>> records to the additional section, if any of those trigger additional
> section
>> processing those records too get added to the additional section. This is
>> consistent with STD 13 that says words to the effect of “add anything
> useful” (I’m
>> not going to look up the exact words). The additional section rules
> for SVCB say
>> to add CNAME, SVCB, A and to the additional section.
>
> The semantic rules for the Alias form lead me to believe that an SVCB at
> the targetname *is* an answer to the question (no other SVCB at that
> ownername, at the very least no Service mode SVCB at that name).
SVCB is NOT A CNAME and despite it being called “ALIAS FORM” it does not
produce the equivalent of CNAME processing in the ANSWER section.
I really don’t know how this thread got started with clear and unambiguous
instructions to add all the records to the additional section.
"Cooperating DNS recursive resolvers will perform subsequent record resolution
(for SVCB, A, and records) and return them in the Additional Section of
the response. Clients either use responses included in the additional section
returned by the recursive resolver or perform necessary SVCB, A, and
record resolutions. DNS authoritative servers can attach in-bailiwick SVCB, A,
, and CNAME records in the Additional Section to responses for a SVCB
query."
Yes this means you need may need to change additional section process to chase
other records. Named was already doing this for one type and with HTTPS and
SVCB needing we made the processing general. Yes, it also means that one has
to add CNAMEs to the additional section when processing HTTPS or SVBC.
> The end-clients (browsers, other programs actually querying for
> SVCB/HTTPS)
>
> Looking at section 5.4.1 ("Ranking Data") of RFC 2181, a non-SVCB
> recursor might accept the data in the answer section:
>
> […]
> + Data from the answer section of a non-authoritative answer, and
>non-authoritative data from the answer section of authoritative
>answers,
> + Additional information from an authoritative answer,
>Data from the authority section of a non-authoritative answer,
>Additional information from non-authoritative answers.
>
> On the other hand, a non-SVCB-aware resolver might even choose to drop
> both the data in the ANSWER and ADDITIONAL section that do not match the
> original QNAME. Thus only serving its client the SVCB alias record in
> the ANSWER section, leading to the end-client re-querying for the
> targetname SVCB record.
>
> It would be good to know what most implementations do when they
> encounter in-bailiwick data with a different owner name in both the
> ANSWER and ADDITIONAL sections. Then the SCVB draft can pick the right
> method:
>
> * Semantically correct (chained SVCB in ANSWER, using 'CNAME chasing')
> * Backwards compatible (All related data in ADDITIONAL)
Named ignores anything it is not expecting. That said adding DNAME to the
answer section caused problems (answers being rejected because a DNAME was
present). Adding unexpected stuff to the ANSWER section is always fought with
problems. If a client falls over because stuff was added to the additional
section then the client is broken.
> Best regards,
>
> Pieter
>
> --
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com
--
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
Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries
On Aug 6, 2020, at 4:08 AM, Andrew McConachie wrote: > > What does it mean for a resolver to be primed, or for a resolver to not be > primed? For example, is a resolver considered primed only if it has all root > server names and IP addresses? 50%? At least 1? Excellent questions, two that the WG can certainly consider. Note that it *is* two questions, the root server names and the associated addresses. From the text you quote: > Priming is the act of finding the list of root servers from a > configuration that lists some or all of the purported IP addresses of > some or all of those root servers. A recursive resolver starts with > no information about the root servers, and ends up with a list of > their names and their addresses. RFC 8109 indicates that priming means knowing the full set of names and the full set of addresses. > If that were true it would be impossible for the resolver to find anything. > It definitely starts with some information about the root servers. Maybe > change "no information" to "this information". This distinction is important. A resolver starts with no actual information, but only meta-information: where to get the actual names and addresses for the root server. Is there a better way to say this in the -bis document? --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
On 16:55 30/07, Patrick Mevzek wrote: > > Only if you take the "hosts as objects" case (where any hosts to be used as > to be provision like a domain but by just providing, in some cases, some IP > addresses), which is only one of the two, the other being "hosts as > attributes (of a domain object)" > .CL uses "hosts as attributes". > There are various solutions, all bad in some aspects: > [...] > - have the registry let the domain be deleted and then have domainB be > broken (which it is already in a way since the delegations to those > nameservers can be explicitly made broken; but the difference is between > registrar A breaking registrar B stuff, or the registry breaking registrar B > stuff). And this approach. When DomainA is deleted/deactivated, its nameservers are gone in the .cl zone, together with their glues. Nameservers ns1.domainA.example and ns2.DomainA.example are deleted from DomainB's NS set too, because there's no DomainA anymore... and so we keep .cl consistency. So we can say .CL is truly delegation-only. But we know there're only a handful of registries using hosts-as-attributes. Hugo signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews wrote: > > > I really don’t know how this thread got started with clear and unambiguous > instructions to add all the records to the additional section. > The possibility of changing what is specified in the draft, was what started this thread. Your responses all suppose that it is not possible to change what is specified in the draft. It would be helpful (IMHO) to the conversation to give consideration to the contents of the thread, from the perspective that the specs in the draft are not absolutely set in stone and immutable. Here's the quote from Ben: I think Section 4.1 is pretty clear that everything goes in the Additional section. (But this can be changed!) > > "Cooperating DNS recursive resolvers will perform subsequent record > resolution (for SVCB, A, and records) and return them in the > Additional Section of the response. Clients either use responses included > in the additional section returned by the recursive resolver or perform > necessary SVCB, A, and record resolutions. DNS authoritative servers > can attach in-bailiwick SVCB, A, , and CNAME records in the Additional > Section to responses for a SVCB query." > > Yes this means you need may need to change additional section process to > chase other records. Named was already doing this for one type and with > HTTPS and SVCB needing we made the processing general. Yes, it also means > that one has to add CNAMEs to the additional section when processing HTTPS > or SVBC. > > We can all read, and we understand what the current draft says. That's NOT what is being discussed (how to interpret those words). What IS being discussed in this thread is whether it may be more sensible to align the process of handling the "alias" form in a manner more consistent with how CNAME processing happens. It is a proposal to change the spec itself, rather than an alternate interpretation of what the current draft of the spec says. This is why I suggested that, while it is not CNAME per se, treating it as "constrained alias applicable only to SVCB queries" isn't a huge leap, and would simplify the code for handling alias form, on both the server and client side of a lookup. If the standard says they belong in the Answer section (as I am suggesting), I think the expected BIND client-side handling of SVCB records (alias and non-alias, if in-bailiwick) and CNAME records if they are both placed in the answer section by the server should be okay, in both situations: when SVCB is "unknown" (it's a match to QTYPE), or when SVCB handling logic is added. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries
If I (insanely) ran a totally manual, out of band process to periodically canvas the space and injected the knowns into the model of "root" for my resolver, would I be able to say I am primed? I am trying to get to the point that the "how" part is only exemplary, explanatory. The requirement is that you have the information, now how you get it or how it comes into your resolver. The distinction between shipped states of the root.hints and the actual live mappings of the domain labels inherent in it, to addresses (if you like) I can bypass the hints file ,and use SQL to update my root mapping. I think the intent of "priming" is that you then populate the information from 'inside' DNS. But, again, its only advisory, its not standards enforced is it? I can populate my continuing knowledge of the state of the DNS at the root, or anywhere else, in any mechanism I like. I could periodically FTP the zone files from places, and populate my resolver cache state from these. I could basically "never" forward DNS queries high in the tree, if I felt like making my server do that. Am I "not primed" if I do this? (this mechanism wouldn't support authenticated denial of arbitrary labels, as an example) -G On Fri, Aug 7, 2020 at 12:42 AM Paul Hoffman wrote: > > On Aug 6, 2020, at 4:08 AM, Andrew McConachie wrote: > > > > What does it mean for a resolver to be primed, or for a resolver to not be > > primed? For example, is a resolver considered primed only if it has all > > root server names and IP addresses? 50%? At least 1? > > Excellent questions, two that the WG can certainly consider. Note that it > *is* two questions, the root server names and the associated addresses. > > From the text you quote: > > > Priming is the act of finding the list of root servers from a > > configuration that lists some or all of the purported IP addresses of > > some or all of those root servers. A recursive resolver starts with > > no information about the root servers, and ends up with a list of > > their names and their addresses. > > RFC 8109 indicates that priming means knowing the full set of names and the > full set of addresses. > > > If that were true it would be impossible for the resolver to find anything. > > It definitely starts with some information about the root servers. Maybe > > change "no information" to "this information". > > This distinction is important. A resolver starts with no actual information, > but only meta-information: where to get the actual names and addresses for > the root server. Is there a better way to say this in the -bis document? > > --Paul Hoffman___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
> On 7 Aug 2020, at 04:03, Brian Dickson wrote: > > > > On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews wrote: > > > I really don’t know how this thread got started with clear and unambiguous > instructions to add all the records to the additional section. > > The possibility of changing what is specified in the draft, was what started > this thread. > Your responses all suppose that it is not possible to change what is > specified in the draft. > It would be helpful (IMHO) to the conversation to give consideration to the > contents of the thread, from the perspective that the specs in the draft are > not absolutely set in stone and immutable. > > Here's the quote from Ben: > I think Section 4.1 is pretty clear that everything goes in the Additional > section. (But this can be changed!) > > > "Cooperating DNS recursive resolvers will perform subsequent record > resolution (for SVCB, A, and records) and return them in the Additional > Section of the response. Clients either use responses included in the > additional section returned by the recursive resolver or perform necessary > SVCB, A, and record resolutions. DNS authoritative servers can attach > in-bailiwick SVCB, A, , and CNAME records in the Additional Section to > responses for a SVCB query." > > Yes this means you need may need to change additional section process to > chase other records. Named was already doing this for one type and with > HTTPS and SVCB needing we made the processing general. Yes, it also means > that one has to add CNAMEs to the additional section when processing HTTPS or > SVBC. > > > We can all read, and we understand what the current draft says. > That's NOT what is being discussed (how to interpret those words). > What IS being discussed in this thread is whether it may be more sensible to > align the process of handling the "alias" form in a manner more consistent > with how CNAME processing happens. > It is a proposal to change the spec itself, rather than an alternate > interpretation of what the current draft of the spec says. > > This is why I suggested that, while it is not CNAME per se, treating it as > "constrained alias applicable only to SVCB queries" isn't a huge leap, and > would simplify the code for handling alias form, on both the server and > client side of a lookup. > > If the standard says they belong in the Answer section (as I am suggesting), > I think the expected BIND client-side handling of SVCB records (alias and > non-alias, if in-bailiwick) and CNAME records if they are both placed in the > answer section by the server should be okay, in both situations: when SVCB is > "unknown" (it's a match to QTYPE), or when SVCB handling logic is added. > > Brian What benefit is there in changing this now? Moving the SVBC chain (graph actually) to the answer section. I know I can follow a graph much easier in the additional section than I can in the answer section with simple depth limited recursion. In the answer section I have to initiate multiple parallel recursions to complete the graph hitting different zones. What happens when one of those recursions fail? Do I return a partial answer? Do I SERVFAIL the entire query? What if one returns NXDOMAN? With everything in the addition section those questions go away. I return what I have. I can initiate speculative queries for missing RRsets where I don’t have NODATA/NXDOMAIN cached so when the client comes back I have the response in cache. The code point has been allocated. Implementations have been written to the existing spec. That’s what happens when you ask for a code point. You are saying: * This is its wire form. * This is its presentation form. * This is what the nameserver does. Now we can go play with the rest of the specification and tidy that up with nameservers that know about the code point. Working group chairs are supposed to believe the specification is in this state of readiness before asking for a early code point. If you want to compare to CNAME and query for CNAME you get back exactly 1 CNAME record even if there is a chain of CNAME records. The target is not followed. This is RFC 1034 behaviour. What I would like is for SVCB alias form to ONLY require looking for SVCB records and SVCB service mode to only require looking up address records. At the moment there is a scatter gun approach though I may have missed something. CNAME/DNAME records are found as a side effect of looking for other types. -- 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
Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries
On Aug 6, 2020, at 3:32 PM, George Michaelson wrote: > > If I (insanely) ran a totally manual, out of band process to > periodically canvas the space and injected the knowns into the model > of "root" for my resolver, would I be able to say I am primed? Not by the standard, no. RFC 8109 was passed by this WG as a standard. > I am trying to get to the point that the "how" part is only exemplary, > explanatory. The requirement is that you have the information, now how > you get it or how it comes into your resolver. That is not true for this standard. This standard gives the way to be primed following what has already been standardized before now. You can get the NS RRset for the root zone into your resolver in other ways, and the resolver would work fine, but that is not priming as standardized here. If you're asking the trivial question of whether you could continue to operate without following the standard, the trivial answer is of course "yes". > The distinction between shipped states of the root.hints and the > actual live mappings of the domain labels inherent in it, to addresses > (if you like) I can bypass the hints file ,and use SQL to update my > root mapping. > > I think the intent of "priming" is that you then populate the > information from 'inside' DNS. But, again, its only advisory, its not > standards enforced is it? You could ask to remove that designation in this -bis document if you want. I, for one, would disagree with such a request. > I can populate my continuing knowledge of > the state of the DNS at the root, or anywhere else, in any mechanism I > like. Yep, and nothing in the current standard or this updating document says that you can't. They say that the standard for priming is done this way. > I could periodically FTP the zone files from places, and populate my > resolver cache state from these. I could basically "never" forward DNS > queries high in the tree, if I felt like making my server do that. > > Am I "not primed" if I do this? Not by the standard, no. You still would have a running system. If you want to call it "primed" (or "Fred"), that's up to you. --Paul Hoffman smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries
No. thats good and clear. Priming is not just the concept of being correct, its specifically following a mandated in-band mechanism. It is a standard, and the bis requirements are not just "arrive at the state, don't care how" they are "arrive at the state by following this specific procedure" -otherwise, you cannot say you are primed in the RFC sense. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
On Thu, Aug 6, 2020 at 4:11 PM Mark Andrews wrote: > > > What benefit is there in changing this now? Moving the SVBC chain (graph > actually) to the answer section. I know I can follow a graph much easier > in the additional section than I can in the answer section with simple > depth limited recursion. In the answer section I have to initiate multiple > parallel recursions to complete the graph hitting different zones. What > happens when one of those recursions fail? Do I return a partial answer? Do > I SERVFAIL the entire query? What if one returns NXDOMAN? With everything > in the addition section those questions go away. I return what I have. I > can initiate speculative queries for missing RRsets where I don’t have > NODATA/NXDOMAIN cached so when the client comes back I have the response in > cache. I don't think this actually changes the spec, only clarifies it or fixes errors. It doesn't change wire format or presentation format, nor does it change the logical resolution tree. It only proposes a change to where the authoritative server should place RRs when QTYPE is found. It does so to maintain consistency with the general processing rules from 1034. That it happens to very closely align with parts of the CNAME rules, is a happy coincidence. But, this is the correct time to fix lingering issues that require clarification or correction. The latest rev, which includes substantial changes, is only a few weeks old (early June to early August). Here's a run-down of how I see the more explicit summary of what an authoritative server should do: An authority server should (in response to an SVCB query) return, at most - a single sequence of zero or more CNAMEs (with a 1:1 linkage from RDATA to owner once the chain is normalized), which must be in the Answer section - followed optionally by an SVCB record set of only AliasForm records, - followed optionally by an SVCB record set of only ServiceForm records. These would all necessarily be in the Answer section, as they all are (a) in-bailiwick, and (b) match the QTYPE (or are CNAMEs and as per RFC 1034 required to be in the Answer section). The above statement is ONLY in reference to recursive-to-authority query/response packets. Note: section 2.4.1 talks about AliasMode, but does not refer to Answer vs Additional sections at all. It only specifies the logical relationship between owner names and TargetNames and SVCB types. Note: Section 4.1 (Authoritative Servers) is only one paragraph long. IMHO, this is the part that is way under-specified. It also appears to be conflating the Additional section placement with what the Client expects. Clients should not be talking directly to Authoritative servers, so it might be a legitimate error that needs to be fixed. The overall placement of what should be an Answer, in the Additional section (i.e. when QTYPE == SVCB and RRTYPE returned == SVCB) is at odds with RFC 1034, IMNSHO. NB: If (and only if) there are in-bailiwick A/ records which are also resolved from the AliasForm records, those would need to be in the Additional section; this is not something I dispute in any way. Also NB: If TargetName names can be CNAME owner names (see below), it's not entirely clear whether those should go in the Answer section or Additional section. My initial opinion on this is, it's really Additional section processing, as there was no rewriting of the QNAME itself involved, so put it in the Additional section. Also NB: If an authority server happened to be authoritative for multiple zones, any SVCB records of either form from the non-in-bailiwick zone(s), if included at all, ,should be in the Additional section. (The spec doesn't mention authoritative servers that are authoritative for multiple zones, so my assumption would be that adding these should be explicitly excluded by the spec (but is not), or their treatment should be explicitly outlined by the spec as belonging in the Additional section.) So, to address your other questions: How a recursive responds to a client is something else entirely; whether and where SVCB records get returned might be an implicit signal for understanding SVCB as something other than "unknown" record types. Putting everything into the Additional section would be okay, but really only if the recursive knew the client was an actual end system, and not another resolver in "forwarder" mode. A more conservative approach would be to put all the received Answer sections in the Answer section, and all the Additional sections in the additional section. I don't think the graph process depends on where the authoritative puts the answers to a single query... you have to deal with the results either way. Each of those is going to be an atomic result with a single RCODE. This actually provides stronger support for AliasMode treatment being the same as CNAME treatment. If an authoritative server is adding in-bailiwick data, and gets to a TargetName which is (a) in-bailiwick
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
On Thu, Aug 6, 2020 at 7:13 PM Ben Schwartz wrote:
> Brian,
>
> I think arguing about the strength of the analogies to CNAME (Answer) vs
> SRV (Additional) is going to be a slow path to consensus. Apart from that
> analogy, I'm not sure I understand your motivating use case. Could you
> write a small example zone where you think the "chain in Answer" behavior
> has a clear advantage over "chain in Additional"?
>
Sure. Here are two very similar examples, where the first one I think is
required to put the entire chain in the Answer for ${reasons}. (Take as
ready any underscore prefixing needed to make this make sense...)
whatever.example.com. CNAME example.com.
example.com. SVCB 0 my-common-thing.example.com.
my-common-thing.example.com. CNAME my-canonical-thing.example.com
my-canonical-thing.example.com. SVCB
whatever.example.com. CNAME example.com.
example.com. SVCB 0 my-canonical-thing.example.com
my-canonical-thing.example.com. SVCB
The motivation here is that the optimization of adding in-bailiwick records
should, to maximize the benefit to the resolver and to the authority
server, process the second CNAME of the first example.
However, if the placement of the in-bailiwick TargetName's records is in
the Additional section, this is somewhat more complex. Either the CNAME
processing has to happen before the TargetName and CNAME canonical name
records are collectively placed in the Additional section, or the
Additional section must now also process the CNAME. Not doing either of
those would leave a "dangling CNAME" in the Additional section, which would
then necessitate an additional query round-trip from the recursive to
authoritative.
Putting them all in the Answer section, means normal Answer section
handling would basically handle the second CNAME "for free".
This is all opportunistic behavior. It doesn't matter whether the extra
records are added or not, so their absence from either section does not
imply their non-existence, nor does it imply the authoritative server is
aware or unaware of SVCB.
I'm not sure I understand why having them be in the Answer section is any
different from having them be in the Additional section, when it comes to
their handling upon receipt by a recursive resolver.
If the rules were "Put any SVCB records into the Answer section along with
CNAME records found while obtaining them", then the only records that
should be in the Additional section would be A/ records and related
DNSSEC records (and possibly CNAMEs found when obtaining the A/
records?).
I think this actually simplifies the processing:
The ServiceForm SVCB record(s) might not be present (based on whether the
authoritative is SVCB-aware and whether it is doing the addition of those
records), but IF they are present, they are in the Answer section.
This ALSO means that the only reason for anything being in the Additional
section is if there are A or records returned, which (hopefully)
implies the presence of a ServiceForm SVCB record.
The only other reason A/ records should be in the Additional section,
is if there is a delegation, in which case there should be stuff in the
Authority section too.
So basically, it becomes:
AliasForm only in Answer -> not in-bailiwick, or not SVCB-aware. Either
way, another query is needed.
AliasForm plus Service Form in Answer -> Check Additional for A/
records, or query for them if not found
(Both of the above possibly also include CNAMEs in the chain)
CNAME chain only in the Answer -> not in bailiwick, need another query.
No Data in the Answer, Authority has a delegation -> follow the delegation,
possibly use Additional section for glue.
I think this is pretty simple logic, and I don't see the problem... could
you point out the problem if there is one?
Brian
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question regarding RFC 8499
On Wed, Aug 05, 2020 at 01:04:22AM +, Paul Vixie wrote: > On Tuesday, 4 August 2020 23:11:34 UTC Michael De Roover wrote: > > i borrowed the initiator/responder terminology from iSCSI, and it seems > intuitive to me. this isn't a client/server situation, because a given host > might be both a client and a server, in a multi-level transfer graph. we need > terminology that describes the transaction, and not the host or hosts > participating in that transaction. we stopped using requester/responder when > the op codes stopped being limited to just QUERY and IQUERY and STATUS. (in > other words, UPDATE is technically a request, but not notionally so.) > > what's your proposal? As I said earlier, I think "primary" and "seconary" are well-enough understood concepts now that we can describe roles in a particular transaction with phrases like "acting as a primary" or "acting as a secondary" and get the point across without much difficulty. But if that's not acceptable, then maybe "transfer provider" and "transfer recipient"? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
> On 7 Aug 2020, at 11:54, Brian Dickson wrote: > > > > On Thu, Aug 6, 2020 at 4:11 PM Mark Andrews wrote: > > > What benefit is there in changing this now? Moving the SVBC chain (graph > actually) to the answer section. I know I can follow a graph much easier in > the additional section than I can in the answer section with simple depth > limited recursion. In the answer section I have to initiate multiple > parallel recursions to complete the graph hitting different zones. What > happens when one of those recursions fail? Do I return a partial answer? Do I > SERVFAIL the entire query? What if one returns NXDOMAN? With everything in > the addition section those questions go away. I return what I have. I can > initiate speculative queries for missing RRsets where I don’t have > NODATA/NXDOMAIN cached so when the client comes back I have the response in > cache. > > I don't think this actually changes the spec, only clarifies it or fixes > errors. It doesn't change wire format or presentation format, nor does it > change the logical resolution tree. It only proposes a change to where the > authoritative server should place RRs when QTYPE is found. It does so to > maintain consistency with the general processing rules from 1034. That it > happens to very closely align with parts of the CNAME rules, is a happy > coincidence. No, it doesn’t maintain consistency with RFC 1034. a. If the whole of QNAME is matched, we have found the node. If the data at the node is a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. If you want to treat SVBC and HTTPS as CNAMES then lets do that. a. If the whole of QNAME is matched, we have found the node. If the data at the node is a SINGLE SVCB in AliasForm, and QTYPE doesn’t match SVBC, copy the SVCB RR into the answer section of the response, change QNAME to the target name in the SVCB RR, and go back to step 1. If the data at the node is SVBC and the Otherwise, copy all RRs which match QTYPE into the answer section and go to step 6. 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. > But, this is the correct time to fix lingering issues that require > clarification or correction. The latest rev, which includes substantial > changes, is only a few weeks old (early June to early August). > > Here's a run-down of how I see the more explicit summary of what an > authoritative server should do: > > An authority server should (in response to an SVCB query) return, at most > • a single sequence of zero or more CNAMEs (with a 1:1 linkage from > RDATA to owner once the chain is normalized), which must be in the Answer > section > • followed optionally by an SVCB record set of only AliasForm records, Sorry you just broke DNSSEC if there are more than one AliasForm records. More than one is permitted with the same name. > • followed optionally by an SVCB record set of only ServiceForm records. Well this at the minimum would be a RRset and possibly multiple RRsets. > These would all necessarily be in the Answer section, as they all are (a) > in-bailiwick, and (b) match the QTYPE (or are CNAMEs and as per RFC 1034 > required to be in the Answer section). > The above statement is ONLY in reference to recursive-to-authority > query/response packets. > > Note: section 2.4.1 talks about AliasMode, but does not refer to Answer vs > Additional sections at all. When there was already clear instructions to add records to the Additional section why would it? > It only specifies the logical relationship between owner names and > TargetNames and SVCB types. > Note: Section 4.1 (Authoritative Servers) is only one paragraph long. IMHO, > this is the part that is way under-specified. It also appears to be > conflating the Additional section placement with what the Client expects. The clients will expect what we tell them to expect. > Clients should not be talking directly to Authoritative servers, Garbage. > so it might be a legitimate error that needs to be fixed. The overall > placement of what should be an Answer, in the Additional section (i.e. when > QTYPE == SVCB and RRTYPE returned == SVCB) is at odds with RFC 1034, IMNSHO. The DNS says if there are records of the given type at this name return them (this applies to CNAMES as well). If you happen to encounter a CNAME (and you are not asking for a CNAME)
