Re: [DNSOP] A question on values in draft-dnsop-caching-resolution-failures
On Mon, Jul 24, 2023 at 06:26:46PM +, Wessels, Duane wrote: > It was not our intention that “2” would be the only possible exponent in > the backoff algorithm. Would this slightly revised text be more > agreeable? > >Resolvers SHOULD employ an exponential or linear backoff algorithm to >increase the amount of time for subsequent resolution failures. For >example, the initial time for negatively caching a resolution failure >is set to 5 seconds. The time is increased after each retry that >results in another resolution failure. Consistent with [RFC2308], >resolution failures MUST NOT be cached for longer than 5 minutes. That's definitely an improvement, yes. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A question on values in draft-dnsop-caching-resolution-failures
On Mon, Jul 24, 2023 at 10:00:37AM +0530, Mukund Sivaraman wrote: > When seeing prescriptive text, implementors often wants to know the > rationale behind it. If the value of 5 is changed to 1, please mention > and have the authors include in the document why the lower limit is > 1s. Is it an arbitrary change? Is this change based on the default value > of BIND's servfail-ttl named.conf option? Yes, it is. For background: BIND implemented a SERVFAIL cache in 2014 with a default cache duration of 10 seconds; after a slew of complaints, in 2015 we lowered it to 1 second, and also reduced the configurable maximum from 5 minutes to 30 seconds. The reason was that certain common failure conditions are transitory, and it's not unreasonable to prioritize rapid recovery. Now, to be clear, the comparison isn't exactly apples to apples: the BIND SERVFAIL cache is a somewhat stupider mechanism than the one outlined in the draft. It caches *all* SERVFAIL responses, regardless of the reason they were generated. For example: when the cache is cold, a query may time out or hit DDoS mitigation limits before it's finished getting through the whole iteration process; an immediate retry would start further along the delegation chain and would succeed. Such problems weren't noticeable until we implemented the 10-second cache, but became very noticeable afterward. If we were able to selectively cache *only* those SERVFAILs that are unlikely to recover soon, then five seconds might indeed be a good starting point. But, with our relatively dumb cache, we found that one second did a fairly good job reducing the processing burden from repeated queries, and eliminated the user complaints about the resolver taking forever to recover from short-lived problems. It's been working well enough that it hasn't been a priority to develop a more complex failure cache. In any case, even with the assumption that future implementations *will* have better selectiveness, I'm leery of using 5 seconds as hard minimum in an RFC. I think it's likely that some operators will find that excessive and want the option to tune it to a lower value. Also, if you *are* doing exponential backoff, then two failures in a row will get your duration up to 4 seconds anyway, so the difference between starting at 1 and starting 5 isn't really all that significant. > > * Note that the original text has this as SHOULD. I've heard reasons for > > both SHOULD and MAY. > > What are these reasons? I suggested MAY because I think exponential backoff is a pretty specific (and rather aggressive) approach to cache timing, and I'm not entirely comfortable with it having the almost-mandatory force of a SHOULD. The original text says a series of seven resolution failures would increase the duration before a retry to five minutes: 5 seconds to 10 to 20 to 40 to 80 to 160 to 300. Lowering the starting value to one second means it would take nine failures to reach 300. IMHO, keeping the recovery period flat, or increasing it linearly (5, 10, 15, etc), could also be operationally reasonable choices, so I'm not sure why we need to be so emphatic about *this* particular backoff strategy in the RFC. I have no objection to mentioning it, but it felt like a MAY to me. It's a mild preference though, and if I'm the only one who feels that way, I won't argue about it further. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Meaning of lame delegation
On Mon, Apr 10, 2023 at 02:35:36PM +, Joe Abley wrote: > I continue to think that if you don't get a response, you can't tell > whether the delegation is lame. Lameness (as I use the term) relates the > configuration of the nameserver, not it's availability. > > So I prefer Duane's formulation to yours, precisely for the reason you > gave. I understand the distinction you're making, but (serving in my occasional role as asker-of-the-dumb-question), does this distinction matter very much? Do we treat delegations differently if they're Properly Lame™ vs merely unusable, and thus need different words for each category? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
On Tue, Mar 07, 2023 at 11:15:55AM +0100, Peter Thomassen wrote: > Oops, touché! I stand corrected. Thanks, Mark. > > What I meant is rrtype 0. I used the wrong mnemonic.* IMHO, you're almost definitely correct that NULL (type 10) would be safe to use for this. Type 0, thought, would not - it's used internally by name servers in ways that could be pretty difficult to untangle. I would lean toward using a newly allocated type code, though, because I'm 100% sure that wouldn't cause any conflict with existing implementations, and I'm only 99.7% sure that NULL wouldn't. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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] Question regarding RFC 8499
On Thu, Jul 23, 2020 at 07:40:25PM +, Paul Vixie wrote: > -1. there are zones lacking primaries, and a secondary which can also > talk to other secondaries gives a second role to those other secondaries. > we must not simply revert to the STD 13 terminology. the role of an > authority server depends on what zone we're talking about and what other > server they're talking to. that's why i've recommended we stop talking > about "primary servers" or "secondary servers", and instead talk about > "transfer initiators" and "transfer responders", where the transfer > pertains to a zone and the initiator or responder is a server's role with > respect to that zone and that transfer. I am visualizing a newly-hired and inexperienced administrator being shown the ropes, and told: - "this server is the master and that one is the slave", - "this server is the primary and that one is the secondary", or - "this server is the responder and that one is the initiator" and I think either of the first two versions would be clearer and more informative to them than the third. Within the specific context of discussing a zone transfer operation, "initiator" and "responder" are clear enough, but in the broader context of servers, service providers, and zone configurations, I don't see it as an improvement. (Come to think of it, even in that specific context, there's potential confusion in the fact that a primary server could meaningfully be said to "initiate" a transfer operation when it sends a NOTIFY.) On the other hand, you can say "server A acts as primary for server B", and it's fairly easy to understand even if technically neither one of them is *the* primary. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question regarding RFC 8499
On Thu, Jul 23, 2020 at 02:36:42PM -0400, Joe Abley wrote: > Oh, that's something I wasn't aware of. Do you have any examples of > people moving from master/slave to primary/secondary? Aside from RFC 8499: | Slave server: See "Secondary server". | | Master server: See "Primary server". BIND added primary/secondary as synonyms for master/slave in our configuration syntax several years ago and have been progressively updating our documentation to prefer those terms ever since. The upcoming release pretty much completes that process. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Question regarding RFC 8499
On Thu, Jul 23, 2020 at 01:38:58PM -0400, Joe Abley wrote: > I don't think primary/secondary are exact substitutes for master/slave in > the way that those four terms are commonly used today. [...] > If we are looking for alternative terminology to master/slave (which I am > not against, because change is a constant and inclusiveness and awareness > amongst all industries is surely to be supported and encouraged) in my > opinion we should find new words and not redefine or overload the common > meaning of primary and secondary. I share the desire for perfection, but IMHO the transition from "master" to "primary" and "slave" to "secondary" is far enough under way and well enough understood at this point that I suspect it would be easier to add modifiers when necessary than to try to deploy new vocabulary entirely. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CNAME chain length limits
On Wed, May 27, 2020 at 01:48:32PM -0400, John R Levine wrote: > is there any consensus as to the maximum CNAME chain length > that works reliably, and what happens if the chain is too long? Hanging > seems sub-optimal. BIND cuts CNAME chains off at 16. As far as I know that was an arbitrarily- selected value, but it's been in the code since 1999 and so far as I can recall, no one's complained. The maximum reliable chain length won't be any longer than that; it might be shorter. When a chain is too long, I think BIND just returns a response with the 16 CNAMEs it's found so far, and without a final answer. The client can start a new query from where the response left off, but I would expect most to treat it as a non-answer. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
On Wed, Feb 26, 2020 at 03:34:55PM +0100, Vladimír Čunát wrote: > I don't think it's so simple. The current ANAME draft specifies new > behavior for resolvers, and there I'd expect even slower overall > upgrades/deployment than in browsers. I agree with this. Browsers often upgrade themselves these days; resolvers sit for years. (A few years ago there were still BIND 4 instances ticking away out there.) And, people who want their browsers to work better will have a specific reason to upgrade. Resolver operators' motiivation is rather less direct. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
On Thu, Feb 20, 2020 at 09:29:31AM +0100, Matthijs Mekking wrote: > ANAME was supposed to solve the CNAME at the apex problem and mitigate > against DNS vendor lock in. Both SVCB and HTTPSSCV do not fix this problem. CNAME at the apex wasn't really the problem. Getting browsers to display content from the right CDN server was the problem. CNAME at the apex was a hackish nonstandard solution that we were forced to adopt by browser vendors' failure to do anything more sensible. If browser folks *are* doing something more sensible now, as appears to be the case, then we no longer have the problem ANAME was meant to solve, and I'm content to let it pass into history. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
On Wed, Sep 11, 2019 at 12:42:53AM +, Paul Hoffman wrote: > Thanks. However, I still think this opens a lot of security holes if > developers try to be "smart" by assuming that some EDEs only make sense > with some RCODEs. If I'm in the rough, I'll be quiet. Sorry, I'm a bit slow tonight; can you explain in more detail the security hole you foresee, and how Wes's suggestion fails to address it? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Specification of DNSKEY "Private-key-format"
On Fri, Aug 30, 2019 at 09:56:21AM +0530, Mukund Sivaraman wrote: > For interoperability, there are other BIND-specific formats to consider > too such as the journal file format, the control channel protocol, > etc. Those seem like separate conversations to me, but I'm happy to have them. I should clarify, while interoperability between Loop's and BIND's private key files may well be useful, IMHO the main concern would be to prevent accidents. If Loop uses what appear to be BIND-style K*.private files, but you bump the format to 1.4, and BIND does the same with incompatible set of changes, then BIND key files could break Loop, or vice versa. So either we should ensure that two sets of changes are compatible with each other (for example, each could recognize-but-ignore any new metadata fields that are introduced by the other), or, failing that, we should ensure that the two formats are *so* incompatible that nobody can cross the streams by mistake. You could change the K in the filename to some other letter, for instance, and then BIND couldn't possibly try to load Loop's keys. But I'd be happy to discuss your proposed changes in hopes of maintaining interoperability. We should probably take it off the list, however; I don't think implementation details on this level are probably of much interest to dnsop. > * As you know, historically the BIND tree on unix relied on /dev/urandom > and /dev/random (or some custom device) as sources of random > numbers. FYI, no longer the case as of 9.14. > There is a ticket to implement the features of what dnssec-keymgr > provides within named itself for ease of use of key maintenance This is on our road map as well. AFAIK it doesn't require changes to private keys, though. > The key material and schedule metadata should be separated into > different files. Yep, that's a design decision I regret. And not just for the reason you mention, but also because there was no good reason for the metadata to be secret, and keeping it in a file that isn't publicly readable causes a lot of inconvenience. I wish I'd added a third file instead, such as K*.meta, instead of extending K*.private. However, IMHO, redesigning it now would inconvenience people rather more than putting up with it does, so for the time being I don't expect it to change. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Specification of DNSKEY "Private-key-format"
On Thu, Aug 29, 2019 at 07:25:54PM +0530, Mukund Sivaraman wrote: > I am asking about where this key format is specified - I want to extend > it. There's never been a written specification as far as I know, and if there was one, then it's definitely been obsolete since 2009, because I changed the format then and I didn't update any specs. What I can tell you is: the private key file contains a format version string, "Private-key-format", currently always set to 1.3, and an algorithm string, "Algorithm". After that comes a set of private keydata fields which are specific to the algorithm, and finally a set of *optional* metadata fields. Those were introduced in format version 1.3. They include "Created", "Publish", "Delete", etc, and also a few (such as "RollPeriod") that were reserved for future use but we'e never gotten around to using them. If the parser encounters any field that it doesn't recognize, and the key claims to be version 1.3, then it will reject the key with an error. However, if Private-key-format is increased to at least 1.4, then the version 1.3 parser will ignore the unknown fields and just use the ones that it does understand. A version number above 2.0 is assumed not to be backward-compatible, so that key would be rejected always. We've have had a few conversations at ISC recently about adding some new fields and increasing the format version to 1.4, so it would probably be best if we coordinate our changes to ensure that your extensions are interoperable with ours. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
On Thu, Jul 25, 2019 at 01:25:52PM -0400, Ólafur Guðmundsson wrote: > Dan, > I think all of this makes sense, what does not make sense is to stuff this > into old "AXFR/IXFR" semantics. > The draft is already changing how "upstream" deals with "downstream" in > this proposal. > My suggestion is to take a step back and say we have outgrown AXFR and we > need better mechanism to sync > various servers. > Lets start work on a new "SYNC Name servers" protocol that can meet modern > requirements > [...] We're running out of bar bof opportunities in Montreal, but I'd be happy to discuss this further. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt
On Thu, Jul 25, 2019 at 03:36:39PM +0100, Tony Finch wrote: > These abbreviations are about identifying the transport that is being used > for the DNS messages. One problem with Do53 is that it isn't specific > about the transport, because it covers both UDP and TCP. But it's a handy > abbreviation for DNS over traditional transports. It doesn't identify DNS > as a whole, just the framing of DNS messages in UDP and TCP. The other day at ANRW, a paper was presented that compared performance of DoH, DoT, and Do53. It was unclear to me what transport the authors had used for their Do53 measaurements - and it makes a significant difference. I don't know, even now, whether the comparison was apples-to-apples or not. "Do53" is a handy abbreviation, but I'm concerned that using it as a coequal peer of DoT and DoH will lead to fuzzy thinking. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis
On Thu, Jul 25, 2019 at 11:15:22AM -0400, Shumon Huque wrote: > Can you elaborate on how you plan to do this? > > One of the things that has always annoyed me about RFC7706 (and its > successor I-D) is that it offers no suggestions on how to validate that you > got a correct copy of the entire root zone. The example configurations > given in the appendix are all insecure - they rely on unauthenticated zone > transfer. I wouldn't say "insecure", exactly, but you're partly right - in the examples in RFC 7706, the zone transfer itself would be insecure, but once the zone was transfered, answers would still be validated. That's why the local mirror is set up in a separate auth server or view - it prevents answers from being returned as authoritative data, without validation. So clients do still have some protection; the problem is, there's no automatic recovery if the transfer is bad. Clients would start to SERVFAIL and the local root wouldn't know it had a problem. BIND 9 mirror zones address this in two ways: first, the zone is validated when transferred; the transfer is rejected if any bogus RRsets are found or if the NSEC chain is incompete. Second, if the zone is unusable, either because it failed to transfer in the first place or because it expired without a successful refresh, named automatically fails over to normal recursion to the root. This doesn't address the problem of glue and delegation NS records, but those aren't subject to DNSSEC validation during normal recursion anyway, so clients aren't substantially worse off. The transfer does represent an attack surface that wasn't there before, but it would be an extremely difficult one to exploit. That said, ZONEMD or XoT would improve things further, and I hope the root zone will adopt one or both. In the more general case for validating zone transfers, the idea is to have a sanity check that signatures are good before a secondary starts serving a zone. This is mostly about preventing self-foot-shooting incidents; ZONEMD isn't strictly necessary for it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis
On Tue, Jul 23, 2019 at 10:18:20PM +, Paul Vixie wrote: > at the one-hour DNSOP meeting in montreal on monday evening, the authors > of RFC 7706 described some of the use case questions they were hoping to > answer in their -bis document, and one of them hit squarely on a topic i > spoke about frequently between 2005 and 2015. i've attached a copy of the > 2015 proposal, which was reviewed by warren kumari and then presented in > a non-IETF meeting on these topics, organized by warren and i, in hong > kong. > > i was opposed to RFC 7706 as written, but there is no permanent record of > my reasoning since RFC documents don't include a "dissenting views" > section, so let me briefly recapitulate here. Thanks. I've never understood your objection to 7706, as it wasn't a new protocol, it just informed people of a way to use what already existed. > first, all complexity comes at a cost. the new code and configuration > needed to support "mirror zones" will be a life long source of bugs and > vulnerabilities, because that's true of every new feature. the desired > benefit should be weighed against this cost. "by running one on the > loopback" fails this important test, mostly because it only applies to > the root zone. A couple of points here: first, mirror zones were developed as a way to make it simpler to configure a 7706-style local root mirror, and to mitigate certain failure cases that could occur in the wake of a failed transfer, but mirror zones are not RFC 7706. You can set up 7706 on *any* name server; the examples in that document were written without mirror zones. Second, this is mostly just nitpicking, but the statement about mirror zones isn't really correct. In BIND, at least, "type mirror" can be used for any zone that allows transfers. However, admittedly, one probably wouldn't want to do it for large zones, and I don't know of any TLD's that allow transfer in the first place, so for the purposes of the current discussion, you're right enough. Third, and more pertinently, this work may have spin-off benefits. I've thought for a long time that a mechanism to use DNSSEC to validate zone transfers would be a useful addition to BIND. While that feature, per se, still doesn't exist, the mirror zone developemnt invovled writing a lot the code that's needed for it, and I expect it to exist fairly soon. So I don't think 7706 will have been a waste of time even if it turns out not to have been particularly effective at its original use case. > second, RDNS name servers who wanted to support this feature, which all > must, due to the competitive nature of the open source infrastructure > community, have to add features very much like authority DNS. we have > been moving away from the so-called "hybrid server" model for three > decades now, and this was a move in precisely the wrong direction. This confuses me. There's nothing in particular for RDNS implementations to support. Set up your root hints to point at a local address, run an auth server at that address, configure that server as a secondary for the root zone - presto, 7706 is supported. What server can't do that? Some implementations may wish to support 7706 internally as BIND has done, but it isn't mandatory. In any case, it would't be the first time it's been useful to mix RDNS and auth (consider empty RFC 1918 reverse zones, for example). I've never agreed that mixing auth and RDNS functions was a bad idea, actually, but that's another conversation. > third, access patterns of root zone data are an important input to > internet governance, and the 7706 proposal included no recommendations by > which access patterns could still be globally shared in any way -- and > for reasons of scale, they will not be participating in Day In The Life > exercises. This bit's legit. > in summary, RFC 7706 solves the wrong problem, in the wrong way, with an > inverted cost:benefit model compared to similar conceptions with similar > implementation costs. As far as I know, 7706 hasn't had much benefit with respect to latency in most environments, and I'm skeptical about its utility with random-query attacks. (Unfortunately, I hear negative answer synthesis isn't working as well at that as we'd hoped, either.) But, it's Mostly Harmless. The implementation cost can be zero if you want it to be; it's just a server configuration. At worst, it's a waste of the time that's been spent talking about it (with the zone transfer code that fell out of it turning the effort to a net positive, I hope). -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
On Sat, Jul 06, 2019 at 03:39:53PM -0700, Joe Abley wrote: > What's the use-case for using the DNS to transfer private key data? Inline signing, I believe. Witold should be the one to discuss that one, not me. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] proposal: Covert in-band zone data
Colleages, Some years ago, Dan Mahoney and I submitted a draft describing a proposed mechanism for storing confidential zone comments alongside normal zone data - a NOTE RR, which would be transferrable from primary to secondary servers, but not accessible to ordinary DNS queries. It generated some iniital interest, but not much momentum, and we let the proposal lapse. More recently, Witold Krecicki had a very similar idea for a mechanism to disseminate private key data between primary and secondary servers. We talked it over and decided to expand the NOTE record semantics into a generic method for storing and transferring covert in-band zone data. The generic mechanism is described in draft-krecicki-dns-covert-00. It calls for the allocation of a range of "Covert-RR" type code values, which would have restrictions on their dissemenination. A primary server implementing Covert-RR types must not allow them to queried, nor to be transerred to a secondary server unless that server indicates via an EDNS option that it *also* understands Covert record semantics and will not transfer the data to any peer that doesn't. The original NOTE RR draft has been shrunk down and rewritten as a proposed use case for Covert RR's. Additional use cases will be coming in the future; in particular, draft-pusateri-dnsop-update-timeout seems like it might be a good candidate. Details are below. Please have a look. Thanks! Name: draft-krecicki-dns-covert Revision: 00 Title: Domain Name System (DNS) Resource Record types for transferring covert information from primary to secondaries Document date: 2019-07-06 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-krecicki-dns-covert-00.txt Status: https://datatracker.ietf.org/doc/draft-krecicki-dns-covert/ Htmlized: https://tools.ietf.org/html/draft-krecicki-dns-covert-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-krecicki-dns-covert Abstract: The Domain Name System (DNS) Resource Record TYPEs IANA registry reserves the range 128-255 for Q-TYPEs and Meta-TYPEs [RFC6895] - Resource Records that can only be queried for or contain transient data associated with a particular DNS message. This document reserves a range of RR TYPE numbers for Covert-TYPEs - types that are an integral part of the zone but cannot be accessed via a normal QUERY operation. Uses for such records could include zone comments that are transferrable with the zone, expiry times for dynamically updated records, or Zone Signing Keys for inline signing. This document, however, does not define any specific Covert RR types. Name: draft-hunt-note-rr Revision: 02 Title: A DNS Resource Record for Confidential Comments (NOTE RR) Document date: 2019-07-06 Group: Individual Submission Pages: 4 URL:https://www.ietf.org/internet-drafts/draft-hunt-note-rr-02.txt Status: https://datatracker.ietf.org/doc/draft-hunt-note-rr/ Htmlized: https://tools.ietf.org/html/draft-hunt-note-rr-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-hunt-note-rr Diff: https://www.ietf.org/rfcdiff?url2=draft-hunt-note-rr-02 Abstract: While the DNS zone master file format has always allowed comments, there is no existing mechanism to preserve comments once the zone has been loaded into memory or converted to a binary representation. This note proposes a new RR type "NOTE", to be allocated from the Covert-RR type range proposed in [I-D.krecicki-dns-covert], so that confidential comments can be stored alongside zone data, and included in zone transfers when Covert semantics are supported by the secondary. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME in answer or additional section [issue #62]
On Tue, Jun 11, 2019 at 08:11:51PM -0400, Anthony Eden wrote: > I'm a fan of Michael's suggestion of using EDNS to signal that the > authoritative should return ALIAS vs synthesizing. Any reason this won't > work? Not that I can think of, but it adds significant implementation complexity in order to solve a problem that I'm not at all sure we have. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] ANAME in answer or additional section [issue #62]
On Tue, Jun 11, 2019 at 10:31:55AM +0200, Matthijs Mekking wrote: > The main argument for putting it in the answer section is that putting > it in the additional section implies a lower trust level, and that the > record is optional and can be removed when minimizing responses. I'm inclined to favor this argument (probably unsurprisingly, since I'm the one who argued it). IMHO, the ANAME is the real answer we're sending; the A and records are just friendly hand-holding for legacy servers. It doesn't make sense to me to demote the real answer into the additional section, any more than it would have to move DNAME there. The protocol specificaions are clear on this point - the more so considering we've already deployed DNAME - and my sympathies for an implementation that got it wrong would be limited. That said, if any resolver implementations are known to choke if they see an unexpected extra RRset in the answer section, it would be good to find out about it. I guess we should do some testing. Hm, stub resolvers might be stupider than full resolvers. Perhaps it would be useful to differentiate RD=0 and RD=1? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt
On Mon, May 13, 2019 at 10:52:59AM +0200, Martin Hoffmann wrote: > Paul Hoffman wrote: > > A far easier approach is for any developer to feel free to treat > > these RRtypes as unknown RRtypes. > > That will work for all record types except those defined in RFC 1035 > since name compression in record data is allowed for them. Yes, that's exactly the problem that needs addressing. Those specific types, defined in 1035 and containing names in the rdata, cannot now be treated as opaque by a compliant server. We *have to* implement them so we can handle name compression and canonicalization correctly, even though nobody's used them for donkey's years (some of them were already labeled "obsolete" when 1035 specified them). There are other types that are also unused, but can be treated as opaque; so IETF action isn't necessary for implementers to do that. Having a note in the registry about whether they're still in use might be a kindness for implementers. It doesn't impact interoperability, though. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt
On Mon, May 13, 2019 at 07:47:35AM +, Paul Hoffman wrote: > A far easier approach is for any developer to feel free to treat these > RRtypes as unknown RRtypes. I'm not sure I understand the distinction you're making here? What you said sounds similar to what the document proposes, so perhaps the document is unclear, or perhaps I've misunderstood you. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 04:05:22PM -0800, Paul Vixie wrote: > nope. because it did not prototype any partial replication. i'm not > going to mirror COM because i need it to reach FARSIGHTSECURITY.COM. I didn't say anybody's going to mirror COM, I said I suspect zone mirroring will find applications other than pre-caching the root. The fact that it isn't a complete solution to the problem space you're interested in at the moment doesn't mean it was useless. That wasn't a major motivation for the work anyway, I don't believe -- my recollection is that it was mainly about reducing garbage traffic, with latency reduction for some resolvers a happy side-effect. Keeping cache data warm and available during network partitions is a largely solved problem; we have prefetch/hammer, we have serve-stale. (Also apparently we have whatever generates all that zombie DNS traffic Geoff discovered back in 2016, but I'd rather avoid perpetuating that mistake, which seems *quite* perpetual enough as it is.) Keeping cache data coherent is less solved: we don't have the trusted invalidation piece you mentioned. I agree that might be a useful line of inquiry. I guess that's the point you were trying to make; I didn't get it immediately because you started off discussing the shortcomings of an RFC that doesn't seem particularly directly related. So let's get specific about the problem and discuss requirements for a solution. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: > indeed nothing which treats the root zone as special is worth pursuing, > since many other things besides the root zone are also needed for > correct operation during network partition events. This point is well taken, but sometimes the root zone is a useful test case for innovations that might be more generically useful later. It's relatively small, relatively static, *XFR accessible, signed but uses NSEC not NSEC3, etc. It's pleasantly free of annoyances. So, zone mirroring fell out of 7706, and I suspect it will eventually have broader applications than just local root cache. I think some of the early work on aggressive negative caching was root-specific as well. I wouldn't assume an idea is bad just because it's currently focused on the root, it might not always be. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: > unbound has pioneered a bit of this by automatically refetching data > that's near its expiration point. [...] > _that_ would be complexity worth its cost. 7706 was not. HAMMER is not. I'm confused, what's the difference between HAMMER and the thing you said? (Which BIND also does, incidentally.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Any website publishers who use CDNs on the list?
On Fri, Nov 02, 2018 at 10:16:25PM +0100, Måns Nilsson wrote: > At the risk of sounding like a repetitive bore, what is actually needed > is a way to say "for that domain name, apex or not, https[1] services are > over there >". Without messing up the entire node in the tree and > causing special processing in every name server and full service > resolver. And without stomping the other interesting protocols that > might like a RR on the node to be found. > > The entire effect that ANAME is supposed to have is achieved easier > by publishing URI records. And by getting web browsers to ask for URI > first. Speaking as a co-author of ANAME, I agree about this. URI, SRV, a proposed new HTTP RRtype, whatever - service lookup is absolutely the correct way to accomplish this goal. However, browser vendors are *not doing that*, and I've given up hope that they ever will. Trying to out-stubborn them has been ineffective. So vendors muck around in DNS software to solve what ought to be a non-problem, ending up with mutually-incompatible, protocol-violating bodges - apex CNAME, ALIAS, etc. ANAME is an effort to unify these various approaches into a standards-compliant, portable bodge. Elegant it isn't, but if we don't standardize ANAME, the existing bodges will persist. Browser vendors want the DNS to give them addresses, and only addresses. If you can get them to change their minds, though, I wish you all success. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC7720 and AXFR
On Sun, Oct 28, 2018 at 11:05:17AM -0600, Grant Taylor wrote: > Does root zone local mirroring require that the zone comes from the > lettered root servers themselves? Or could it come from another server > with the root zone? Possibly a server that one or more operators set up > specifically for the purpose? You're right, it could, and I'd forgotten earlier that the appendix does also mention lax.xfr.dns.icann.org and iad.xfr.dns.icann.org. However, the root servers are the root servers. We all know A through M by heart, and resolvers have their addresses built in and kept up to date. Seems like a useful thing to leverage, if possible. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC7720 and AXFR
On Sun, Oct 28, 2018 at 01:32:51PM +0100, A. Schulze wrote: > RFC 2870 (Root Name Server Operational Requirements) say > > 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, > queries from clients other than other root servers. > > The update, RFC 7720 (DNS Root Name Service Protocol and Deployment > Requirements) don't even mention AXFR at all. All I found is > https://tools.ietf.org/html/rfc7720#section-2 > > o MUST implement core DNS [RFC1035] and clarifications to the DNS > [RFC2181]. > > Is AXFR a strict requirement for root-servers today? As a relatively new consideration, root zone local mirroring (RFC 7706) depends on at least a subset of root servers being able to provide the zone via AXFR. The configuration examples in the appendix specify B, F, G, and K. I've been assured by ISC folks that we'll always serve AXFR on F, but I don't know if that commitment is in writing, nor whether the other roots that currently support it have made any promises to keep doing so. IMHO it would be nice if all 13 letters provided AXFR service, but at a minimum we it's important for *some* of them to do so. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote: > Similar things can be said of other proposals. > > * If SRV for HTTP is brought into use, what about X% of user agents that > don't have support for it? > > * If a new RR type is introduced, what about X% of resolvers that do not > support it? They're no worse off than they already were. The old methods would still work just as well or badly as they do today. If apex CNAME were declared legitimate, then people using legacy resolvers *would* be worse off than they are now. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
ly do not like this but it seems better to think though > corner cases in code we already have in production (i.e. think through > current hacks for CNAME at apex) instead of inventing new things like ANAME > (or whatever else). > > Opinions? Tomatoes? Can it work? If not, why not? > > To me it seems it can work, and it sounds like a good idea. To relax DNS > protocol for CNAME to co-exist with other RR types, we'd need resolver > support, authoritive support and a time when it is practially usable. > > > > Adding resolver support (to resolvers that don't have it, i.e., vs. RFC > 1035) does not appear to break current DNS, i.e., it can be proposed > now. > > 1. When a resolver looks up a RR type in cache, and finds any positive > type match, it serves it. > > 2. If it does not find a positive type match, but finds a CNAME, it > looks for a negative cache entry for that RR type. > > 2.a. If a negative cache entry is found (or if it can synthesize one), > it returns/follows the CNAME chain. > > 2.b. If no negative cache entry is found (and it cannot synthesize one), > it starts a fetch for that type from upstream. > > 2.b.i. If the fetch returns a CNAME or NODATA, it means that the type > does not co-exist with CNAME in that node in the auth zone. The resolver > adds a negative cache entry for the type for the TTL of the returned > CNAME (or from SOA fields) to the cache, and returns/follows the CNAME > chain. > > 2.b.ii. If the fetch returns the type, it means that the type may > co-exist with the CNAME. The resolver adds a positive cache entry for > the type and returns the fetched answer. > > 2.b.iii. If the fetch returns NXDOMAIN, it overwrites the cache for that > node with a negative cache entry. > > > > Adding authoriative support would mean relaxing checks and allowing > CNAME to co-exist with other types except non-apex NS (parent of zone > cut), and perhaps allow CNAME and DNAME to co-exist too. > > For operators to be able to use it, they would need resolver support to > be available everywhere. I guess nothing stops a draft requiring > resolvers to implement support for it now. > > So +1. > > Mukund -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brief addition to terminology-bis draft
On Mon, Sep 10, 2018 at 09:48:05AM -0700, Paul Vixie wrote: > Andrew Sullivan wrote: > > ... > > > > I agree with Paul Vixie that classes were never defined well enough to > > be made to work properly, at least at Internet scale. > > this thread has further cemented my prejudice against CLASS. however, it > has also motivated me to define it well enough that we can create a > global "CHAOS" system, with very different zone cuts, which seems like > an idea bad enough to be good. This is not in any way an *urgent* consideration, but I do sometimes wonder what we (or, y'know, our grandchildren) are going to do if we ever run short of type codes. The obvious thing would be to expand into the CLASS field. Someone in the future might be grateful if we avoid making that too difficult. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On Mon, Jul 30, 2018 at 03:44:11PM -0700, Paul Hoffman wrote: > I am still mystified about the scenario in which a malicious zone > operator creates two zone files with the same ZONEMD hash, one with the > right set of addresses for unsigned child zones, and a different one > with one of more of those child zones with wrong addresses plus enough > other kruft to make the colliding hashes match. In what world is that > attack more likely than just not using ZONEMD? I don't think the imagined attack involves a zone operator creating two zones. It would be a zone operating creating one zone, with a legitimate and validly signed ZONEMD, and then someone else creating a fake version of the zone in which all the signed rrsets still validate, and the ZONEMD still matches, but the unsigned parts have been mucked with. Adding an RR count does make that attack more expensive. I'm not sure it makes enough difference to be worthwhile. Another imagined attack is someone trying to dump terabytes on you when initiate the zone transfer. An RR count could help with that, if you looked it up before starting the transfer. (For the record, I neither favor nor oppose the idea. I don't see much benefit, but I also don't see much cost.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On Mon, Jul 30, 2018 at 09:19:14AM +0200, Ondřej Surý wrote: > I know some people have 40Gbps at mothers house, but for general > usefulness you want to prevent downloading fake (or otherwise invalid) > zone before you start downloading it. While this does seem like a potentially useful feature, I don't think it's essential to the problem of verifiable root mirroring. "Nice to have", but not a requirement. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On Mon, Jul 30, 2018 at 11:03:25AM +1000, Mark Andrews wrote: > Actually it needs to be a type code. How do you hash the TXT RRset and > RRSIG(TXT) RRset when you need to modify both of them after computing the > hash? You need to be able to cleanly exclude the records from the ZONEMD / > XHASH calculations but have a indication that it is present in the zone > (NSEC/NSEC3 bit map). You omit the relevant TXT rrset (_zonehash./TXT, or whatever) when computing the hash for the remainder of the zone. Using a type code is obviously more convenient, but I could implement a zone verification hash without it and so could you. SO, ZONEMD only needs expert review. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On Sun, Jul 29, 2018 at 09:26:19PM -0400, John Levine wrote: > Well, heck, we could do the whole DNS with TXT records. No, not really - you couldn't do NSEC3 with TXT, for example. Or DNAME, or ANY, or lots of things. I'm just using "could I implement this with TXT?" as a proxy for whether it's a major change to the way the DNS works, or just a thing we can move forward on with expert review. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
On Sun, Jul 29, 2018 at 05:42:04PM -0400, Joe Abley wrote: > I also agree with Tim's observation the other day that if this is just a > new RRType, then expert review is all that is procedurally required and > it'd be a generous extension of what is required to document the > implementation and use of the new RRType in the RFC series. A good point. Technically, I don't think there's anything in ZONEMD that couldn't be implemented with TXT; using a dedicated rrtype for the purpose is mere convenience. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On Sun, Jul 29, 2018 at 10:55:31AM +0200, Ondřej Surý wrote: > You need to know the hash is valid before you start the download. > Therefore the hash has to be signed. Before you *start* the download? Or before you use what you downloaded? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] zonemd/xhash versus nothing new
On Fri, Jul 27, 2018 at 06:17:37PM -0400, Paul Wouters wrote: > we can do AXFR but that would keep the root servers mission critical. Also, the only currently practical channel security for AXFR is TSIG and it can't scale to hundreds of thousands of clients. Speaking as an implementer, I like AXFR from the traditional root servers as a method of distribution (despite the regrettable fact that half of them don't support AXFR; I wish they would). Reducing the root servers' central role isn't a major concern for me, and I don't think daily zone transfers from resolvers will overly tax them. The code's long-since implemented and mature and using it doesn't introduce a lot of new moving parts. However, the inability to verify a the correctness and completeness of a zone transfer (including the gluey bits) with an in-band signature *is* a problem. ZONEMD/XHASH solves it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
On Fri, Jul 27, 2018 at 11:24:33AM +0800, Davey Song wrote: > The draft says zone digest is not for protecting zone transmition. Where did it say that? I didn't notice it. > IMHO, the treat model is MITM attack by malicious editing on on-disk > data (NS and glue especially) and server the new zone to end user. DNS > digest intends to enable end users (resolvers) automatically detect the > modifation ( and drop the zone?). I don't think that's entirely correct. Normal resolvers don't need to transfer in a full zone; they just send queries for individual records and validate RRSIGs. There's no zone for for it to check against ZONEMD, or for it to drop if the check fails. However, a resolver configured with a local copy of the root zone as in RFC 7706 *does* contain the full zone, and has to get it somehow. Perhaps it gets it via AXFR, perhaps via some out-of-band mechanism. Either way, once the local copy is obtained, ZONEMD allows it to be verified. So, yes, ZONEMD does protect zone transmission. It does so regardless of channel - TLS, AXFR/IXFR, sneakernet, whatever. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote: > There's over 6000 service names defined for SRV. That's a lot of rrtypes. But HTTP/HTTPS is the one we have by far the most problems with. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On Fri, Jul 06, 2018 at 08:22:41AM +0200, Matthijs Mekking wrote: > Me too :) > > https://github.com/each/draft-aname/pulls Yes, sorry, my bad. I'll try to address the pull requests next week. Should've done ages ago. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On Sun, Jun 24, 2018 at 07:42:36PM +, Viktor Dukhovni wrote: > But that requires a new "XNAME" rrtype, whereas what the users want > is a more flexible CNAME that coëxists with other RRtypes. Ah. I didn't understand that you were proposing to reuse the CNAME rrtype for this. I think it would be impossible to make that work sanely with legacy resolvers. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On Sat, Jun 23, 2018 at 07:43:19PM -0700, Joe Abley wrote: > I think a pragmatic solution needs to work in unsigned zones. +1, but, an unsigned zone could still return an NSEC-style bitmap. It wouldn't be provably correct, but neither is any other unsigned response. You could actually add the bitmap to the XNAME rdata, instead of returning an NSEC. The XNAME could then mean "alias to for any rrtype not in ". Or you could turn it around, and have it mean "alias to for any rrtype that IS in ". Then you could have multiple XNAME records with different bitmaps, and forward different types to different names. That's kind of cool, but I suspect the benefits are outweighed by the camel burden. In any case, I don't understand how XNAME avoids the "ANAME kludges". Legacy resolvers won't know what to do with XNAME, so all the same workarounds on the auth side still must be implemented. Possibly even more of them, since XNAME responses might need to include answers for lots of different rrtypes, while ANAME is explicitly limited to A and . -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility
On Fri, Jun 22, 2018 at 10:26:55PM -0400, Warren Kumari wrote: > So, if I set both to use their (non-default) of SHA256 (and set the same > secret:-)) do they actually generate compatible cookies? > I'd guess / assume so, but I haven't tested this... That's the intention. Mukund recently pointed out a bug in the hash inputs BIND is using, so it might not work right now. We really should have a COOKIE bakeoff (worth doing for the pun alone) to check for interoperability issues. Montreal would seem like a good time and place for it, but I'm not going to be able to attend this time, so I can't volunteer to run it. If someone else wants to step in, that'd be great. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On Fri, Jun 22, 2018 at 03:18:43PM -0400, John R Levine wrote: > > Minor clarification here: ANAME doesn't require the authoritative server > > itself to do recursion; it requires it to have access to a reursive > > server. > > I suppose, but that seems to me a distinction without a difference. > Either way we end up importing all of the failure modes of a recursive > server into an authoritative one. I wasn't disagreeing about it being regrettable, I just wanted to nip in the bud any repeat of the argument that the auth server would itself have to be upgraded into a recursive server. The goal of ANAME is for the processing to be done on the resolver side. Addresses that are included in the authoritative response alongside ANAME should be ignored by the resolver and re-queried. But, for the benefit of legacy resolvers that don't know what to do with an ANAME, the auth would need to provide some sort of usable answer, which means it has to be able to look up addresses for the target name (whether it does that internally or via resolv.conf). It would be nice if that could be avoided, but there's no straightforward way. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility
On Thu, Jun 21, 2018 at 11:19:55AM -0400, Warren Kumari wrote: > There are a number of anycast clusters which run different > implementations on the same IP. Sure, but as long as the algorithm is settable for each server in the anycast so that all of them can match, then I don't think it matters if the different implementations have different defaults, does it? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On Tue, Jun 19, 2018 at 03:02:12PM -0400, John Levine wrote: > Agreed but it doesn't seem all that much less work than a well > specified version of ANAME, and it avoids the ANAME ugliness of making > authoritative servers do recursive lookups. Minor clarification here: ANAME doesn't require the authoritative server itself to do recursion; it requires it to have access to a reursive server. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested
On Sat, Apr 14, 2018 at 01:13:30AM +0800, Mukund Sivaraman wrote: > On Fri, Apr 13, 2018 at 04:31:35PM +0000, Evan Hunt wrote: > > I could have sworn there was an RFC published several years ago concerning > > the prevention of cache poisoning, which specified that resolvers had to > > ignore out of zone CNAMEs and re-query, but I can't find it now. Poor > > google skills, or did I dream the whole thing? > > RFC 2181 That was a "should", not a MUST. I thought I remembered something that upgraded it to MUST, but I can't find it now. It's possible I was thinking of RFC 5452 (which I now see was authored by the person whose question I was answering -- *this* is how you suck eggs, grandma). It says, "Care must be taken to only accept data if it is known that the originator is authoritative for the QNAME or a parent of the QNAME. One very simple way to achieve this is to only accept data if it is part of the domain for which the query was intended." This is less strongly-worded than what I remembered, but at least it does strongly hint that returning out-of-zone CNAMEs is likely to be a waste of effort. When we do the 1034 bis I'd like to see this made more explicit. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested
On Fri, Apr 13, 2018 at 05:11:52PM +0200, bert hubert wrote: > RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that > in step 2 we look up the best zone again for the target of the CNAME. I have > not looked if newer RFCs deprecate this or not. So with 'chase' I mean, > consult other zones it is authoritative for. There might be millions of > these btw, operated by other people. The search algorithm has been updated a few times (most recently 6672, I believe?) but AFAIK this phrasing remains in effect, and probably ought to be clarified in a future document. That said, it's up to you what zones you consider "available" in step 2, and there's no reason you can't limit the set of available zones to the ones that were in bailiwick for the original query, so you're not breaking any rules. I could have sworn there was an RFC published several years ago concerning the prevention of cache poisoning, which specified that resolvers had to ignore out of zone CNAMEs and re-query, but I can't find it now. Poor google skills, or did I dream the whole thing? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC localized validation
On Tue, Apr 10, 2018 at 11:32:18AM +0100, Tony Finch wrote: > Before the root zone was signed, [isc.org](https://www.isc.org) > created a mechanism called "DNSSEC lookaside validation", which > allowed "islands of trust" to publish their trust anchors in a special > `dlv.isc.org` zone, in a way that made it easy for third parties to use > them. To be clear, the zone didn't have to be dlv.isc.org. That was the DLV zone ISC provided, and there was a configuration short cut to make it easy to use, but it's always been possible to configure BIND to use a different DLV zone, including a local one. > Now that the root is signed and support for DNSSEC is widespread, DLV > has been decommissioned. But if we tweak it a bit, maybe it will gain > a new lease of life...? To be pedantic again, dlv.isc.org is decommissioned. DLV the protocol is still alive and well (for now). However... > I mentioned my localized DLV idea to Evan Hunt at IETF 101. I feared he > would think it is too horrible to contemplate :-) but in fact he thought > the use case is quite reasonable. I must confess I don't remember the conversation clearly (I may have been a jetlag zombie at the time), but I hope I warned you that in the interest of reducing code complexity, we've been talking about refactoring the BIND validator and stripping out the DLV code in a future release. Use cases like the one you're describing are the reason we've been uncertain about whether to proceed with that. I'd been assuming such use cases would be vanishingly rare. I may have been mistaken about that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
On Fri, Apr 06, 2018 at 10:09:50PM -0400, Warren Kumari wrote: > I think I heard that ISC was considering adding support, but was > planning on waiting till RFC / some sort of LC. Yes. The work in progress is available here: https://gitlab.isc.org/isc-projects/bind9/merge_requests/123 -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] raising the bar: requiring implementations
On Thu, Apr 05, 2018 at 01:31:37PM -0700, 神明達哉 wrote: > At Thu, 5 Apr 2018 13:46:29 -0400, > tjw ietf <tjw.i...@gmail.com> wrote: > > > What is work: An "informational" document being used as standard is people > > taking a submitted (expired) draft as "standard"? > > I'm not sure how to interpret it (not even sure if it's a question to > me)... I suspect Tim meant to type "What is worse: An 'informational' document being used as standard, or people taking a submitted (expired) draft as 'standard'?" To answer, I think which of those is worse depends on the implementation status. I don't have any problem with an informational document to explain the details of something that's already widely deployed, but which for whatever reason can't go through the standards process. Consider RPZ, for example: it's been implemented several times, there's lots and lots of real-world deployment experience. I'd be happy to see an informational RFC describing it; I'd be confident in its stability. Relying on old expired drafts would be disappointing. ECS, though, was published before it was fully cooked, and continuing to iterate and update the drafts would've been better. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-10 and AD
On Tue, Apr 03, 2018 at 06:32:49PM +1000, Geoff Huston wrote: > So this text is saying that the AD bit is set if the resolver considers all > RRsets in the Answer section to be authentic. Fair enough. More correctly, the bit is cleared if the resolver *doesn't* consider all RRsets to be validly signed, but the distinction probably isn't that important here. > What happens when neither DO nor AD is set in the request? "dig +noends +noadflag" will produce such a query, if you want to try it out. > Do you get a response that is authentic (but without any explicit signalling > in the response that would indicate that authentication has occurred) or the > Servfail response in the case where authentication fails? This. The resolver attempts validation and returns a plain-looking answer if the response was valid or provably insecure, SERVFAIL if bogus. > Or do you get a response that is not necessarily authenticated even though > the CD bit is not set? > > If its the former then the AD bit may or may not be set on responses even > though they have been "DNSSEC validated” That's correct. (Also the AD flag can easily be turned on or off by an intermediate proxy, so you should never rely on it for much of anything, really.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Verifying errata 5316 against RFC1034.
On Sun, Apr 01, 2018 at 01:33:17PM -0400, Warren Kumari wrote: > I'm also somewhat confused what the caching the wildcard answer > *means* - if I have *.example.com cached and then get a query for > foo.example.com I still need to query for it (note that this is all > before DNSSEC / Aggressive NSEC / etc) and so what is the "use" of the > cached wildcard? AFAICT, searching for the wildcard itself is only > useful for debugging, so caching it seems wasteful at best. It could also be wasteful not to. First, the resolver has to examine every name to see whether it's a wildcard before deciding whether to cache it, which has a small but non-zero cost. Second and more significantly, every time an explicit query for a wildcard name arrives, an iterative query must be sent to resolve it. I strongly suspect the reason the text was there was to prevent implementations from naively using a cached wildcard record *as* a wildcard -- i.e., synthesizing answers when there was a cache miss, instead of sending a query to the authority. As long as an implementation doesn't do that, I see no reason to worry about it. > Can folk help me understand what should happen with this errata? Errata, as I understand it, are meant to fix drafting errors, not correctly-expressed but wrong ideas. I agree with Mukund that the requirement shouldn't be there, but I'm not sure which class of error it is - bad writing or wrong thinking. If it was wrong thinking, then it calls for correction in a bis document rather than an erratum. Errata can be published an awful lot faster, though. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
On Mon, Mar 26, 2018 at 02:09:14PM +0200, Ondřej Surý wrote: > That’s one of the goals of the document - saying: “it’s ok to not > implement those RR Types, and it’s ok to break if you receive them" We need to state clearly what is meant by "ok to break". I described my preferred approach as an implementer upthread. Let me state it again more formally and let people knock it down: 0. types will be flagged as obsolete/deprecated in the IANA registry, and the following guidance is given to DNS implementors in the handling of obsolete/deprecated RR types: 1. auth servers SHOULD log a warning when loading zones that contain obsolete/deprecated rrtypes. 2. responders SHOULD NOT compress rdata when rendering obsolete/deprecated type records to wire format. 3. queriers which receive obsolete/deprecated type records MAY interpret them as unknown type records (rfc 3597), and MUST NOT interfere with their transmission. 3a. note that the choice to parse obsolete/deprecated MAY be contingent on whether the rdata is compressed: an obsolete type record MAY be parsed as a known type if its rdata is uncompressed, but as an unknown type otherwise. 4. validators and signers SHOULD treat rdata for obsolete/deprecated types as opaque with respect to canonical RR ordering and deduplication -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
On Sun, Mar 25, 2018 at 02:19:56PM +0100, Paul Hoffman wrote: > except that, if some implementer reads this document as meaning that > they don't have to handle the listed RRtypes in any special way, they > could get nailed when interoperating with implementations that handle > the compression correctly. I'm not sure that's a major concern though. If you receive an MB RRset and you don't implement that type, or if you do but your impelementation assumes the rdata won't be compressed and it is, then you could just treat it as an opaque TYPE7 RRset. We do have experience with interoperation between servers that implement different sets of rrtypes. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt
On Sat, Mar 24, 2018 at 06:48:35AM -0700, Joe Abley wrote: > I'm actually surprised to see that support for rarely-used RRTypes is > really upsetting the camel. It's an interesting object lesson in the complexity of unloading camels, though. (Perhaps it's time to add something about "the eye of a needle" to our camel metaphor.) > A combinatorial explosion of annoying workarounds for the inability of > middleboxes or upstream authority servers to implement EDNS(0) > properly seems like a much more plausible camel irritant to me. I'm > sure there are many more like that. Wholeheartedly agree, and efforts to address this are under way. > I can see why you could strip out lines of code by eliminating the > need to parse the canonical formatting of WKS and friends, but I'm > surprised that it's a notable source of complexity. It is, after all, > complexity that I heard is causing the camel strain, not just lines of > code. > > If future-BIND stops parsing an archaic RRType that I happen to use, > I'm going to have to change whatever code or processes that depend on > it. Maybe someone (ISC, even) is going to publish a filter that will > turn all the old RRs in canonical syntax into TYPE representation, > and back again. New RRTypes might then need to get implemented in both > BIND (because presumably they are camel-friendly) and also in the > filter or filters, because perhaps we are targeting multiple > nameserver implementations with our zone file. > > This all sounds like we're just sharing the complexity around. It > doesn't sound any simpler. Maybe it's a silly example? I don't know. > Could be. But I think brushing the grains RRType parsing dust off the > camel is not going to do much for its posture. I think it would help if there were more clarity on what exactly is being proposed, other than adding the words "obsolete" or "deprecated" to a list of RRtypes on a website somewhere. The draft didn't seem to have particularly clear guidance to implementers. These RR types have text representations and wire format representations, which from a complexity standpoint seem quite harmless to implement. There are the old annoying rules about name compression and sorting, which do add some complexity, but are already implemented in all the existing codebases. I don't see how the IETF can mandate that they be removed, nor am I sure it's particuilarly worth doing. We can make them optional to implement in the future, though. Perhaps that's all Ondrej has in mind? (With respect to BIND, if these types are declared obsolete by the working group, then my inclination would be to a log a message saying so if you tried to load them in a zone, same as with SPF. In a future relase I might start treating them as opague types when rendering to wire format, but would probably retain the ability to parse them and display them as text.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-spacek-edns-camel-diet-00.txt
On Wed, Mar 21, 2018 at 08:17:08PM -0400, Matthew Pounsett wrote: > Congratulations on an extremely short, to the point draft. I think that's > the shortest I've ever read. Indeed! I hesitate to offer trivial rephrasing suggestions because it might represent such a significant percentage of the final text you'd have to give me co-author credit. :) That said, however, "No response...means" is ambiguous: it could be read as "[there is] no response [which] means". So I suggest rephrasaing section 2 as: The failure of a server to respond in any way to repeateded DNS queries containing EDNS OPT records indicates that the server is not a DNS responder. The querier MUST treat this server as nonresponsive, and MUST NOT retry queries without EDNS. Or something like that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Terminology question: split DNS
On Mon, Mar 19, 2018 at 05:58:08PM +, Ted Lemon wrote:
> Yeah, that's a bit iffy. Homenet is another example of the same thing.
> I would make it more generic, something like this:
>
> Where DNS servers that are authoritative for a particular set of domains
> provide partly or completely different answers in those domains depending
> on the source of the query. The effect of this is that a domain name that
> is notionally globally unique nevertheless has different meanings for
> different network users.
This might be a little *too* generic: it appears to cover things like
geographically tailored responses and EDNS Client-Subnet, as well as
the internal and external views that are more typically what
"split[-horizon] DNS" refers to.
At a technical level there may not be much difference, but I've always
thought of "split DNS" as being specific to the boundary point between an
organizational intranet and the global internet. It's my impression that
historically most people who've used the term meant it in that sense, and
it might be confusing to broaden the definition retroactively.
I do think the text above is useful, though. I would suggest that, as there
are now several situations in which DNS responses may differ depending on
the client, would could define a generic term for that ("multi-horizon DNS"
or similar?), and then define "split DNS" as a specific case in which the
answer depends on whether the originating client is inside or outside of a
network controlled by the server's operator.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Please review the definitions around "recursive" in terminology-bis
Yes please. I'd start off by noting that "recursive" (like "resolver") is used in several different ways and a single clear definition isn't possible. "Recursive mode" is currently defined as "receiving a query and then either answering from a cache or sending a query to other servers" -- which seems overly broad to me; it could include a caching forwarder, which isn't what I think of as "recursion", though of course others may differ. The RA and RD bits are defined as "recursion desired" and "recursion available", which at least implicitly suggests that "recursion" means whatever a server does in response to those bits. RFC 1034 discussed "recursive" and "iterative" as separate and distinct concepts in distributed database design... but the DNS uses an iterative process to implement recursion. A "recursive resolver", "iterative resolver", and "full resolver" are pretty likely to be the same thing. (This isn't very clear from the definitions of either "recursive mode" or "iterative mode" in the current text, btw. See the terminology section in RFC 4697.) I don't think any one explanation can meaningfully reconcile all of these; I think we need a list of possible meanings, and maybe a Venn diagram, discussing the various shades of meaning in "stub", "recursive/recursion", "iterative/iterating", "forwarder/forwarding", "validator/validating", "cache/caching", and "resolver", so that there's a good chance someone can guess at the meaning when several of those words are chained together, as they often are. I don't have any text to offer at the moment, but I'll give it some thought. On Mon, Mar 12, 2018 at 08:09:27AM -0700, Paul Hoffman wrote: > Greetings. The definition of "recursive resolver" has been problematic > both in RFC 7719 and in draft-ietf-dnsop-terminology-bis. Section 6 of > draft-ietf-dnsop-terminology-bis defines a bunch of terms about servers, > including "recursive mode" and "recursive resolver". The current text > gives: > > Recursive mode: A resolution mode of a server that receives DNS >queries and either responds to those queries from a local cache > or >sends queries to other servers in order to get the final answers >to the original queries. Section 2.3 of [RFC1034] describes this >as "The first server pursues the query for the client at another >server". A server operating in recursive mode may be thought of >as having a name server side (which is what answers the query) > and >a resolver side (which performs the resolution function). > Systems >operating in this mode are commonly called "recursive servers". >Sometimes they are called "recursive resolvers". While strictly >the difference between these is that one of them sends queries to >another recursive server and the other does not, in practice it > is >not possible to know in advance whether the server that one is >querying will also perform recursion; both terms can be observed >in use interchangeably. > > Recursive resolver: A resolver that acts in recursive mode. In >general, a recursive resolver is expected to cache the answers it >receives (which would make it a full-service resolver), but some >recursive resolvers might not cache. > > That is, "recursive mode" is only barely defined in RFC 1034, and > "recursive resolver" is defined almost trivially. > > Can these be improved on? This is one of the core ideas in the DNS > protocol and it seems a bit weird that we don't have a crisp set of > definitions. If there is more text from RFCs to quote, that would > possibly be a big help. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
On Sat, Feb 03, 2018 at 12:20:34PM +0100, Stefan Bühler wrote: > This advise suggests that if the auth server has access to the zone's > private key and can sign responses on the fly, ANAME works with signed > zones. > > But it doesn't! Because ANAME-aware recursive resolvers will replace > the signed records with unsigned ones. No, an ANAME-aware resolver would ignore those records, re-query for the ANAME target, and validate the response from there - same as it does now with a CNAME. As long as the ANAME is validly signed, it's just a chain query. > I'd also suggest to relax the "MUST re-query" requirement if the > resolver used ECS - because it means the auth server had a good chance > to respect the network topology (this is unrelated to signed zones). It's the same requirement as for CNAME. Putting full trust in a chain returned by an auth server risks cache poisoning. (Not even necessarily malicious; the auth might simply be serving information that's outdated.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
; > will not be sufficient for DNSSEC validation. > > Does this say anything useful at all? There is nothing ANAME specific > here. I suggest removing this as well. > > The "which do not yet implement ANAME" is confusing at best. Resolvers > having implemented ANAME will be equally unable to validate unsigned A > and responses included with an ANAME response. It's meant to explain the reasoning behind the requirement, which some other readers found confusing. To put it more correctly, validating resolvers which don't implement ANAME won't know that they shouldn't bother validating these addresses, so validation will fail unless the signatures are replaced by the ANAME zone. I'll try to clarify. > I agree with Richard Gibson that the zone transfer considerations merit > their own section. This has nothing to do with DNSSEC. > > The synthesized A and RRs are treated as authoritative dynamic > records, and DNSSEC, serial number calculation, zone transfers etc > should simply follow the normal rules for such records. Please don't > define rules allowing slaves to serve different content for the same > serial number. > > The TTL handling rules also need to be split out of the DNSSEC section. > These rules should not depend on the zone being signed or not. Noted, I'll consider this. > >When ANAME is present in a signed DNS node and address records exist > >at the ANAME , the type bit map in the NSEC [RFC4034] or > >NSEC3 [RFC5155] record for that node MUST include bits for A and/or > > as well as ANAME. This is for the benefit of validating > >resolvers not implementing ANAME which may use a signed proof of > >nonexistence for type A and to prevent address queries from > >being resolved. The type bit map SHOULD only include address types > >which are known to exist at the . > > This is confusing. Won't the type bitmap have to be correct for *any* > validating reolver, including those implementing ANAME? Or are they > supposed to modify it? If so, how? Again, this is meant to explain the reasoning behind the requirement. If the bit map indicates the absence of A/ but the resolver is ANAME-aware, then it won't matter - we'll chase the ANAME target and get the answer we wanted, the same as with CNAME. But if the resolver is *not* ANAME-aware, we don't want it to look at a cached NSEC, see the missing A and bits, and decide not to send a query. > > 4. Recursive Server Behavior > > > >When a recursive resolver sends a query of type A or and > >receives a response with an ANAME RRset in the answer section, it > >MUST re-query for the ANAME . This is necessary because, in > >some cases, the address received will be dependent on network > >topology and other considerations, and the resolver may find a > >different answer than the authoritative server did. (This > >requirement MAY be relaxed if both the ANAME and are > >validly signed and provably in the same zone.) > > > >If resolution fails -- for example, due to the local resolver being > >nonfunctional or the ANAME zone being unreachable -- then > >the resolver MAY use the address records that were included in the > >authoritative response as a fallback. Otherwise, these records MUST > >NOT be cached or returned. > > This section needs a DNSSEC discussion. It seems to be written under > the assumption that a recursive server can modify the answer. This is > bogus, and you should know that. I must have phrased it badly, but I'm not sure how to improve it because I don't see where you're seeing that assumption? > Please solve the following problems: > > 1) authoritative server answers an A query with with NSEC, ANAME, A, > and valid RRSIGs for all three RRsets. The recursive server > implements ANAME and does further processing of it, replacing the A > RRset. What RRSIGs should it send to clients setting 'DO'? > > 2) autoritative server answers an A query with NSEC + ANAME with valid > RRSIGs, but no A or RRsets. The recursive server implements > ANAME and does further processing of it, adding an A RRset to the > answer. What RRSIGs should it send to clients setting 'DO'? Some thought required, I'll come back to this. Thanks very much for the comments. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
> I have concerns about the resolver replacing A/ records in signed > zones as it breaks validation. What do you mean by "the resolver" in this case? > If a resolver understanding ANAME is queried using the DO=1 flag it > shouldn't touch the A/ records, because it already knows the > requestor would through them away. It doesn't *know*. DO=1 doesn't mean the client is validating; it means the client understands RRSIG. The draft already advises that ANAME will break validation unless the validator is ANAME-aware or the auth server has access to the zone's private key and can sign responses on the fly. (This suggests to me that the use of ANAME in signed zones will probably be limited at first.) > This also means a caching resolver should store the original A/ > records (and not the ones resolved through ANAME) in the cache. Certainly. > With this change I don't think it makes sense to say "a resolver MUST > re-query", I'd use "a resolver SHOULD re-query if it didn't use ECS and > the query didn't use DO=1". I'm sorry, I'm not getting this. Please explain further, particularly with an expansion of the word "it"? > But I'd add "a resolver MUST include ANAME > RRset in respones to queries for A/". Yes, I'd been assuming it would. If I forgot to mention it in the draft, I'll fix that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
On Thu, Jan 25, 2018 at 11:51:30PM +, Wessels, Duane wrote: > As an example, consider an ANAME record with TTL 3600 and a corresponding > record with TTL 86400. You'd want the to expire no later than the ANAME did, because the ANAME might have been updated to point to some other name by then. > I'm suggesting its just as acceptable to return the record with TTL > counting down from 86400, but after 3600 seconds it is ejected/marked > stale/whatever from the ANAME-implementing authoritative server. > > Unbound does that with its cache-max-ttl setting. > > If you do it this way then the consumers of the data (including > ANAME-unaware clients) get to cache it for the original TTL. That's exactly what I'm trying to prevent. With an ANAME-aware resolver, the address returned by the auth is ignored, the resolver chases the answer for itself, and records are all cached with their original TTLs. The ANAME answer and the target answers expire when they should, just as with a CNAME now. In your example, the ANAME expires after 3600 seconds, so we re-query to refresh it. If it's changed, then we follow it to get a new , but if it hasn't changed, then since we already have the cached, there's no need to chase it again. But with an ANAME-unaware resolver, it asked for an address, got one, and will cache it for whatever TTL you sent it. If your ANAME has a one-hour TTL, then you wouldn't want to send a higher TTL than that; you'd just overriding the ANAME TTL. > It seems to me that ANAME gives auth servers resolver-like properties, so > why wouldn't that apply there as well? Yes, fair point. I'll try to come up with text to address this. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
On Thu, Jan 25, 2018 at 10:05:24PM +, Wessels, Duane wrote: > Why does the draft mandate initial TTL behavior? The important aspect > would seem to be how long the data can be kept in cache, not what the > (initial) TTL value is. As I noted in the previous message, Unbound's > cache-max-ttl works that way and I think it has some nice properties. I'm not sure I understand the distinction you're making. When you first cache something, its TTL represents the length of time that data can be kept in the cache, and it counts down from there to zero. That's what I meant by the initial TTL. > Also in this new text I'm not sure what to make of "intermediate and address > records." If "and" is truly intentional in this phrase then I think > intermediate should be better defined, or examples given. Suppose ANAME (TTL 3600) points to a CNAME (TTL 30) which points to a CNAME (TTL 5) which points to an A (TTL 86400). The response would contain ANAME with TTL 3600 and, because of the intermediate CNAME, A with TTL 5. Suggestions welcome for a clearer way to phrase this. > >Address records with expired TTLs MUST NOT be used to answer > >address queries until refreshed by sending a new query to the ANAME > >. > > > > [...] > > > >If resolution of the ANAME yields no address records due to > >some other failure, and the query was for a specific address type, > >the response MUST include the ANAME record and set the RCODE to > >SERVFAIL. > > If the authoritative server has address records, which then expire, and > cannot be refreshed, I read this as saying the later response must be > SERVFAIL. For A or queries, that is the intent. An explicit query for type ANAME would still be answered. > That seems in contradiction with the ideas of draft-serve-stale which says > "stale bread is better than no bread" and "Several major recursive resolver > operations currently use stale data for answers in some way ... Their > collective operational experience is that it provides significant benefit > with minimal downside." This seems like a job for the resolver, not the auth server. In the long term my hope is that resolvers will implement ANAME, chase the answers themselves, and then decide whether to serve stale records or not. However, I guess we can relax this requirement if the auth server is configured for serve-stale. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Tue, Jan 16, 2018 at 03:33:11PM -0500, Bob Harold wrote: > That sounds clear and complete to me! +1 -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Wed, Nov 29, 2017 at 07:25:53AM -0500, Andrew Sullivan wrote: > How about, "This kind of response is not required for resolution or > for correctly answering any query, and in practice some authoritative > server operators will not return referral responses beyond those > required for delegation"? Up to the comma looks fine. The part after the comma strikes me as over-wordy, and I suggest "and there is no requirement that authoritative servers send them". -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
> "Not strictly speaking required to work" was intended to observe that, > if you didn't get a referral under this condition, nothing ought to > break (or, if it did, it was already broken). I think the phrasing is unclear because "this response is not required to work" is ambiguous. The response *itself* doesn't have to work? Or the resolver can get along without this response? I took it to mean the latter, but I see how it could be confusing. I'd suggest something like "this response is not strictly speaking necessary, as it provides no information the resolver didn't already have; resolution can succeed without it." -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Tue, Nov 14, 2017 at 12:21:11AM -0800, Paul Vixie wrote: > i mean propagating REFUSED back to the stub so that it can return an > error to its application or user. Okay. I haven't encountered a resolver that propgates REFUSED from the authority to the stub. If there is such a beast, then IMHO that, not the authority, is the one that's mis-using REFUSED; REFUSED only makes sense on a hop-by-hop basis. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote: > while specific guidance was not given as to resolver action in response > to each possible authority RCODE, i have both witnessed and implemented > full resolvers which treated REFUSED as a permanent failure whereas > SERVFAIL was a temporary failure. What do you mean by "permanent" in this context? As far as I know, BIND treats REFUSED as persistent during the resolution process -- i.e., it won't bother to retry the same server with the same query immediately. It would go to the next delegated name server, and if all servers refused, eventually it would return SERVFAIL to the client. It might add the address to a bad server cache; I'm not actually sure whether it does that in this scenario, I'd have to check. If it does, that would keep it from retrying the server for 30 minutes, which is a reasonable recovery time for the "haven't caught up with my inbox" class of error. > treating "i don't have the zone configured" as a REFUSED condition, > while treating "i can't write the secondary zone" or "i can't read the > primary zone" as SERVFAIL conditions, adds no value, but does subtract > it. I'm not seeing the value subtracted. In those two cases, your server knows that it's *supposed* to be authoritative for the zone in question, and that there's a problem preventing it from answering. This fits the definition of SERVFAIL, "unable to process this query due to a problem with the name server", and the other case doesn't. > usually when i don't have a zone configured that is delegated to me, > it's because i have not caught up with my inbox, or i have FUBAR'd my > configuration file using "git" or similar. in those cases, the name > being looked up _might exist_ and retrying later _might succeed_. Or, very likely, the parent zone is misconfigured or out of date, in which case the name doesn't exist and retrying later won't sucseed. Perhaps you run a secondary name service and your customer hasn't paid the bill, or they're in the process of switching to a new provider, or they just put in the wrong glue. Your server isn't failing; it's just being asked for a name it never heard of. > i have heard a number of folks argue that this logic is common, but i > have heard noone argue that it is superior to known alternatives. can we > hear someone who is in favour of this for reasons beyond "five million > frenchmen cannot be wrong"? I wish NOTAUTH had been defined in 1035. Since it wasn't, there are only three answers that make any sense: NOERROR with upward referral, SERVFAIL, REFUSED. We already disposed of upward referral. SERVFAIL gets you spurious retries. REFUSED makes the querant go away for a sensible amount of time; we have ten years of operational experience with it. I don't see the problem. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)
On Tue, Nov 14, 2017 at 09:16:43AM +1100, Mark Andrews wrote: > Remember the draft was designed to handle ALL record updates to the > parent zone after being approved by the registrar in a unified manner. > NS, DS, A, DNAME, , TXT, CNAME, etc. This isn’t restricted to DS > records. In the present context, I was only suggesting this method be used for NOTIFY, not UPDATE -- to signal the parent that it should poll the child for CDS/CDNSKEY. (I guess CSYNC could be included in the mix as well, though, for updating NS and glue.) I would suggest the child should be polled periodically regardless. If the SRV record were spoofed, causing the child to send a NOTIFY to the wrong address, synchronization should still occur, just not as quickly. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On Mon, Nov 13, 2017 at 11:12:52AM -0800, Matthew Pounsett wrote: > I haven't got the time this morning to search release notes, but I'm fairly > sure that in 2012, when you wrote that article, current versions of BIND > were already handing out REFUSED to indicate "I'm not authoritative for > that." At the very least it began doing that not long after. That became the default behavior in 9.4.2 in Nov 2007. (It was documented in 9.4.0 in Feb 2007, but there was a bug in how the default setting was applied.) The relevant change was the addition of the allow-query-cache ACL. The REFUSED rcode in this case doesn't mean "I'm not authoritative", it means "you're not allowed to look in my cache to see the root referral I would've sent otherwise". It'd be nice if we could use NOTAUTH for this, but that rcode didn't exist when the spec was written. REFUSED isn't an exact fit, but it's legal, sensible in context, and gets the job done. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)
On Mon, Nov 13, 2017 at 03:19:23PM +, Tony Finch wrote: > It seems to me that a reasonable in-band mechanism would be to send a > NOTIFY to the parental agent. I can only find a little discussion of this > idea in 2014, and it wasn't very enthusiastic - there were questions like, > how do you know where to send the NOTIFY? On the other hand there are > similar questions about how you would make an out-of-band request. Mark's idea to push updates to the parent instead of relying on polling used a SRV query to identify the correct recipient of an UPDATE: https://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-04 The same trick could be used to find the right NOTIFY target. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?
> I see that this draft uses a syntax similar to RFC 8145 Trust Anchor > Telemetry RFC (which uses _ta-) albeit without the leading > underscore, i.e. .ta-. > > I'd like to propose instead ._ta. > > This would allow _ta to be registered as a standalone entry in the > underscore label registry, whilst also avoid the risk of collisions with > "plain" labels that happen to match ta- > > FWIW, I think in retrospect that RFC 8145 should have taken a similar > approach too. IIRC we discussed it, and were concerned that _ta. could be cached as nonexistent by servers implementing QNAME minimization. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt
On Thu, Sep 21, 2017 at 02:20:15PM +0200, Peter van Dijk wrote:
> thank you for this, I like it a lot. One nit below.
Me too, with another nit...
> > This creates a kind of confusion, however, because the answer to a
> > query that results in CNAME processing contains in the echoed
> > Question Section one QNAME (the name in the original query), and a
> > second QNAME that is in the data field of the last CNAME. The
Why only the "last CNAME?" If a chain contains more than one CNAME, the
answer includes intermediate names as well:
;; ANSWER SECTION:
www.paypal.com. 5 IN CNAME geo.paypal.com.akadns.net.
geo.paypal.com.akadns.net. 5IN CNAME wlb.paypal.com.akadns.net.
wlb.paypal.com.akadns.net. 5IN CNAME www.paypal.com.edgekey.net.
www.paypal.com.edgekey.NET. 5 IN CNAME e3694.a.akamaiedge.net.
e3694.a.akamaiedge.net. 5 IN A 104.91.181.63
> > QNAME (effective) The name actually resolved, which is either the
> > name actually queried or else the last name in a CNAME chain as
> > defined in [RFC2308].
This does match the use of the term in RFC 2308, but in other contexts,
I think it would be better to expand it to include intermediate names:
"A name actually resolved, which is either the name originally queried,
or a name received in a CNAME chain response."
RFC 2308 is interested in caching of answers after recursion is done,
but if one were discussing the recursion process itself, this would be a
natural term to use for itermediate names. ("If the response is a CNAME,
update the effective QNAME to the CNAME target and go back to step 2...")
If it's necessary to have a specific term that only refers to the *last*
name, perhaps "QNAME (final)" would be a better choice for that.
Incidentally "CNAME chain as defined in [RFC2308]" is ambiguous. RFC
2308 has a definition of QNAME that includes the last CNAME in a chain,
but it does not define the term "CNAME chain".
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)
On Sat, Sep 09, 2017 at 08:29:28AM -0700, Paul Vixie wrote: > rpz is a defense. it assumes that the content owner is trying to hurt > me. it is therefore one step away from being an attack, and is in any > case, not an attack. Sure. And TTL stretching assumes the content owner is a fellow victim, and someone is trying to hurt both of us by making their site inaccessible to me. Both are lies; both have a defensible moral justification. > i think that attack-p is more relevant than lie-p for this discussion. The line between attack and not-attack can be surprisingly blurry. But given that there are non-malevolent reasons for wanting to serve stale data, and solutions are being implemented (including one in BIND), I'm okay with publishing details of the method, same as with RPZ. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)
On Fri, Sep 08, 2017 at 06:43:52PM -0700, Paul Vixie wrote: > not so fast. nxdomain redirection is an attack. censorship is an attack. > i don't think you mean to group ttl stretching in with those attacks. > because if you do, then we agree, it is an attack, and ought not be > done, and certainly ought not be standardized in any form. They're both lies, and TTL stretching is a lie, and in principle I believe the DNS should not lie, but filter- and dns64 and RPZ all had good and worthy reasons, and nxdomain redirection had bad reasons with dollar signs next to them, and here we are. Just as with RPZ, it seems reasonable to publish guidance on how to do the kind-of-bad thing in the least bad way. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] opportunistic semi-authoritative caching (Re: DNSOP Call for Adoption - draft-tale-dnsop-serve-stale)
On Thu, Sep 07, 2017 at 10:28:30PM -0700, Paul Vixie wrote: > if they really need this, they should provide a method by which i can specify > both a TTL and an Expiry, and i will consider publishing both values, and > if i do, then they can use them the way i intend them. because as i said, > autonomy. it's my data, and my TTL. I agree, and yet, a DDoS can make your data unavailable for refresh through no fault of yours, which makes a resolver operator appear to be broken through no fault of theirs, which makes them want very much to be able to do this bad thing. So, TTL stretching goes on the pile with NXDOMAIN redirection, tools that can be used for censorship, and all the other regrettable things that we implemented anyway dammit. (I do like the idea of advertising a separate expiry value though.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error
On Mon, Jul 31, 2017 at 09:57:11AM -0400, Paul Wouters wrote: > But we know people are already building software and systems that DO > trust the AD bit, even with non-localhost resolv.conf entries. This > saves them the overhead of adding a dnssec library to their application, > and saves them from running a system resolving understanding dnssec. Are there applications specifically trusting AD=1 and behaving differently than with AD=0? Or are they just ignoring it and trusting every answer equally? I would have expected the latter, but I confess to being surprised if there are people going out of their way to implement "DNSSEC validation" by just buying whatever magic beans some dude in the forest has for sale. > > Some of the error codes might be trustworthy enough if you're using COOKIE > > or TCP; that would enusre at least that it wasn't an off-path forgery. > > That's a very small use case with pervasive monitoring and > coffeeshop and hotel wifi. In case I wasn't clear, I'm suggesting that TCP and COOKIE would be adequate protection for any error code where the worst case scenario is no worse than what any MITM can do. If you've already got control of the channel, then I can't see how sending the client "Prohibited" or "Lame" messages gives you any more of an advantage than you already had. However, any response that says anything about DNSSEC validity should be presumed guilty until proven innocent. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error
On Sat, Jul 29, 2017 at 10:04:06AM -0400, Joe Abley wrote: > If client behaviour is not supposed to change when you return > an extended RCODE, why bother returning one? It's clearly helpful for human debugging. But, yes, you're correct -- diagnostic information included with a SERVFAIL is about as trustworthy as the AD bit, and in the absence of an authentication mechanism such as TSIG, clients should not rely on it or base policy on it. Some of the error codes might be trustworthy enough if you're using COOKIE or TCP; that would enusre at least that it wasn't an off-path forgery. The ones related to validation I wouldn't trust without a signature, though. This should be spelled out in more detail in the security considerations. (And, considering I'm listed as a co-author on this draft, maybe it's time I earn my keep and submit some text...) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On Wed, Apr 19, 2017 at 10:47:24PM -0400, Paul Wouters wrote: > ANAME could just be a regular RRTYPE without any special handling, > meaning "go look there for up to date information on A/". It could > come along A/ records using one of the existing bitmaps multi-type > query proposals that have been suggested in the last two years. But, because there are always going to be legacy servers, the client would then need to send an ANAME query, and when it got no answer, send another query for A and . If clients were willing to do that, then they'd have been willing to use SRV, and we'd have standardized on that long since. Which would've been fine, but browser vendors have had years to do it, and they never have. Apparently, what they want is to send address queries and get redirected answers. And if we can't make them do the smart thing, at least we can give them an interoperable and standards-compliant way to do the dumb thing. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On Tue, Apr 11, 2017 at 10:20:31PM +0200, Florian Weimer wrote: > And in order to accommodate them, we upgrade the DNS server > infrastructure across the Internet? Them, and web browser implementers who just don't want to use SRV. We did the best we could to ensure it can be deployed gradually, though. The domain that wants to redirect apex addresses can implement ANAME, and its clients will get answers. Resolvers that want better answers can do that too. Forklift not required. > I understand that's how things work in practice, but I don't like it. So say we all. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On Tue, Apr 11, 2017 at 10:21:13PM +0200, Florian Weimer wrote: > But what happens when the target server also performs cache filling at > the same time? If two servers end up being unable to populate their address records because they're depending on each other for answers, then you end up with two servers that both return SERVFAIL on address queries. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote: > I don't see how you can detect loops without DNS protocol changes. The > query that comes back will look like a completely fresh query. We can put a limit on the number of hops that are followed in populating the A and records for the expanded ANAME response. If that limit is exceeded, the ANAME record could be rejected by the auth; either the zone wouldn't load or address queries return SERVFAIL. BIND already has a limit of 16 hops for CNAME loop prevention. I assume other resolver implementations must do something similar. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On Sat, Apr 08, 2017 at 06:32:12PM -0400, Paul Wouters wrote: > > Resolvers don't ask for ANAME. They ask for A/, and get an A/ > > answer, along with an ANAME record so they can go directly to the source > > and get a better answer if they support that. > > If these are the premises for ANAME, and its special handling, wouldn't > it be better to generalise asking for multiple records (eg A + > + ANAME) where ANAME has no special handling on its own? And then do the > generealised multi-query-at-once using one of the previously suggested > proposals? I must have been unclear -- I meant the slash to mean "or". This isn't about getting back multiple records. I did include a MAY in there saying that if you query for an A you can get in the additional section, and vice versa, but that's not the central point of ANAME at all. This is a mechanism for redirecting address queries. Because it's limited to address types, it can, unlike CNAME, be used at the zone apex. So the initial query is going to be for type A or type . (If we ever invent a third address family, that would count here as well.) The response is going to be an ANAME record plus the address you asked for. That address has to be looked up by the auth in case the querying resolver doesn't have ANAME support, but if the resolver *does* have ANAME support, then it repeats the lookup on its own behalf, just as it would do if it got back a CNAME. > Then people who want to ask (A + + TLSA) or (A++SSHFP) or > (A++IPSECKEY) could use the same mechanism. And ANAME would just be > a regular DNS record without any abnormal processing. Fine idea but not related. ANAME == CNAME for addresses. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
Hi Paul, On Fri, Apr 07, 2017 at 05:16:14PM -0400, Paul Wouters wrote: > When a recursive resolver sends a query of type A or and > receives a response with an ANAME RRset in the answer section, it > MUST re-query for the ANAME . This is necessary because, in > some cases, the address received will be dependent on network > topology and other considerations, and the resolver may find a > different answer than the authoritative server did. > > That opens up a whole can of worms :P We start with the problem of > "we need addresses at the APEX be non-static, but then you add logic > to support that and then it is not good enough for the job. AUTH servers > already know how to return split view answers with various > implementations based on geolocation, edns-subnet or what not. The hope here is that, in the long run, ANAME resolution would be the job of the resolver, which in in a position to get the best answer for its clients, given geolocation and topology considerations. Expansion of ANAME on the authoritative end is a workaround for the fact that we can't go back in time and put ANAME support into all the resolvers. > But really, what it comes down to for me is that if you are adding logic > to the AUTH nameservers to synthesize ANAME into A/ records, why bother > ever sending ANAME over the wire? Just let clients send A/ and never > ask for ANAME. Resolvers don't ask for ANAME. They ask for A/, and get an A/ answer, along with an ANAME record so they can go directly to the source and get a better answer if they support that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
Greetings, Here's the new ANAME draft I mentioned last week. This is similar to existing non-standard approaches (ALIAS records, CNAME-flattening, etc) but also sends the ANAME record to the resolver so that, if the resolver understands the ANAME type, it can re-query for the answer just as it would with a CNAME. Please have at it. - Forwarded message from internet-dra...@ietf.org - From: internet-dra...@ietf.org To: Evan Hunt <e...@isc.org>, Peter van Dijk <peter.van.d...@powerdns.com>, Anthony Eden <anthony.e...@dnsimple.com> Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt Date: Fri, 07 Apr 2017 11:04:39 -0700 A new version of I-D, draft-hunt-dnsop-aname-00.txt has been successfully submitted by Evan Hunt and posted to the IETF repository. Name: draft-hunt-dnsop-aname Revision: 00 Title: Address-specific DNS Name Redirection (ANAME) Document date: 2017-04-07 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-hunt-dnsop-aname-00.txt Status: https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/ Htmlized: https://tools.ietf.org/html/draft-hunt-dnsop-aname-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hunt-dnsop-aname-00 Abstract: This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only redirects type A and queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to redirect queries for apex domain names in a standards compliant manner. 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. The IETF Secretariat - End forwarded message - -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for ALIAS/ANAME type
On Mon, Apr 03, 2017 at 03:48:49PM -0400, Paul Wouters wrote: > As Evan said, there should not be any code in an authoritative server > that requires it to do recursive validation. I said what now? Had I recently had dental surgery? I don't remember this. If you mean the comment I made on the ANAME thread, I was just saying that it's possible to implement CNAME flattening without a built-in resolver; several implementations already do. (I do believe an authoritative server should be *able* to operate without built-in recursive code, and enabling such operation is on my list of things to get around to someday in BIND: if auth servers could be configured to use external resolvers, then security bugs affecting only the recursive code wouldn't be any risk to them. But I definitely wouldn't phrase that as "there should not be any code".) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNSSEC validator requirements
I have reviewed draft-mglt-dnsop-dnssec-validator-requirements-04.txt and some comments on the substance of it are below. (I'll also send some grammatical nitpicks via private mail.) > However, without valid trust anchor(s) and an acceptable value for the > current time, DNSSEC validation cannot be performed. This document lists > the requirements to be addressed so resolvers can have DNSSEC validation > can be always-on. This abstract, and the introduction below, both seem to suggest that the intention of this draft is to list requirements for automatic bootstrapping and recovery of DNSSEC without human intervention. However, several of the requirements actually included in the text describe mechanisms of human intervention: for example, insertion of negative trust anchors or the ability to flush the cache. To my mind, any need for human intervention contradicts the idea of DNSSEC being "always-on"; humans can't react instantly. So I suggest revising the abstract and the problem statement to say that these are requirements for a DNSSEC validator to be recovered when it fails, rather than for it always to be on. > REQ1: Mechanism MUST be provided to update the time of the DNSSEC > Validator. "... or to securely bootstrap the time without the use of DNS." (There's an irritating chicken-and-egg problem when NTP relies on DNS lookups to find clock servers and DNSSEC requires the time to be correct before it can look anything up.) > REQ2: Mechanisms MUST be provided to check the validity of DNSSEC > Validator's Trust Anchors. > > REQ3: Mechanisms MUST be provided to update the Trust Anchor of the > DNSSEC Validator. I would explicitly reference RFC 5011 here, and also Wes Hardaker's 5011 security considerations draft, and IANA's publication of trust anchors via HTTPS. > This situation should not happen as when a ZSK is renewed all RRsets > validated by the old ZSK are flushed from the cache. I think maybe you meant "rolled", not "renewed"? I wouldn't say old RRsets will be "flushed" from the cache when a key is rolled -- that suggests that they're being removed en masse, prior to expiry, as a result of the key rollover. But if the rollover has been carried out correctly, with the old ZSK published in the DNSKEY RRset for at least as long as the longest TTL in the zone after the new ZSK started signing, then all the cached RRSIGs will be *expired* from the cache by the time the old key is removed. If the key rollover is done incorrectly, then a mechanism will be needed to flush the entire validator cache, or to flush the namespace below the problematic DNSKEY. I would reference RFC 7583 here. > This DS RRset can be invalid because its RDATA (KSK) is not anymore > used in the child zone or because the DS is badly signed and cannot be > validated by the DNSSEC Validator. > > In both cases the child zone is considered as insecure and the valid > child zone's KSK should become a Trust Anchor KSK. I don't think this is correct. The child zone would be treated as bogus, not insecure, and would return SERVFAIL. (IIRC, it would only be treated as insecure if the DS RRset exclusively referenced DNSKEY algorithms not supported by the validator.) In any case, this doesn't strike me as a DNSSEC failure, but as DNSSEC working correctly to prevent an attack. The ability to configure trust anchors at arbitrary points in the tree is a useful requirement to specify, though. > REQ7: Mechanisms MUST be provides to informed the DNSSEC Validator that > a KSK or a ZSK MUST NOT be used for RRSIG validation. Unlike "flushing", > "MUST NOT be used" means the issue is not a synchronization issue, but > that legitimate keys are invalid. Such Keys are known as Negative Trust > Anchors [I-D.livingood-negative-trust-anchors]. Negative trust anchors are now specified in RFC 7646. This isn't a very clear description of them; I'll suggest revised text in separate mail. > REQ9: Mechanisms MUST be provided to inform the DNSSEC Validator a KSK > or a ZSK is to be used for private use. I'm not sure how this differs from REQ6? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC corner case -- (surfaced by homenet vs stub validators)
On Thu, Mar 30, 2017 at 07:23:46PM -0500, Brian Dickson wrote: > What seems to be "missing" (as in, maybe it is a corner case that wasn't > noticed before), is the ability for a security-aware resolver to "signal" > to a stub, that it is deliberately not returning DNSSEC records, even > though the stub set the DO bit (DO=1). Why would the stub trust such a signal? Seems like an easy mechanism for a downgrade attack. > Or is it far too late to be suggesting changes for sub-resolver DNSSEC > signaling? Signaling from the resolver to the stub doesn't seem like a promising approach to me. If for some reason you can't put an insecure delegation in the global DNS, then it would work to configure both the stub and the resolver with (*sigh*) a permanent NTA for .hab.arpa or whatever. (I was so very firm in my advocacy that NTAs should always be temporary when RFC 7646 was being written. Please let's just have insecure delegations?) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for ALIAS/ANAME type
On Thu, Mar 30, 2017 at 11:08:06PM -, John Levine wrote: > though ANAME is vastly less complex. It requires that an > authoritative server include a recursive client and do online signing, > both of which would be rather large additions to the mandatory set of > server features. It can outsource resolution to an external recursive resolver. Depending on the implementation details, signing could also be handed by an external bump-in-the-wire signer. (Incidentally, I'm working on a somewhat more ambitious ANAME draft with Peter van Dijk and Anthony Eden, who has kindly agreed to merge his efforts with ours. I expect to post it in a few days, stay tuned.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BULK RR as optional feature
On Thu, Mar 30, 2017 at 06:25:28PM +, Woodworth, John R wrote: > I was under the impression DNSSEC fixed problems with integrity, > not inconsistency. There's an expectation that the DNS will only be loosely coherent, but the same serial number should have the same answers, and an NSEC/NSEC3 proving nonexistence of an answer at one auth server is going be problematic if there is a positive answer from another. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BULK RR as optional feature
On Tue, Mar 28, 2017 at 10:47:02PM -0500, John R Levine wrote: > That's exactly the problem -- a server that doesn't handle BULK will > return the wrong answer. It might return the BULK record itself or > NXDOMAIN for an address that BULK would synthesize. And, if the zone is signed, it'll be provably wrong. I don't think it's enough to handwave the problem as "not of great concern". At least, please add some operational advice that BULK is not to be deployed in any domain unless all auth servers for that domain fully implement it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BULK RR as optional feature
On Wed, Mar 29, 2017 at 12:41:26AM +, Woodworth, John R wrote: > I believe this would ultimately be less efficient than generating > the records on the fly. Unquestionably. This clearly wouldn't be the preferred behavior. If the slave does understand BULK records, you'd just transfer those. > Assuming a relatively small range, say an IPv4 /16. You would > need to sweep through similar logic and load _every_single_answer_ > into memory rather than just the ones which are asked for. Sure, that's what $GENERATE does. The generated records are then transfered normally. You con't end up with one auth server that has generated records and another that doesn't. > I see no reason caching couldn't be used to hold the more commonly > requested records in order to save on CPU. (apologies for double-neg) > > Additionally, the patterns could (and most likely should) be pre- > parsed for simpler/ lower calorie processing. But if you have a primary that supports BULK and a secondary that doesn't, then you have two authoritative servers for the same domain with the same serial number but one of is saying NXDOMAIN when the other one returns a positive answer. This is a significant problem, and the draft ought to address it. (Or have I misunderstood something?) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)
Earlier today Petr Špaček sent me an off-list comment that he intended to be on-list, and I want to promote it: On Tue, Mar 28, 2017 at 05:20:52PM +0200, Petr Špaček wrote: > Here I have to agree with enforcing "MUST NOT". MD5 is a risk even on > the validating side. It might provide attacker with ability to forge > TLSA records in zones signed with MD5, which is has much worse > consequences than treating the zone as unsigned. It is a security > nightmare because validators supporting MD5 will treat this as valid and > happily accept forged certificates! This is a convincing argument, and I'm reconsidering my objections in light of it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BULK RR as optional feature
On Tue, Mar 28, 2017 at 06:31:56PM -, John Levine wrote: > What if such a server receives BULK by AXFR? By IXFR? I agree these scenarios in particular need to be specified. One possible solution would be an EDNS signal indicating whether or not the secondary server implements BULK. If not, the primary would have to expand the BULK data during transfer, same as BIND expands $GENERATE. (I proposed a similar sort of EDNS signaling mechanism in draft-hunt-note-rr-01 a few years back.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)
On Tue, Mar 28, 2017 at 03:36:40PM +0100, Tony Finch wrote: > Chris Thompson just mentioned to me another reason for dropping support > for RSAMD5: it uses a different DNSKEY tag calculation, which implies that > dropping support should simplify validators more than dropping other > algorithms. To be clear, for the benfit of those not in the room yesterday, I do *not* object to deprecating RSAMD5, I agree with the "MUST NOT" in the signer column, and that it's pointless to support it in new validator implementations. My problem is with elevating "pointless" to the force of a "MUST NOT". I think it should be reduced in force to "OPTIONAL", "NOT RECOMMENDED", or even "SHOULD NOT". Kill it on the supply side. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)
Oopsie: On Tue, Mar 28, 2017 at 02:41:27AM +, Evan Hunt wrote: > MD5 is known to be breakable, but it's not *as* breakable as a zone > that hasn't been signed -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
