Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?
On Tue, Apr 9, 2019 at 1:56 PM Richard Gibson wrote: > Copied from https://github.com/each/draft-aname/issues/54 per Tony Finch. > > The current draft specifies > > > We treat missing address records (i.e. NXDOMAIN or NODATA) the same > > successfully resolving as a set of zero address records, and distinct > > from "failure" which covers error responses such as SERVFAIL or REFUSED. > > This is both undesirable for customers of DNS service providers (whose > active sites will occasionally be inaccessible to some clients for > $SOA_MINIMUM seconds), and operationally cumbersome because resolvers > are not in a good position to synthesize the necessary SOA records for > NXDOMAIN responses (e.g., example.com. ANAME example.invalid. alongside > example.com. A 192.0.2.1). Tony suggested that this was to be "as much > like CNAME as possible", but I disagree because unlike CNAME, ANAME can > have sibling records which are therefore available for use. > If it gets an authoritative answer saying that there are no address records, then it should respect that answer. If that is incorrect, then whatever gave that answer is broken or misconfigured and should be fixed. Perhaps I am missing something. In what cases can you imagine getting a response with no errors and no records? Perhaps a load balancer that has probed all the servers and determined that none are working? If you want a fall-back, it should be configured in the load balancer in that case. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] What should ANAME-aware servers do when target records are verifiably missing?
Copied from https://github.com/each/draft-aname/issues/54 per Tony Finch. The current draft specifies We treat missing address records (i.e. NXDOMAIN or NODATA) the same successfully resolving as a set of zero address records, and distinct from "failure" which covers error responses such as SERVFAIL or REFUSED. This is both undesirable for customers of DNS service providers (whose active sites will occasionally be inaccessible to some clients for $SOA_MINIMUM seconds), and operationally cumbersome because resolvers are not in a good position to synthesize the necessary SOA records for NXDOMAIN responses (e.g., example.com. ANAME example.invalid. alongside example.com. A 192.0.2.1). Tony suggested that this was to be "as much like CNAME as possible", but I disagree because unlike CNAME, ANAME can have sibling records which are therefore available for use. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME discussion
Vladimír Čunát wrote: > > I can't even see a simple way of detecting this. At least in the > implementation suggested by Jan where you have an authoritative that > calls out to a resolver (which calls out to authoritatives...) You could prevent the loop from leading to a circular dependency, rather than detecting the loop, e.g. if the auth always answers from zone or cache which are updated asynchronously. Maybe the auth's resolver could chase the chain by making ANAME queries; when the auth replies it can reply from zone data and skip filling in the additional section if it doesn't have fresh address records. The auth can be more eager to make recursive queries when it gets A or queries. Tony. -- f.anthony.n.finchhttp://dotat.at/ promote human rights and open government___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME discussion
If an implementation has a resolver, then that component is the logical place for deduplication (e.g., the second inbound query for a given ANAME target does not result in a second outbound query, but rather waits on completion of the first). On 4/9/19 11:15, Vladimír Čunát wrote: On 4/9/19 3:38 PM, Richard Gibson wrote: This loop is one reason of several to eliminate inline resolution for ANAME if possible and minimize it otherwise, but is not quite as bad as it seems because all involved servers can—and should—avoid issuing queries that are redundant with an already-active request. But even if they don't, the early queries eventually time out and rate limiting eventually detects and caps the runaway load. In other words, this misconfiguration does not create any new vulnerabilities, and existing mechanisms are already sufficient to handle it (although the document should explicitly mention them to avoid subjecting new implementers to unnecessarily painful lessons). I can't even see a simple way of detecting this. At least in the implementation suggested by Jan where you have an authoritative that calls out to a resolver (which calls out to authoritatives...) - it would need some magic that somehow links one query of the cycle to the other but regular DNS queries do not currently carry such information AFAIK. Am I missing some obvious approach? --Vladimir (Knot Resolver) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME discussion
On 4/9/19 3:38 PM, Richard Gibson wrote: > This loop is one reason of several to eliminate inline resolution for > ANAME if possible and minimize it otherwise, but is not quite as bad > as it seems because all involved servers can—and should—avoid issuing > queries that are redundant with an already-active request. But even if > they don't, the early queries eventually time out and rate limiting > eventually detects and caps the runaway load. > > In other words, this misconfiguration does not create any new > vulnerabilities, and existing mechanisms are already sufficient to > handle it (although the document should explicitly mention them to > avoid subjecting new implementers to unnecessarily painful lessons). I can't even see a simple way of detecting this. At least in the implementation suggested by Jan where you have an authoritative that calls out to a resolver (which calls out to authoritatives...) - it would need some magic that somehow links one query of the cycle to the other but regular DNS queries do not currently carry such information AFAIK. Am I missing some obvious approach? --Vladimir (Knot Resolver) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME discussion
This loop is one reason of several to eliminate inline resolution for ANAME if possible and minimize it otherwise, but is not quite as bad as it seems because all involved servers can—and should—avoid issuing queries that are redundant with an already-active request. But even if they don't, the early queries eventually time out and rate limiting eventually detects and caps the runaway load. In other words, this misconfiguration does not create any new vulnerabilities, and existing mechanisms are already sufficient to handle it (although the document should explicitly mention them to avoid subjecting new implementers to unnecessarily painful lessons). On 4/9/19 08:09, Jan Včelák wrote: On Tue, Apr 2, 2019 at 5:54 PM Tony Finch wrote: WRT loop detection, it is much easier if the additional section in the response from the resolver contains the chain(s). The draft doesn't specify that at the moment; maybe it should. I meant a situation where an authoritative server is doing the sibling address record substitution using an external resolver. Imagine the following ANAME loop: foo. ANAME bar. bar. ANAME foo. For simplification, expect the zones to live on different authoritative servers and also that the ANAME processing triggers with the first query. The resolution steps will look something like this: 1. Authoritative receives a query for foo. 2. Authoritative finds the ANAME and calls out to the resolver asking for bar. 3. Resolver sends a query for bar to the authoritative. 4. Authoritative finds the ANAME and calls out to the resolver asking for foo. 5. goto 1 The authoritative server acting as a stub resolver doesn't have full context of the resolution chain and therefore cannot break the loop. We would have to pass around additional context in the queries and I'm not sure if DNS firewalls would be happy to see messages with QR = 0 and ARCOUNT > 0. Jan ___ DNSOP mailing list DNSOP@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=4nTLZAsnHCwTJyrARtQ8uzJN8jmKg6JeQX9gDiHuHhc=O9ORRXkRs5TFBIKPXCdq6ck3K88lw-t7xDcNwI-ecMU= ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME discussion
On Tue, Apr 2, 2019 at 5:54 PM Tony Finch wrote: > WRT loop detection, it is much easier if the additional section in the > response from the resolver contains the chain(s). The draft doesn't > specify that at the moment; maybe it should. I meant a situation where an authoritative server is doing the sibling address record substitution using an external resolver. Imagine the following ANAME loop: foo. ANAME bar. bar. ANAME foo. For simplification, expect the zones to live on different authoritative servers and also that the ANAME processing triggers with the first query. The resolution steps will look something like this: 1. Authoritative receives a query for foo. 2. Authoritative finds the ANAME and calls out to the resolver asking for bar. 3. Resolver sends a query for bar to the authoritative. 4. Authoritative finds the ANAME and calls out to the resolver asking for foo. 5. goto 1 The authoritative server acting as a stub resolver doesn't have full context of the resolution chain and therefore cannot break the loop. We would have to pass around additional context in the queries and I'm not sure if DNS firewalls would be happy to see messages with QR = 0 and ARCOUNT > 0. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-algorithm-update-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for DNSSEC Authors : Paul Wouters Ondrej Sury Filename: draft-ietf-dnsop-algorithm-update-08.txt Pages : 11 Date: 2019-04-09 Abstract: The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of non- existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes [RFC6944]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-08 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-algorithm-update-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-algorithm-update-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-algorithm-update-07: (with COMMENT)
On Fri, 5 Apr 2019, Bob Harold wrote: I'm a little surprised that this is going for PS rather than BCP, which seems like it would reflect the recognized need for recurring updates to the guidance given. Personally, it seems a PS feels like it has a little more weight. Not just a recommendation but a strong nudge towards doing this. In a similar vein, if we stay at PS, a lot of the references seem like they would need to move from Informative to Normative, since to implement the various MUST-level algorithms you have to follow those references. I would not say those references are normative in that sense. You don't HAVE to read how GOST is specified to not implement it. Section 1.1 The field of cryptography evolves continuously. New stronger algorithms appear and existing algorithms are found to be less secure then originally thought. [...] I'd suggest also noting that attacks previously thought to be computationally infeasible become more accessible as the available computational resources increase. Added. Section 1.2 For clarification and consistency, an algorithm will be specified as MAY in this document only when it has been downgraded. Does "downgraded" mean that it was formerly mandatory but has been rotated out of the mandatory role? Perhaps explicitly saying "downgraded from " would aid clarity. Added. Section 3.3 SHA-384 shares the same properties as SHA-256, but offers a modest security advantage over SHA-384 (384-bits of strength versus nit: SHA-384 has an advantage over ... SHA-384? Fixed. We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback. IIRC a directorate reviewer noted that "imminent" means "expected to arrive in the near future but not yet present"; such text does not seem appropriate for final publication since review after that point would not be helpful. That was fixed too :) Thanks for the review! Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Gen-art] Genart telechat review of draft-ietf-dnsop-algorithm-update-07
On Mon, 8 Apr 2019, Alissa Cooper wrote: Peter, thanks for your review. I entered a Yes ballot and pointed to your review. Indeed, thanks for the review Peter! I've incorporated all of your suggestions, with the exception of: Page 4, Section 1.3: In general, it would be nice if there were references in the paragraphs following the table that point to the research that led to the statements of strength or lack of strength of the algorithms. Then again, this isn't an academic paper, so references aren't strictly required either. While I mostly (but not completely) agree with the notes on the individual algorithms, the average reader is left to take the statements as gospel rather than being able to make an informed decision on the current state of cryptography. We did not want to add these to the document, in an attempt to keep the document short and on topic. Page 5, 8th paragraph, 1st sentence: change "ED25519" to "Ed25519". Change "ED448" to "Ed448". Only make these two changes if you are referring to these algorithms by the names given to them by their authors as opposed to the mnemonics used within DNSSEC. (This statement also applies to the Ed25519 comment below.) Insert "the" before "Edwards". We are using the mnemonics, so I left these as is. Page 5, 8th paragraph, 4th sentence: change "ED25519" to "Ed25519". Same, Page 6, Section 3.3, 3rd paragraph, 1st fragment: change "for" to "regarding". Append "are summarized in the table below." to the fragment. I did not understand this change request? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
