Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)
On Mon, Mar 27, 2017 at 12:45:04PM -0700, Paul Vixie wrote: > also, a validator that outputs "secure" based on MD5 inputs is making a > promise it can't keep. MD5 is known to be breakable, but it's not *as* breakable that hasn't been signed, or a resolver that hasn't turned on validation. A validator that doens't implement an algorithm treats any domain signed by that algorithm as if it were not signed at all. A MITM attack on that domain goes from "not as difficult as we'd like" to "trivially easy". I don't see this as a net improvement to security. We can and should kill MD5 key generation and signing (and I'll add this to the ticket about updating defaults in BIND) but I'm uncomfortable killing MD5 validation until I'm sure there aren't any legacy keys floating around. Your other point about never-used code being uneploded ordnance is well taken. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any
On Fri, Mar 17, 2017 at 10:19:27AM -0700, Doug Barton wrote: > I'm aware that a lot of the animosity towards ANY has come from Dan's > choice of using it to find records for qmail. I am not a Dan-fan > generally, but on this topic he has made the excellent point that the > query exists, and has well-defined semantics which meet the use case, so > it's legal to use it. I have never understood the DNS literati's > animosity towards that argument. Dan's use case would not be harmed by refuse-any; qmail sends its queriers to local resolvers, not to authority servers. It gets back whatever happens to be cached, or the minimal answer, and in either case it'll re-query. No harm done. > I find it astonishing that there is this overwhelming "We must preserve > backwards compatibility at all costs!" sentiment on so many ridiculous > topics in the DNS, and yet because people hate the ANY query (and > particularly one software author's perceived misappropriation of it) SO > MUCH y'all are willing to throw backwards compatibility out the door for > something that it's absolutely clear will break deployed applications. This is already deployed; it was introduced as "mimimal-any" in BIND 9.11.0 using the pick-one-RRset method, and cloudflare has been using the HINFO method for over a year. I haven't heard reports of anything being broken. -- 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 NSEC5 protocol spec and paper
On Fri, Mar 10, 2017 at 03:16:05PM +, Woodworth, John R wrote: > > Is there a community of zone admins who want this so much that they > > won't start signing until it exists? > > With the draft's aliasing of algorithms, why couldn't (wouldn't) a zone > at least experimenting with this be able to provide 2 sets of keys, > one pre-NSEC5 and the other NSEC5 and forward? I think the question pertains to whether it's worthwhile for us to adopt this. If there are operators who need NSEC5 badly enough that they won't deploy DNSSEC until it exists, then it makes sense for the working group to take it on. If it turns out, however, that everyone who might like NSEC5 is also reasonably satisified with NSEC3, then we'd be wasting time on an academic exercise. It's clever, but it's only necessary if we broadly agree that NSEC3 isn't meeting our needs. I'm not sold on that point. -- 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] order of records in DNAME responses
On Fri, Feb 24, 2017 at 02:46:28PM +, Edward Lewis wrote: > The reason I point this out is that the order of records in a section has > been famously undefined, with the convention of supporting round robin > (an undocumented feature of the protocol) hanging around, for all of > eternity. I can see an implementation recommendation note because it > makes sense, but, if we use the old rule of "for interoperability" I > don't see specifying the order of records as necessary. The order of RR's within an RRset is undefined and needs to remain so, but can there be constraints on the order of RRsets within a section? > I also think that goats have already left the burning barn on this. > Going forward code might put the DNAME ahead of the CNAME, but if past > code doesn't, going forward code must account for that. It took us a very long time to encounter the first server that did CNAME-first. Most are going to do DNAME-first because it's simpler to code that way: it's easier to append to a message than insert something into the middle. IMHO the problem is now big enough to see, but still small enough to step on by declaring we didn't mean for it to be legal. > Not to mention the difficulties in writing so-called clarification > documents. They aren't all that pleasant... Well, that's why I started with an email thread... -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] order of records in DNAME responses
On Fri, Feb 24, 2017 at 11:40:26AM +0100, Matthäus Wander wrote: > Do you mean clarifying as in "how it always was meant to be but stated > in unclear words" or as in "change to protocol"? I meant the former. I wasn't involved, but I suspect that DNAME-first was the intended behavior all along, and nobody thought to mention it. However, if the group doesn't agree, then I guess I mean the latter. > In the latter case, you'd still need code to parse responses from > implementations that don't make assumptions about the order of records. What I'd like is to be able to send FORMERR with a clear conscience. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] order of records in DNAME responses
RFC 6672 saith: A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME RR is synthesized and included in the answer section when the DNAME is employed as a substitution instruction. The DNSSEC specification ([RFC4033] [RFC4034] [RFC4035]) says that the synthesized CNAME does not have to be signed. The signed DNAME has an RRSIG, and a validating resolver can check the CNAME against the DNAME record and validate the signature over the DNAME RR. The phrase "included in", as opposed to "appended to", provides no guidance about the order in which records appear, so presumably it's legal to have the synthesized CNAME appear first and the DNAME from which it was synthesized afterward. Most implementations, however, do send the DNAME first. We had a problem with BIND a while back when we encountered a server that didn't. BIND processes the RRsets in an answer in the order they're received (I suspect nearly all resolvers do this). In this case, the decisions about how to validate and cache the CNAME went wrong because we didn't have the flag set saying we'd previously seen a DNAME. We rejiggered the code so it wouldn't care about the order of records anymore (incidentally, and embarrassingly, introducing another bug in the process, but that's another story). It would have been simpler and more painless if we could have just treated this condition as a FORMERR. I'd like to start a discussion of that now. Does anyone have a problem with the idea of clarifying the protocol here, saying that the order of records in the answer section of a chaining response is significant, and in particular, that a DNAME MUST precede the corresponding synthesized CNAME? -- 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-bellis-dnsop-xpf-00.txt
On Fri, Jan 06, 2017 at 06:43:30PM +, Wessels, Duane wrote: > When a server receives the option from a non-whitelisted client, it > MUST return a FORMERR response. +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] I-D Action: draft-vixie-dns-rpz-04.txt
On Tue, Dec 20, 2016 at 07:30:43AM +0200, ac wrote: > You are quite correct, but the minute you answer questions for other > people the entire situation changes. Not if they've contracted with me to answer their questions in a way that protects them from malware, it doesn't. > To rip the dam from underneath the duck: You cannot legally resolve a > non google IP number as "google.com" just because your t says you can > do whatever you want. If google.com is known to be sending malware or spam or other undesirable content (which it isn't), then of course I can. Or, instead of remapping the answer, I can return NXDOMAIN. This would not be theft; it would a service provided to my malware-averse clientele. If they don't want this to happen then they should use some other resolver or run their own. Now, if I remap google.com in order to *cause* my clients to receive malware or spam, then yes, I agree that I am being evil, and I hope everyone is using DNSSEC and SSL certificate validation and other such mechanisms to detect and avoid this. > in DNS, it is much more subtle, it is about honesty, morality and ethics. I remember when I stood up at my first IETF meeting and asserted the principle that the DNS should not lie. I was 40 years old. Just a starry-eyed kid with a dream. Even then, though, the context of my statement was that there were technical considerations that made it regrettably necessary to lie in certain operational environments - specifically, some networks at the time were breaking when they received answers, so we'd added an option to filter those. Such considerations take precedence over absolute truthfulness. "Not wanting to be recruited into a botnet" is another such consideration. Paul and Vernon invented a useful tool to help address it, and I'm in favor of documenting 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] I-D Action: draft-vixie-dns-rpz-04.txt
On Tue, Dec 20, 2016 at 06:42:02AM +0200, ac wrote: > the reason why there is an ethical difference between Domain Names and > IP resources starts with the fact that domain names are other people's > actual intellectual (legal) property. There is also all the other > considerations, for example DNS is a question whereas some other > protocols are instructive, based on the answers to questions. > > IP resources (RIR) are generally not registered as intellectual property > and so the ethical considerations regarding IP are different to that of names. Once again, I own my resolver and I own my web browser. I want my web browser not to download malware. It's easier for me to configure my resolver not to answer bad questions than it is to prevent my browser from asking them. Neither "ethics" nor "intellectual property" (the relationship between which is not, in my opinon, anywhere near as obvious as it is to you) are considerations here. If you wish to consider a physical analog, there may be a general principle that one should not interfere with postal mail, but this is challeged by the existence of the unabomber or the anthrax attacks. -- 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-vixie-dns-rpz-04.txt
On Mon, Dec 19, 2016 at 10:42:35AM +0200, ac wrote: > it still is never okay to lie and to deceive. > [...] > This is simply about ethics. I hereby, with full knowledge and prior consent, give my resolver (which I own) *permission* to falsely tell my browser (which I also own) that malware domains don't exist. The ethical conundrum having been resolved, we can now carry on with documenting the mechanism I used to tell my resolver to do 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] DNSSEC operational issues long term
On Wed, Nov 16, 2016 at 08:41:03AM -0500, Bob Harold wrote: > > Do you have a suggestion for a solution? > > > This is not well thought out, but what jumps to mind is to keep a chain of > signatures in the root DNS that links from the original KSK up through the > current KSK (or at least the last 10 years). Perhaps a different record > type, so it is only sent if asked for. > > Does that make any sense? I believe that's what the TALINK RR type is for. The draft seems to have fizzled back in 2010, but I still think it's a good idea. https://tools.ietf.org/html/draft-wijngaards-dnsext-trust-history-03 -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Authoritative Servers and the AD bit
On Thu, Jun 09, 2016 at 09:14:28AM -0400, Peter DeVries wrote: > We are observing a system that is setting the AD bit both without the > DO bit set in the query and without supplying RRSIGs but I can't find > any relevant text in the new RFCs. If the AD bit was set in the query that's being answered, that's legit under RFC 6840 sections 5.7 and 5.8. -- 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 for draft-fujiwara-dnsop-nsec-aggressiveuse
On Sun, Apr 10, 2016 at 12:52:39PM -0400, Olafur Gudmundsson wrote: > I have read the draft and support its adoption +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] RSASHA512 SHOULD-
On this topic, I wasn't quick enough to get to the mic before the line was
closed, but I'd like to suggest a higher degree of caution with the "MUST
NOTs" and "MUST-'s" in the validator column, relative to the signer column.
IIRC, RSAMD5 was originally mandatory to implement. I certainly don't mind
deprecating it for signing, but to tell validators that they not only don't
have to implement it, but actually MUST NOT do so, seems excessive. The
only justiication I could see for that would be if MD5 were so
comprehensively broken that MD5-signed data could be trivially falsified,
and we're not there yet. IMHO it shouldn't go any lower than MAY.
Similarly I think it's fine for {NSEC3,}RSASHA1 to get MUST- in the signer
column, but I don't see any near-term future where they should drop below
MUST in the validator column. It's still the default algorithm in the BIND
signer; it's going to be a long, long time before validators can start
ignoring 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] Fracturing the protocol - was Re: Updated cheese-shop.
On Wed, Mar 02, 2016 at 08:06:39AM +1100, Mark Andrews wrote: > ANC does not work for zones using OPTOUT. This is just about all > TLDs and similar zones. To be pedantic, it doesn't work for optout ranges. I don't actually know offhand of any zones that mix optout and non-optout, though, so it's a fairly pointless quibble. > That then leaves leaf zones. Here sites will not want ANC for their > own zones internally. Externally there is only real benefit if you > are under a random prefix DoS attack. Random prefix DoS attacks are prevalent enough nowadays to make this seem like a rather significant exception. The downsides should be manageable. We can implement ANC so that it's separately enabled or disabled for different namespaces, and put a TTL cap on NSEC/NSEC3 records in zones that have ANC enabled. I agree with the suggestion upthread that we address the general case instead of the root-only 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] RFC 5155 §7.2.8
On Wed, Feb 17, 2016 at 03:50:54PM -0500, Robert Edmonds wrote: > Should the second condition on the RR type have an explicit "besides > NSEC3" qualifier? Or am I missing something that implicitly excludes RR > type NSEC3? Otherwise it seems to me that the second condition is always > false. Yes, it should have that qualifier. -- 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-refuse-any and DO=0
On Sun, Feb 07, 2016 at 02:16:15PM +, Tony Finch wrote: > Is this sensible, and if do should it be suggested by the draft? Yes. I haven't looked in the draft recently, but I thought I mentioned that when I originally described this trick. Choose an arbitrary (preferably determinate) rrset to return, and include its covering signature if it exists and DO=1 so the response can validate. eh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag
On Mon, Nov 30, 2015 at 05:29:53PM +, Wessels, Duane wrote: > As I've said a number of times before, the edns-key-tag proposal is modelled > after RFC 6975, which does the same thing for algorithms. If it works for > algorithms why wouldn't it work for key tags? Does it work? Has anyone deployed 6975? We have an experimental implementation of it in a development branch for BIND, but we decided not to release it because the benefits didn't seem commensurate with the extra complexity and packet size. I haven't checked to see whether any other implementations are using it. We've certainly encountered operational difficulties when sending unknown EDNS opcodes to broken servers. Mark has been pushing hard on this issue, and things are getting better, but it's still a problem. > > without needing the entire ecosystem to be upgraded > > which this proposal requires. > > I disagree with this characterization that "the entire ecosystem" needs > to be upgraded. Yes a non-key-tag-aware recursive won't know to forward > the option, but this is true for all EDNS options. But it isn't true for query names. -- 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-edns-chain-query
On Mon, Nov 09, 2015 at 04:55:24PM +, Tony Finch wrote: > With the current DNS protocol, a stub resolver can get all the records it > needs to validate a response in 1RTT, by sending multiple concurrent > queries for all the possible delegation points in the QNAME. But has to retain state for all those active queries, which adds a fair bit of complexity. I would expect it to be a lot more straightforward to code a stub validator using 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] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
> > i believe that in dnssec, an empty non-terminal has a proof that the > > name exists, and a proof that there are no RR's. thus, vastly > > different from the signaling for NXDOMAIN. > > RFC 4035 §3.1.3.2 appears to say differently :( But RFC 5155 is clear on the subject; empty non-terminal nodes are mentioned under "no data" rather than "name error". -- 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-muks-dnsop-dns-catalog-zones-00
On Mon, Oct 19, 2015 at 10:10:29AM -0700, Paul Vixie wrote: > there's been enough churn at isc in recent years that probably noone now > working there remembers metazones. > > muks, et al, see: <http://family.redbarn.org/~vixie/mz.pdf>. Metazones, and that particular URL, are referenced in the draft. I've had no significant involvement in the catalog zones design, so I can't tell you why the metazone format wasn't used, but I'm pretty sure there were reasons for the decision. -- 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-jabley-dnsop-refuse-any-01.txt
On Wed, Oct 14, 2015 at 09:49:59AM +0100, Ólafur Guðmundsson wrote: > Sorry for the typo : RFC4470 > > Minimally Covering NSEC Records and DNSSEC On-line Signing Ah, thanks. Yes, the first and second points mentioned in the security considerations there are both applicable. -- 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-jabley-dnsop-refuse-any-01.txt
Hi Joe, I think you need some more text in the description of pick-one-rrset, something like: A DNS responder which receives an ANY query MAY decline to provide a complete response, and MAY instead choose to return only one of the the RRsets present at the node specified in QNAME, and the associated RRSIGs if any. If this approach is chosen, the following limitations apply: - If there is an NS, CNAME, or DNAME RRset present, then the responder MUST return those RRsets. (Note that DNAME can coexist with NS; if this is the case, both RRsets MUST be returned.) * - Otherwise, when multiple RRsets exist, the responder SHOULD select an RRset to return using a deterministic mechanism, so that subsequent queries of type ANY to the same server will continue to receive the same data so long as the contents of the node remain unchanged. For example, the responder MAY choose the smallest RRset, in order to reduce the amplification potential of a type ANY query. - The responder MUST NOT choose to return an RRset of type RRSIG, but MUST include the covering RRSIG RRs for whichever RRset is chosen. I'd suggest breaking this into a separate subsection of section 5. I would also mention in security considerations that synthesizing responses from a signed zone requires the private signing key to be online and available to every responder; offline signing, or signing on the master server only, are not possible. * I'm not completely certain DNAME needs to be mentioned in the first bullet point, but I'm concerned there may be unintended consequences if it's present but omitted.) -- 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-jabley-dnsop-refuse-any-01.txt
Belated thought: In the text about synthesized responses, I think you should specifically mention that if the responder would normally have returned a delegation, a CNAME, a DNAME, or an NXDOMAIN, then it MUST still do so. That's implied by the final paragraph of section 5, but IMHO it ought to be 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] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt
On Tue, Oct 13, 2015 at 10:10:39PM +0100, Ólafur Guðmundsson wrote: > Having DNAME and NS below a zone apex is non-sensical as both are > "delegation records" i.e. > NS says where to find more specific name, > DNAME how to write a more specific name to another name. It's legal, though. > NS and DNAME can co-exist at zone apex, and if the ANY query is for > the apex then it should not matter which RRset is returned from the APEX is > returned. That's why I qualified this point -- I'm not certain anything would break if you chose to omit a DNAME; I'm just concerned that something might. In any case, I do think an ANY query for a zone apex should always return the NS. > If this is a delegation point I think the server SHOULD return a referral, > i.e. NS record in Authority section. Agreed. > For names where there is a CNAME either the CNAME is the only RRset or > there is a NSEC/NSEC3 RRset > I think for backwards compatibility CNAME should be returned in this case. Agreed here too. > > This is an over specific recommendation and can not be enforced, > think about the case where an operator uses any-cast and different software > running on > various servers. It doesn't need to be enforced, I suggested it as a SHOULD. I think it's better if the same server (physical server, that is, not anycast address) behaves consistently and predictably. I don't care what selection algorithm is used by any implementation, I just don't think randomness is desirable. Choosing the smallest RRset, as you suggested, is a perfectly fine option. > Similarly if there is a HINFO record it MAY take precedence over any other > records by the selection algorithms. Good point. > Is reference to RFC4770 security considerations good enough ? Sorry, which RFC? "vCard Extentions for Instant Messaging" doesn't seem likely to be what you meant here, but my brain is failing to figure it out from context. -- 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-jabley-dnsop-refuse-any-00.txt
On Thu, Oct 01, 2015 at 09:02:09AM -0700, Ólafur Guðmundsson wrote: > Only validating resolver will send follow up query, Correct, but it would send them to every name server until it got a non-bogus reply. This is unnecessary collateral damage. > Here is the deal there are 3 sources of ANY queries to authoritative > servers > a) Malicious ones both direct or reflected flood via open resolvers > b) Someone debugging or trying to zone walk > c) Resolver forwarding a ANY query because the cache for that name was > EMPTY. I see five categories. Malicious queries can come in directly, or through a resolver, or from a spoofed source. Legitmate queries can come in directly or through a resolver. - With spoofed source queries it doesn't matter what we answer. Setting TC=1 or dropping would be fine. - With a direct query (from dig, for example) it doesn't matter what we answer. REFUSED would be fine. - With a query from a resolver, we have to send an answer that the resolver will accept, so it doesn't keep trying; we also have to send an answer that will *not* impair the resolver's ability to resolve other names later. The problem is, we can't perfectly distinguish between these categories. DNS COOKIE will help to weed out the spoofed sources when it's deployed widely enough to rely on, and DNS RRL will mitigate the damage, but things will always get through. I see no choice but to assume the least convenient case: that a query for type ANY is coming from a resolver which is passing along a query from a legitimate client. In order to avoid doing any harm to that presumptive resolver, we *must* perform a database lookup to find out whether the qname exists and whether it's below a zone cut, so we'll know whether to return NXDOMAIN, a delegation, or a minimized response. And if the zone is signed and we're sending a minimized response, then it *must* include a valid signature. > There is NO need to sign, unsigned HINFO returned for ANY query looks to an > validating resolver just like an > incomplete answer thus it can either return the HINFO or ask the followup > question for the HINFO and get a signed > denial that the HINFO exists ==> which looks like the HINFO was just > deleted from the zone i.e. temporal inconsistency. It doesn't look like an incomplete answer; it looks like a *bogus* answer. A validating resolver will react by sending the same query to every other auth server for the zone until it gets something that validates. Eventually it'll SERVFAIL, and at that point perhaps the application will do something sensible, but we're wasting resolver resources in the meantime. > Given the assumption that we are optimizing for defense there is no need > for an authoritative resolver to know if it is authoritative for the zone > the query was for, it can just return HINFO as an negative answer to the > ANY query type. You've got to search the database for zone cuts, or you'll end up with a resolver thnking example.com is authoritative for www.child-zone.example.com. You've got to search down to see if there's a leaf node above the qname, or the resolver won't be able to use a cached NXDOMAIN as a signal to stop sending queries for descendant nodes in the future. > In our proposal you are optimizing for c) without knowing if the type you > return is of value to the originator of the query, I don't care whether the response is of value to the originator; I'd return no answer at all if I could. (Unfortunately, NODATA for type ANY is interpreted by some caches to mean "no data of any type", and REFUSED wouldn't stop a resolver from asking.) > furthermore your answer is likely to be larger. Admittedly true. Still an improvement over conventional ANY responses. > If we agree that both are acceptable and each server only needs to support > one of the two then that is fine with me. Both are acceptable as long as we don't break the DNS. I cannot support a proposal that does break the DNS. If we do what's necessary to avoid breaking the DNS, then I don't believe there's any practical advantage to the HINFO approach, but I wouldn't oppose. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)
On Wed, Sep 30, 2015 at 01:41:19PM -0400, Robert Edmonds wrote: > but AFAIK the example BIND configuration > only supports querying the "static-stub" servers on the well-known port. This is true. It's implemented as a virtual delegation, and works the same as a regular delegation. NS and glue records don't have a place to put a port number, so static-stub zones don't allow you to configure one. It should be easy enough to create a local alias address for the purpose though. "ifconfig lo inet6 add ::2 alias", salt to taste. -- 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-jabley-dnsop-refuse-any-00.txt
On Wed, Sep 30, 2015 at 04:20:25PM -0700, Ólafur Guðmundsson wrote: > FYI, > this is latest incarnation of of how to give out minimal answer to ANY > query without breaking anything and being friendly to resolvers. > Olafur This was discussed at some length back around the Toronto IETF and I made a suggestion that seemed to garner fairly wide support, i.e., selecting a single RRset from the ANY response and returning only that. See: https://www.ietf.org/mail-archive/web/dnsop/current/msg13945.html ...and its followups. Is there a reason you decided not to go in that direction? (I'd be happy to contribute text if you like.) The new proposal to return an empty HINFO record has the advantage of a smaller response, but will be inconvenient for DNSSEC-signed zones, unless the server has access to the signing key and can generate a covering RRSIG. This should be mentioned in security considerations. The pick-one-RRset mechanism doesn't have this problem, because the covering RRSIG will already exist for whichever RRset is returned. -- 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-jabley-dnsop-refuse-any-00.txt
On Wed, Sep 30, 2015 at 11:28:45PM -0400, Joe Abley wrote: > 1. Return an unsigned response. This will be marked as bogus, and > trigger a QTYPE=HINFO re-query that will either return an actual signed > HINFO from the zone or a signed proof of non-existence. We think. I > haven't actually tested that a re-query will happen, but Olafur is > confident. :-) I haven't tested it either, but that is not what I would expect. If the resolver gets a bogus response to a query of type ANY, I would expect it to try the same query at another name server, until it had exhausted all authoritative name servers, and then reply with SERVFAIL. > 2. Sign the HINFO RR as it is synthesised (or pre-sign one, to avoid the > edge authority servers needing access to a signing key). Pre-signing essentially reduces to adding an empty HINFO to every node in every zone, then using the pick-one-RRset method, but ensuring that HINFO is always selected first. > That is true. However, one of the use-cases for this approach is a > nameserver for which a search for records present at a particular owner > name (as would normally be performed when responding to an ANY query) is > expensive. It's not at all obvious to me that this is cheaper. With either method, you have to search down through the zone to find out whether the node exists (otherwise you'd be returning NXDOMAIN, rather than a minimized response). Since you're doing that search anyway, choosing an RRset to return is pretty cheap. And actually, you really *should* also look through the RRsets at the node to make sure there isn't a non-empty HINFO record before you synthesize an empty one, and if you're doing *that* anyway, choosing an RRset wouldn't cost any more and could well cost less. Assuming we aren't considering the possibility of native HINFO records, I agree that synthesizing an unsigned HINFO would be little quicker than pulling an RRset out of the node, but not *so* much quicker as to seem obviously worthwhile. And for signed zones, synthesizing a signed HINFO would almost certainly be slower, while returning a pre-signed HINFO would be no faster than choosing an RRset. The disadvantages of pick-one-RRset that I can see are 1) more information leaked (but nothing that couldn't be obtained by sending queries for individual qtypes anyway), and 2) modestly larger response size (but still a lot better than unminimized ANY responses). Perhaps both approaches should be described in the draft. -- 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-muks-dns-message-checksums-00.txt
On Mon, Sep 28, 2015 at 09:56:38AM -0700, Paul Vixie wrote: > so i think there's good cause to add a DNS-level checksum even as we add > DNS-level cookies. +1 I would prefer to use checksum and cookies in parallel rather than have the checksum option recapitulate cookie functionality, though. Unless I'm overlooking something, the NONCE field in Mukund's proposal becomes unnecessary if cookies are in use. Otherwise it seems like a very good idea. (It's a pity there's no version field in the COOKIE option format; COOKIE version 1 could have been extended to include a checksum.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)
On Thu, Jul 09, 2015 at 11:29:11AM -0400, Olafur Gudmundsson wrote: Strictly speaking the minimum time needed for a Negative Trust anchor is something like Domain_Operator_reaction_time + Parent_reaction_time + Parent DS TTL + DNSKEY TTL Valid point. When the NTA for a name expires, the cached data at and below that name can also be discarded, so TTLs aren't a major concern when the cache and the validator are coresident, and it hasn't been a factor with BIND. But if validating forwarders and stubs support NTAs they may have a different experience. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)
On Wed, Jul 08, 2015 at 09:50:09PM -0400, Warren Kumari wrote: Less flippantly, it is in this email: https://www.ietf.org/mail-archive/web/dnsop/current/msg13004.html I don't think that we have a really good motivation for a week, other than that is feels sort of like a good, human scale timeframe to recheck on things. We really want there to be a limit on the lifetime, a week felt right... Yep, that's pretty much it, right there. A day isn't enough (we had feedback from customers to this effect) but anything longer than a week strikes me as much too likely to fall off operators' radar. Though the limit is arbitrary, I do believe that we need to assert *some* limit, on this approximate time scale. but, I still like because Evan said so... Yes let's definitely document it that way. ... MUST NOT exceed a week, due to the whimsical and capricious nature of Evan. Pray he does not alter the deal any 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] Some distinctions and a request - Have some class?
On Sun, Jul 05, 2015 at 10:01:55PM -0400, Andrew Sullivan wrote: Since the RDATA for a CNAME or DNAME is another point in the tree, the above convention would suggest in fact that you _can't_ point to a different alias (or else, we'd get a very unusual meaning of the terms parallel and same). The remark prefaced with by convention doesn't strike me as particularly definitive. There's no .bind TLD in class IN, yet version.bind/CHAOS exists in many DNS servers, therefore the namespaces aren't actually parallel or the same, whatever the authors may have expected to happen at the time 1034 was written. If all we want is a convention for instructing the local resolver, repurposing classes seems like a lot of work. After all, apparently Bonjour and Tor -- and for that matter, DKIM -- are able to figure this out by grovelling through magic labels in the owner name. It's filthy, but the code all shiped ages ago. Point taken, but the problem we're facing is magic special-purpose labels potentially being repurposed in the global DNS and thus becoming ambiguous. Allocating class ONION, class MDNS, etc, for things like this may actually turn out to be less trouble in the long run than ensuring that ICANN never sells anybody a TLD called .onion. -- 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 distinctions and a request - Have some class?
On Sun, Jul 05, 2015 at 10:44:40AM -0400, Andrew Sullivan wrote: Imagine the alternative-resolution class FAKE. In the IN class, example.com has a DNAME entry pointing to example.net. What should happen when someone performs a query for QNAME localentry.example.com, TYPE , and CLASS FAKE? What *should* happen, IMHO, is the DNAME shouldn't come into consideration because it only exists in class IN. localentry.example.com/FAKE/ is in a different namespace entirely, and a query for it should never reach the example.com/IN zone. What *does* happen is unclear; maybe nothing. To the best of my knowledge, nobody currently uses non-IN namespaces except for strictly local authoritative data such as version.bind/CHAOS/TXT. I'm not sure whether it's even theoretically possible to do more than that today; in any case it hasn't gotten much attention from implementors or operators, so if the code exists, it's not being exercised. Non-IN delegation and recursion probably aren't adequately specified, certainly aren't adequately tested, and if my interpretation above is correct, they'd imply a need for a ./FAKE root zone alongside the ./IN one, which opens up multiple cans of distressingly wiggly worms. However, I can imagine a mechanism in which a query for some.tld/FAKE instructs the local resolver to use an alternate resolution mechanism for some.tld, with the DNS protocol being used only for that first hop. This might be suitable for things like .onion. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
On Wed, Jun 03, 2015 at 08:40:16AM +0200, Petr Spacek wrote: Could this be added to agenda for IETF 93? Does it make sense to discuss it there? Unfortunately I won't be in Prague, but I do expect to be in Yokohama. If you or someone else would like to push the idea forward in my absence, that's fine. There were a couple of review comments that I'll need to dig out and address if the draft is coming back to life. -- 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-negative-trust-anchors
On Tue, May 12, 2015 at 11:44:28AM +0200, Warren Kumari wrote: An NTA placed at a node where there is a configured positive trust anchor MUST take precendence over that trust anchor, effectively disabling it. Implementations SHOULD issue a warning or informational message when this occurs, so that operators are not surprised when this happens. Just added. Seem good? I'd have gone with MAY instead of SHOULD, but that's a quibble: it's fine. -- 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-negative-trust-anchors
Does this mean: A: All implementations that conform to this document should prefer the NTA over the positive anchor in such a case, or B: This is implementation-dependent, but if an implementation allows the coexistence of positive and negative anchors, it should prefer the NTA, or C: something else? Good point. I personally favor A, but would be fine with B. I'd be interested in input from other implementors; if there's a constituency for B then fine, but if we're all going to allow coexistence anyway, we might as well specify it that way. I don't have a strong opinion between A and B, but I'd like this document to be clear on this. And, if it means A, I'd use an RFC2119 keyword (it's probably a SHOULD). With respect to the precedence rule, I would use MUST rather than SHOULD. -- 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-negative-trust-anchors
On Mon, May 11, 2015 at 12:19:19PM -0400, Bob Harold wrote: I am not even sure there is a good reason for a warning. In BIND, NTA's are set by an rndc command, but in other implementations they might be set up in a config file. If you have both a TA and an NTA for the same node in the same configuration, that would be sensible to warn about; it's the sort of oddity that might have been unintentional. -- 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-negative-trust-anchors
On Sat, May 09, 2015 at 03:08:11PM +0200, Warren Kumari wrote: It is RECOMMENDED that implementations warn operators (or treat as an error) if they attempt to add an NTA for a domain that has a configured positive trust anchor. You still need to say what happens if the implementation decides to warn instead of treat it as an error. Actually, weirdly enough, after I implemented NTA's in BIND, one of the very first applications somebody came up with for them was to temporarily disable DNSSEC validation by setting an NTA for .. This was seen as better than rndc validation off because he didn't have to send rndc validation on afterward; it would just quiety switch itself back on after a minute. It's... actually a pretty clever hack, and I don't really want to disable it. May I suggest: An NTA placed at a node where there is a configured positive trust anchor takes precendence over that trust anchor, effectively disabling it. Implementations MAY issue a warning when this occurs. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
On Thu, May 07, 2015 at 09:11:53AM -0700, 神明達哉 wrote: According to Section 7.2.4.1 of draft-ietf-dnsop-cookies-01, the server will still return the full size of response, so the attack will still be effective. Subject to rate limiting restraints, yes. BIND's experimental SIT implementation exempts clients from rate limiting if they have a valid cookie, but not otherwise. The cookie is more of a way for legitimate client traffic to be privileged, than for attack traffic to be mitigated; we have other mechanisms in place to handle mitigation. That said, however, I like the idea of adding the TC=1 response to the protocol specification as a MAY. -- 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-negative-trust-anchors
On Tue, May 05, 2015 at 12:24:13PM -0400, Warren Kumari wrote: The way that our resolver works is that the closest TA would win, and so a positive TA under a negative trust anchor *would* be used. To me this seems to be the obviously right thing to do, and so, unless anyone objects, I'll add text to the document stating that. This matches the BIND implementation. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
Greetings, The current DNS Cookies document (draft-ietf-dnsop-cookies-01) has two similar but distinct protocols described in it: the DNS Cookie option as designed by Donald Eastlake, and the Simple DNS Cookie option designed by Mark Andrews and experimentally implemented (under the name Server Identity Token, or SIT) in BIND 9.10. The chief difference between the two is the presence of an error code field in Eastlake cookies; Andrews found it redundant/unnecessary (as discussed in https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html). The hope was that including both mechanisms in the draft would lead to a working group discussion about whether the error code is, in fact, necessary or desirable; unfortunately, not much discussion has happened yet. I would very much like to see this protocol nailed down enough that we can request a code point and start including this feature in BIND without the #ifdef's around it. I'm hoping for WGLC in the Prague timeframe. May I request that people weigh in on the error code issue? Speaking for myself, I agree with Mark: the benefits of including error codes in the option are slim and other mechanisms such as FORMERR work just as well in almost every scenario, so it doesn't justify the cost in additional complexity. Thanks, -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on DNS terminology draft
Should we also mention that NODATA responses usually include a SOA record in the authority section to indicate to resolvers how long to do negative caching for? That does not seem to be established firmly enough for us to add. It's necessary for negative caching, so I believe it's required for authoritative responses (RFC 2308 section 3), but optional for recursive. Might also add that DNSSEC-signed zones will include a signed NSEC/NSEC3 to prove the nonexistence of the qtype. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?
On Sun, Mar 29, 2015 at 06:38:24PM -0400, Donald Eastlake wrote: The big argument against a Cookie error field, that I can see, is that it isn't there in the BIND implementation and running code speaks loudly in the IETF. When this is standardized, BIND will be changing the OPT code anyway; modifying the option format wouldn't be a huge problem. (I suspect it'll be more of an annoyance to change the name from SIT to COOKIE.) Would it be reasonable to leave space in the option for error reporting, but leave it up to the implementor to decide whether to bother doing 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] another way to minimize ANY responses
On Thu, Mar 26, 2015 at 06:33:18PM -0500, Ted Lemon wrote: what we should say in the spec is determinative, and non-information-leaking, and let implementers scratch their heads about how to do that. we should not try to invent it here, or specify it in an ietf document. I don't see how you can do that without maintaining state. So this may be a nice general thing to specify, but is it a _good_ thing to specify? Determinate is necessary, for reasons stated earlier. As long as the authority doesn't change the content of a node, the ANY response should stay the same. But if the node content does change (e.g., there's an A rrset that wasn't there before), then the ANY response may change, and I don't think we need to contort ourselves to prevent that. So IMHO it's not necessary to emphasize non-information-leaking with the same level of urgency, though it's desirable. It *might* be kinda vaguely desirable to offer guidance on the selection method to use, so that people get the same predictable ANY answers from BIND, NSD, etc. Otherwise, you could characterize it as an information leak if someone were running multiple implementations on different servers, and one of them returns and another one MX, etc. However, it can't possibly be any worse of a leak than merely running an old server that doesn't implement ANY minimization, so on balance I agree with Paul that it would be an overspecification. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] another way to minimize ANY responses
Last night the dumb-idea fairy visited me as I was falling asleep, and suggested that another way to reduce the impact of ANY queries would be to pick *one* rrset and return just that. (Probably the numerically smallest rrtype present at the node, plus RRSIGs if any.) This avoids poisoning caches with false NODATA, it works for both DNSSEC and non-DNSSEC zones, meets djb's requirements, makes ANY responses small, and we don't need to argue about what rrtype to use for synthesized responses in non-DNSSEC answers. Still leaks some data (which admittedly undermines the motivation of Olafur's draft) but not as much and what gets leaked would be trivial to acquire by other means anyway. -- 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 terminology draft
On Tue, Mar 24, 2015 at 06:02:34PM -0400, Dave Lawrence wrote: ECS / EDNS client-subnet -- An EDNS option principally for carrying information from a resolver to an authoritative server about the general network location of a client of the resolver. This is generally used by full service resolves who serve clients from a diverse network topography to get response from authoritative servers that tailor their responses based on client location. +1. If it stops one person from coming up and asking me when BIND is going to implement EDNS (when they mean ECS), it will all have been worthwhile. :) PS: I tend to use NXRRSET as slightly more expressive than NODATA, though it is an extended rcode for dynamic update. Worth mentioning along with the NODATA definition, or am I pretty much solo in using the term this way? You're not the only one. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
On Sat, Mar 14, 2015 at 09:10:03PM +0100, Florian Weimer wrote: We'd have to be reasonably sure that no resolver treats is as a meta-type and turns the upstream response into a FORMERR upon seeing it in the answer section. “NULLs are used as placeholders in some experimental extensions of the DNS.” is not confidence-inspiring in this regard. On the other hand, it saves us the grief of allocating a code point, and it has an intuitive name: if I saw a NULL RR in a cache dump I'd immediately guess it was a placeholder. Your point is well taken, but if that hypothetical resolver behavior turns out not to commonplace, then I say let's run with 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] DNS Terminology: Glue
On Fri, Mar 13, 2015 at 09:00:34AM -0700, Paul Hoffman wrote: If there is a well-accepted name for address records that come with glue records but are not actually glue records, we can add it, but I am hesitant for this document becoming a list of things observed in the wild that don't already have names. FWIW, what we tentatively have for the next draft is: Glue records -- Resource records which are not part of the authoritative data [for a zone], and are address resource records for the servers [in a subzone]. These RRs are only necessary if the name server's name is below the cut, and are only used as part of a referral response. (Definition from RFC 1034, section 4.2.1) Given the amount of discussion this topic has generated, and the number of ways I've seen the word used in the past (and, in fact, have used it myself when speaking imprecisely), a discursive paragraph about common misuses might be helpful. Like: The term glue is sometimes incorrectly used to refer to other resource records in a parent zone that are related to a delegation, such as address records included with a referral which are not strictly necessary due to the server's domain name falling below the zone cut, the authoritative delegation (NS), or the delegation signer (DS). This could help newcomers to the DNS to understand what they're reading when they encounter terms like NS glue, but it still stakes out a clear definition of the word. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
On Wed, Mar 11, 2015 at 12:13:42PM +, Tony Finch wrote: These are signed zones so the answer has to validate. ... they are? I thought the proposal was to restrict/deprecate qtype=ANY for all zones, not just signed ones. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
On Thu, Mar 12, 2015 at 11:38:04PM +, Darcy Kevin (FCA) wrote: So you're thinking it's more likely that we'll get folks to understand this new type, that's designed to frustrate QTYPE=* queries in a more-or-less graceful way, than it is to convince them to stop making QTYPE=* queries in the first place? They don't need to understand it, they just need to be able to receive it without choking. This could be a pretty brilliant solution, actually: If you're authoritative for a signed zone and you receive a query of type ANY, return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize a response containing a single RR with a type from the private use range (e.g. TYPE65531 or whatever), zero length rdata, and a long TTL. The resolver would get an answer, so it stops asking; it would *not* cache the answer as an empty node, so subsequent queries for other qtypes can still resolve. I like this better than any of the prior suggestions. (It doesn't address qmail's problem, but that's a lost cause no matter which method is chosen.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More work for DNSOP :-)
On Fri, Mar 06, 2015 at 08:13:09PM +, Dan York wrote: While I agree with this idea, I wonder if from a clarity of deployment point of view, as well as a speed point of view, it would be easier to divide this into two different documents: 1. Deprecate the ANY query 2. “Meta queries” should be behind some access control mechanism Is there anyone arguing that the ANY query should still be around? Or can we agree that ANY is now a query that has outlived its usefulness and needs to fade away? I use QTYPE=ANY for testing and troubleshooting quite frequently, and would prefer to see it hidden behind an access control mechanism rather than disabled completely. (As an aside: I've often wondered why the DNS doesn't have *more* meta-query types, less extensive than ANY, such as a single type covering A and . Or, an EDNS OPT mechanism to request a list of desired types in addition to QTYPE to be returned in the additional section (subject to packet size, rate limiting, DNS cookie authentication, whatever). I would guess the absence of such conveniences to be the reason Mozilla decided to take their regrettable shortcut. It seems like such an obvious optimization, I'm guessing it was talked to death before I ever started working with the DNS and there were good reasons not to do it, but I don't actually know what they were.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
On Wed, Feb 11, 2015 at 05:36:22PM +0100, Petr Spacek wrote: In other words, I do not think we can prevent people from doing crazy things just by obscuring format of diagnostics data. I'm sure somebody will try to parse free-form string 'signature expired 1 week ago' and do some decisions from that :-) I wasn't thinking of obscuring anything, just mentioning my one major concern about including diagnostics with SERVFAIL responses: I fear it will be a tempting target for someone to attempt misguided cleverness. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side
On Wed, Feb 11, 2015 at 03:44:31PM +0100, Pier Carlo Chiodi wrote: Wild idea: Could it be solved by adding more information to SERVFAIL answer? a draft was proposed with this very topic, but it's expired now: https://datatracker.ietf.org/doc/draft-hunt-dns-server-diagnostics/ I'd be happy to revive it, especially now that it's explicitly within dnsop's remit. I don't recall anyone objecting to the idea; it just wasn't high-urgency and I had other business to attend to. It's important that diagnostic signaling only be used for human troubleshooting purposes and not as input to a policy decision, such as ignore DNSSEC failures due to expired signatures or something, because the diagnostic messages would be trivial to spoof. -- 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-wkumari-dnsop-multiple-responses-00.txt
On Tue, Jan 13, 2015 at 10:08:00PM -0800, Paul Vixie wrote: you've left the box i thought we were standing in. CNAME chains are already returned by authorities, if in your above example, the alias and the canonical name are served by the same authority server. Didn't we decide a while back that this was a bad idea, that resolvers needed to stop trusting CNAME chains sent by authorities, and that authorities really ought to stop sending them? The reasoning as I remember it: If I ask the server for vix.su a question, and it helpfully provides an answer in redbarn.org, I have only its own assurances that it *is* in fact authoritative for redbarn.org; the answer can't be trusted until I've chased delegations to redbarn.org too. Even if I'm DNSSEC-validating your responses, you *could* be replaying an outdated answer with a still-valid signature, so I'm safest if I resolve each name in the CNAME chain separately. (I vividly remember a thread about this three or four years ago, but I'm having poor luck with the grepping.) -- 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-negative-trust-anchors-00.txt
On Tue, Dec 16, 2014 at 10:47:33AM +, Tony Finch wrote: That is a good point. Happily I think the draft already makes it hard for operators to do that, since an NTA will be automatically removed if its zone validates (section 10). Thank you for pointing this out, Tony; I'd missed it when I read the draft, and it would have been embarrassing if I'd gone ahead and posted my planned comment to the effect that there ought to be text like this. :) I will revise my planned comments to say there ought to be MORE text like this. First, some clarification of of attempt to validate the zone is probably called for. A resolver can't validate the entire zone; it can only spot- check. BIND's method, for the record, is to send a periodic query for type SOA at the NTA node; if it gets a response that it can validate (whether the response was an actual SOA answer or a NOERROR/NODATA with appropriate NSEC/NSEC3 records, which would imply that the NTA was placed at a node which was not a zone cut [1]), the NTA is presumed no longer to be necessary and is removed. (Note that under some circumstances, this is undesirable behavior -- for example, if www.example.com had a bad signature, but example.com/SOA was fine -- so we also provide a force option to set an NTA which is *not* subject to this periodic spot-check.) Second, I would upgrade the recommendation from optimally this is automatic to at least a SHOULD, and maybe a MUST. Third, it's implied in section 8, but I would add to section 10 that NTAs MUST expire automatically when their configured lifetime ends, and that this lifetime MUST NOT exceed a week. My biggest fear with NTAs is that someone will configure one and then forget about it forever. There should be an expiry date associated with every NTA, and it should be enforced by code. One final comment: in appendix A.2, the rndc nta description is outdated and should now read: nta -dump List all negative trust anchors. nta [-lifetime duration] [-force] domain [view] Set a negative trust anchor, disabling DNSSEC validation for the given domain. Using -lifetime specifies the duration of the NTA, up to one week. The default is one hour. Using -force prevents the NTA from expiring before its full lifetime, even if the domain can validate sooner. nta -remove domain [view] Remove a negative trust anchor, re-enabling validation for the given domain. [1] ... which we presume to be legal, but maybe ought to be clarified in the draft. Trust anchors are always at a zone apex; negative trust anchors don't strictly need to 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] Fwd: New Version Notification for draft-hoffman-dns-terminology-00.txt
On Tue, Dec 09, 2014 at 11:28:44AM +, Tony Finch wrote: This is not the usual DNS meaning of recursion. Referrals occur during *iterative* resolution. (Also, tangential to the point of this message, delegation NS records are not glue - if there is glue in the response, it isn't necessary to find the addresses of the NS targets!) I've seen glue used generically to describe any record returned in a response from an authoritative server for which that server is not itself authoritative; that *would* include delegation NS RRsets, as well as associated address records. I've also seen it used to describe any record in a parent zone that describes a child, even if the parent *is* authoritative, as with DS glue. Not saying either of those definitions is correct; just that they're not obviously wrong. It would be a good idea to nail it down. BIND has various functions with find in the name which deal with finding name server addresses. I don't think it has a more special name for this part of the iterative process. I call this delegation following (or sometimes delegation chasing), but I don't recall where I first encountered the term, and there may be a better one out there. -- 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-root-loopback
On Thu, Nov 20, 2014 at 11:13:42AM -0800, Doug Barton wrote: Slaving the zone into the same view/instance as the recursion has the advantage that when changes happen to the data in the zone the recursive view/instance will be updated as soon as it receives its copy of the zone. When using a separate view for slaving the zone the recursive instance will cache all of the queries it looks up. Currently the TTL for DS and delegation NS records is 2 days. Accurate summary, but as this is the same behavior as you get when using traditional root servers, I'm not sure it makes sense to characterize it as a disadvantage. -- 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-root-loopback
On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote: That seems like something that should be fixable in BIND, yes? (And thanks for doing that testing, btw) Yes, by using two views and slaving the root in one of them and validating in the other one, like it recommends in the draft. :) With a single view, if you're authoritative for a zone, then you're the authority, period. You *know* the corect answer. Validating yourself to find out whether you're lying to yourself would be somewhat silly. -- 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-root-loopback
On Sun, Nov 16, 2014 at 03:12:58PM -0800, Doug Barton wrote: Before commenting further I'd love the authors to flesh out their reasoning for not simply slaving the zone where possible. I'm not one of the authors, but I can give you an answer: in BIND, and I believe in other DNS implementations as well, local authoritative data isn't subject to DNSSEC validation. (And yes, I'm aware that one of the primary motivators is DNSSEC, but the only thing in the root that we care about are the DS records, and a validating resolver is going to chase those up to its trust anchor anyway.) No. If the root zone is slaved locally in the same view as the validator, then the server (correctly) sees the top level DS as local authoritative data, and presumes it to be valid. (I just tested BIND to confirm this. The log shows that org/DNSKEY, isc.org/DS, and isc.org/DNSKEY were validated, but org/DS wasn'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] Call for Adoption draft-wkumari-dnsop-root-loopback
On Sun, Nov 16, 2014 at 02:28:19PM -0800, Tim Wicinski wrote: In case I wasn't clear enough, the chairs will accept all the emails supporting the CfA from warren's previous email, so you'll not need to resend. I can't remember if I already said I supported adoption. If so, I support adoption again. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia (circleid)
On Tue, Nov 11, 2014 at 10:26:22PM -0800, Paul Vixie wrote: i don't know how to answer your discomfort. as you know i was responsible for f-root's anycast growth for many years; as you may not know i was responsible for as112's early growth after a bill manning experiment succeeded. AS112 absolutely proves that unowned anycast can work at scale; that's not my concern. But if my neighbor announces a route to the AS112 addresses, and then misconfigures a server, fills it with lies, or logs all my queries, the practical effect on me is pretty small: the worst case scenario I can think of offhand is that somebody gleans information about my internal network topology that probably wouldn't have been difficult to guess anyway. I believe there's more scope for an incompetent or malicious root server operator to block, surveil, or deceive me, and while there are defenses I can deploy against some misbehaviors, I think we need to be cautious about about a potential increase in the number of bad actors and failure modes. While I don't particularly share Andrew's camel's-nose-on-the-slippery-slope concerns about a root zone with a modified NS rrset, if I were going to use it myself, it would *only* be because I was deploying a local root instance on my own network or on the local host. If I weren't going to deploy it myself, then I'd stick to the traditional roots. I may not be typical in that respect, but if I am, then there's no need for unowned anycast anyway. -- 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-eastlake-dnsext-cookies
On Thu, Nov 13, 2014 at 04:55:36PM -1000, Tim WIcinski wrote: https://datatracker.ietf.org/doc/draft-eastlake-dnsext-cookies/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. +1 for adoption, and I can 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] Fwd: New Version Notification for draft-wkumari-dnsop-root-loopback-01.txt
On Tue, Nov 11, 2014 at 02:43:02PM -0500, Bob Harold wrote: Thanks, but what about the case where the zone transfers are refused and the root zone expires? My server is still running, but cannot answer for the root zone. That's a case where I want it to fail over to the real roots. If the slave zone expires, it's because your server isn't receiving transfers from *any* of the five root servers in the masters statement, and in that situation you'd be having troubles whether you used this configuration or not. I suppose some of the five might disable transfers while continuing to allow queries... but as long as one of them still supports transfers, you'd be okay. I'm confident that f-root, operated by ISC, will always support them. (Honestly, I don't know why it isn't a requirement for all the root ops. It's not like the zone contents are a secret.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia (circleid)
On Tue, Nov 11, 2014 at 06:14:44PM -0500, Andrew Sullivan wrote: But my point is that it's a different zone. Once you allow for the possibility that an apex record could change in this zone, why not change other records too? Because that's not necessary to address the technical issue this proposal is intended to address, and t would be undesirable for a host of other reasons, so, you know, let's not do that. And who gets to control this other zone? Same people that control the root zone now. It's no longer the root zone, by definition. It's an alternative zone, it seems to me. Yes, but with changes explicitly limited to the NS RRset, and not affecting any delegation content. Of course, this does suggest the idea of simply updating the one-and-only root zone to contain a single additional NS record: . IN NS [a-m].root-servers.net. . IN NS local-root. local-root. IN A 127.12.12.12 On a system that had a server listening and serving root at 127.12.12.12, a recursive resolver would prefer to use it for root queries because of the very short RTT. On a system that didn't, a few queries would be wasted to determine that the local-root address was nonresponsive, and then the server would carry on using the traditional roots. This is kind of a hybrid of the Lee/Vixie and Kumari/Hoffman mechanisms: ohh lord, kum-ba-yah. :) For the record, I'm not comfortable with the Lee/Vixie proposal that new root server addresses be globally routable and anycasted by anyone who wants to, but I'd be fine with it if they were localhost addresses, as above, or reserved nonroutable addresses similar to (but distinct from) RFC 1918 addresses. I also think Kumari/Hoffman has most of the same benefits at lower 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] A Preliminary Test for Loopback Server
On Mon, Nov 10, 2014 at 05:27:08PM +, Evan Hunt wrote:
Attached is a sample named.conf configuration which implements this using a
root view for the root zone slave, and a recursive view for recursion.
DNSSEC validation works correctly and the root zone will sync correctly.
One of these days I want to write a mail client that checks for the word
attached and refuses to let me hit send until I attach something.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
options {
directory /etc/bind;
listen-on { any; };
listen-on-v6 { any; };
};
view root {
match-destinations { 127.0.0.1; };
zone . {
type slave;
file rootzone.db;
notify no;
masters {
# b.root-servers.net
192.228.79.201;
2001:500:84::b;
# c.root-servers.net
192.33.4.12;
2001:500:2::c;
# f.root-servers.net
192.5.5.241;
2001:500:2f::f;
# g.root-servers.net
192.112.36.4;
# k.root-servers.net
193.0.14.129;
2001:7fd::1;
};
};
};
view recursive {
dnssec-validation auto;
allow-recursion { localnets; };
recursion yes;
zone . {
type static-stub;
server-addresses { 127.0.0.1; };
};
};
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
On Thu, Nov 06, 2014 at 08:24:35AM -0700, Paul Ebersman wrote: marka Which won't work in IPv6 unless you syntesize the records on marka demand. And that's the plan, at least for $DAYJOB. And sign on the fly for those of us signing our zones. I'm going to take the risk of embarrassing myself in public and ask the stupid thing I've been wondering: Is there a reason not to use wildcard PTRs? $ORIGIN 6.7.6.2.7.6.7.0.1.0.0.2.ip6.arpa. * 604800 IN PTR home-ipv6-customer.isp.net. This way, a PTR would exist for every address, so broken sshd and similar daemons will work. It's easy to grep for, so antispam folks should be content. The wildcard record can be signed, which is trickier to do with on-demand PTR synthesis. If you want to sell a customer their own PTR or delegated reverse zone, you still can. You don't end up with a unique PTR for each address, and you'll get answers for addresses that aren't in use... but those kind of seem like features, not bugs. Also, it's cheap. So, are there technical reasons not to do this, or is it just conceptual inertia from the use of $GENERATE for v4? -- 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 Reverse DNS in IPv6 for Internet Service Providers
On Thu, Nov 06, 2014 at 05:33:10PM -, John Levine wrote: This turns out to be a Well Known Bad Idea (WKBI). Most PTR checks look up the name to be sure there's a matching forward ( in this case) record, and ignore them if there isn't. I see. Too bad. Is it any more feasible to adjust expectations for v6 in this respect than it was when we were talking about not providing PTR for v6 in the first place? For whatever it's worth I've been running with a wildcard PTR for my hurricane-tunnel v6 network at home for more than four years. It's only a dozen or so addresses, but I haven't hit any obvious problems. -- 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 Reverse DNS in IPv6 for Internet Service Providers
On Thu, Nov 06, 2014 at 09:41:57AM -0800, Paul Hoffman wrote: I think Evan was proposing that home-ipv6-customer.isp.net would also exist, so a PTR check that looked for *existence* would succeed, but one that looked for *matching* would fail for most of those addresses. Do we know whether typical PTR checks look for existence or matching? Matching could work, too, if they were able to compare prefixes rather than full addresses, but that's obviously a bigger leap. I suspect John is correct and the idea isn't practical. Alas. Thanks for the education, carry on. -- 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-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive
On Tue, Oct 07, 2014 at 01:27:40PM -0400, Tim Wicinski wrote: The documents are: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ I support both, and will review if needed. -- 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-rfc6598-rfc6303-01
On Thu, Aug 21, 2014 at 12:17:25PM +1000, Mark Andrews wrote: If they fail it can fallback to making iterative queries or just accept the failure. I'd quibble with this bit: if it can make iterative queries, then we might as well just call it a validating resolver. IMHO the thing we're describing is an application that gets DNS service from a recursive resolver, but validates the answers rather than trusting them implicitly. It needs to be able to send the resolver a succession of queries to obtain the chain of trust, but it's not going to be iterating down from the root. The delv utility that ships with BIND 9.10 is an example. -- 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-zhang-dnsop-weak-trust-anchor.txt
If the verification is failed, it should response Bogus If the resolver do not get enough data to do the verification, then the resolver which weak trust anchor should be response with insecure DNS package. it is up to end-user or netizens to decide what to do next. If the resolver didn't get enough data, but should have, then the validation failed and the answer is bogus. Your proposal effectively promotes all bogus answers to insecure. -- 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-zhang-dnsop-weak-trust-anchor.txt
On Fri, May 30, 2014 at 02:11:45PM -0400, Paul Wouters wrote: Note also that for this problem, there is already a commonly deployed solution at the application level that addresses this situation, such as https://www.nlnetlabs.nl/projects/dnssec-trigger/ which will inform the user the network is severely broken or the user is under attack, and gives the user the option to disable DNSSEC and go insecure. Also negative trust anchors, which seems to have stalled in the IETF (http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-06) but has been implemented in some validators (and will be in BIND in a future release). I do not believe your stated problem is one that needs addressing. +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] NOTE RR type for confidential zone comments
So not to put too fine a point on it, but where is the use case for this proposal? It seems like something that is more of someone's cool hack than a standard people ought to implement. What am I missing? The first three I thought of when the Dan suggested the feature: 1) In the places I've worked, there have often been emails going around asking who's in charge of a particular machine or a particular IP address, that information having apparently been misplaced since the machine was set up or the address allocated. In geographically dispersed organizations it can be particularly hard to figure this stuff out. It would be nice to be able to leave breadcrumbs in the zone file and have them a) not get stomped on, and b) be retrievable by an administrator working in a colo cage somewhere by sending a suitably TSIG-signed query. 2) Over the years I've had to tell a dozen or so BIND operators who'd had disk failures on their master servers to fetch backup zones from slaves, and heard sadness at the loss of comments. (Also file ordering, but that's not something that NOTE can help with.) 3) Status comments could be added to zones such as signed by $version on $host at $date. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
On Wed, May 28, 2014 at 12:20:26PM -0400, Ted Lemon wrote: These are all examples of things that are ordinarily addressed by some kind of IPAM user interface. True, for the first two, at least, and the third could be solved on an implementation-specific basis by storing metadata outside the zone. But another way of saying that is: software exists that kluges around this lacuna in the DNS feature set, which doesn't mean it isn't a lacuna. Also, IPAM software isn't necessarily interoperable between different DNS implementations. (And there may be use cases I haven't thought of yet.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
On Tue, May 27, 2014 at 09:30:57PM -0700, Doug Barton wrote: On a purely stylistic level I agree with you. :) However this signal would only have to be sent when requesting a zone transfer, and the extra 32 bits would be in the noise. The direction of the wind being clear, I have redrafted the NOTE specification with a NOTE-OK option rather than a NO bit. (Thereby strangling in its cradle my secret plan to gradually aquire EDNS flags until they spelled DO NO TT AU NT HA PP YF UN BA LL, so I HOPE YOU'RE HAPPY.) http://www.ietf.org/id/draft-hunt-note-rr-01.txt -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] NOTE RR type for confidential zone comments
One of our operations staff made what I thought was a clever suggestion the other day: That it would be nice, from an operational standpoint, to have a way to encode comments into a zone so that they wouldn't get obliterated when a dynamic zone was dumped to disk, but couldn't be read by just anybody with access to dig. This draft proposes such a beast. Feedback would be lovely. http://www.ietf.org/internet-drafts/draft-hunt-note-rr-00.txt -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
On Tue, May 27, 2014 at 12:57:01PM -0700, Nicholas Weaver wrote: Using an EDNS0 bit however, does not makes sense to me. Flag bits are rare and precious, while 16b option codes are not. I was expecting this feedback, and am entirely prepared to redraft using an EDNS option if (when?) that turns out to be the group consensus, but I decided to ask for what I want first and get shot down rather than assume in advance that there was no chance. :) At the going rate of 1 EDNS bit allocated per 15 years of EDNS existence, we have enough to last until the year 2239, at which time an EDNS version bump could allocate more of them. So I concur with rare, but not necessarily with precious. However, there is no technical reason a flag bit is necessary. I just think it's more elegant. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NOTE RR type for confidential zone comments
On Tue, May 27, 2014 at 04:08:29PM -0700, Doug Barton wrote: I'm interested in why you think a flag bit is more elegant than an option, as I agree with Nicholas that the latter is preferable. As with any argument that resorts to elegance, it's a matter of taste. A single bit, which is already being sent though currently undefined, versus 32 bits that wouldn't otherwise need to be sent, and the unavoidable necessity of parsing OPT past the header. It just seems cleaner to me, and in the absence of other considerations it seems the obvious way to design a feature like this. (DNSSEC, by example, is a little bit like this: omitting some response data if a flag bit is not set.) However, other considerations do exist, and I'm not married to 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] key lengths for DNSSEC
On Wed, Apr 02, 2014 at 11:33:20AM -0400, Ted Lemon wrote: Bear in mind that all you _really_ have to do is get a bogus ZSK with the current time into the resolver, which you may be able to do with some clever NTP shenanigans over a relatively short timescale. But yeah, this isn't likely to be useful except in cases where a device has been powered off, doesn't have an accurate battery-backed-up clock, and does DNSSEC, which is a weird set of circumstances. I predict that will be a less weird set of circumstances in a year or so: dnsmasq now has DNSSEC validation in beta. (Tony Finch has a nifty idea to replace ntpdate with a quorum of tlsdate responses; it might still be subvertible but it would be a much harder nut to crack. https://git.csx.cam.ac.uk/x/ucs/u/fanf2/temporum.git) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] CD (Re: Whiskey Tango Foxtrot on key lengths...)
On Tue, Apr 01, 2014 at 06:25:12PM -0700, Colm MacC?rthaigh wrote: DNSSEC is a mitigation against spoofed responses, man-in-the-middle interception-and-rewriting and cache compromises. These threats are endpoint and path specific, so it's entirely possible that one of your resolvers (or its path) has been compromised, but not others. If all of your paths have been compromised, then there is no recovery; only detection. But that is always true for DNSSEC. Consider the scenario in which one authoritative server for a zone has been compromised and the others have not, and that one happens to have the lowest round-trip time, so it's favored by your resolver. If you query with CD=0, a validating resolver detects the problem and tries again with another auth server. It doesn't give up until the whole NS RRset has failed. If you query with CD=1, you get the bogus data and it won't validate. If you try again, you'll get the same bogus data out of the cache. Use a different resolver, and if it happens to use the same auth server, then the same thing happens again. Your best chance of getting an answer that you can validate is to send CD=0 to a recursive resolver that is itself validating. If you get SERVFAIL, *then* you try with CD=1, and if the result validates, you know it was the resolver that was broken rather than the data. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Unexpected behaviour of dig +trace
On Wed, Mar 26, 2014 at 06:52:44PM +0800, Warren Kumari wrote: Feature, but does catch many folk by surprise. I'd written a patch and given it to someone at ISC that makes dig output a warning message if you hand it both the +trace and @server options. Dunno what happened, but never got integrated... My apologies for not sending feedback directly. (That's something we really need to work on.) IIRC, we opted to clarify the documentation rather than add a warning to dig itself. There's also a knowledge base article on this topic at http://tinyurl.com/o37rpgm. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On Thu, Mar 06, 2014 at 02:50:20PM +, Stephane Bortzmeyer wrote: The only place where server authentication could be useful is between a stub and the first resolver. I think that's exactly the point that was under discussion, though: How can people who don't want their DNS traffic snooped and analyzed, but have decided for some reason to use 8.8.8.8 anyway, be sure they're talking to the real 8.8.8.8? :) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my dnse vision
On Thu, Mar 06, 2014 at 06:39:07PM +0100, Stephane Bortzmeyer wrote: It's a very valid and interesting point but it has not a lot of relationship with the privacy issues. I don't entirely agree: if a MITM can spoof a trusted remote resolver, then QNAME minimization won't help you. DNSSEC ensures that you get legitimate answers; it doesn't ensure that the server on the other end belongs to someone you trust to keep your queries confidential. I suggest that it deserves a separate effort, which could start with a nice I-D describing the problem statement/analysis (and then to proposed solutions). I agree it would be appropriate to treat stub-to-resolver channel security as a separate problem space. (I will note in passing that I'm intrigued by the CGA-TSIG draft being circulated by Mr. Raffieh.) Unless we want to solve all the security problems of the DNS at once, with the same solution? Oh, I didn't realize it was an option. Yes, that sounds excellent, please do 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] [dnsext] DNS vulnerabilities
On Fri, Nov 01, 2013 at 03:29:12PM +0900, Masataka Ohta wrote: TLS is another PKI and is inherently insecure as CAs can be compromised. True, but Tony's quorum-based approach could be made exhaustive enough that the adversary would have to have compromised *every* CA. If they can do that, I'm not sure any realistic defense is possible anyway. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
On Mon, Oct 28, 2013 at 04:57:46PM +0100, Marc Lampo wrote: How could a local time problem lead to using an expired (zone) key for arbitrary data of the zone ? There is a genuine theoretical concern here, but IMHO it's unrealistic. Imagine some shadowy omnipotent organization has tapped your connection to the internet and controls every packet you send and receive. Your router box (or other embedded device lacking an RTC battery) boots and requests the current time via NTP. The bad guys send a forged response indicating a time in the past, then they answer all DNS queries by replaying data that were captured at that time: the answers *used* to be valid, but they aren't anymore. Now suppose this no-longer-valid data includes a TLSA record for a certificate that's been compromised and revoked since then...? I can't see this as realistic for several reasons - among them, that it's easily detectable by anyone who happens to compare the clock on their router to what it says on their calendar, and I presume a shadowy omnipotent organization would have a strong preference for undetectability. I'd prefer provably impossible to insanely impractical if I had a choice in the matter, but the truth is, any adversary with the resources to pull this off would certainly have cheaper alternatives. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote: My colleagues and I worked on OpenWrt routers to get Unbound to work there, what you need to do is to start DNS up in non-validating mode wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation. That's roughly what we did with BIND on OpenWrt/CeroWrt as well. We also discussed hacking NTP to set the CD bit on its initial DNS queries, but I don't think any of the code made it upstream. My real recommendation would be to run an NTP pool in an anycast cloud of well-known v4 and v6 addresses guaranteed to be reliable over a period of years. NTP could then fall back to those addresses if unable to look up the server it was configured to use. DNS relies on a well-known set of root server addresses for bootstrapping; I don't see why NTP shouldn't do the same. (Actually... the root nameservers could *almost* provide a workable time tick for bootstrapping purposes right now: the SOA record for the root zone encodes today's date in the serial number. So you do the SOA lookup, set your system clock, attempt validation; on failure, set the clock an hour forward and try again; on success, use NTP to fine-tune. Klugey! :) ) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] public consultation on root zone KSK rollover
On Wed, Apr 03, 2013 at 05:17:35PM +0200, Stephane Bortzmeyer wrote: Was RFC 5011 actually tested in a real rollover with the current resolvers?) Depends what you mean by real. The BIND implementation has been tested with real keys, but obviously it's never been confronted with an actual real-world root-zone rollover. In principle there's no difference, but in practice I'm less confident: Rolling the root zone means exercising the RFC 5011 code in *many* validating resolvers, on different platforms with different configurations, and with high stakes in the event of failure. The possibility that we've overlooked a test scenario and some validators out there will fail to roll to the new trust anchor correctly is going to give me jitters until we've done it the first time. Then there's the issue Paul mentioned -- gear configured with a root KSK that gets switched off and not rebooted for a few months or years, and then no longer works and can't recover. Unfortunately, none of these concerns get smaller if we wait longer. -- 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 Negative Trust Anchors
On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote: i'm opposed to negative trust anchors, both for their security implications if there were secure applications in existence, and for their information economics implications. +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] KSK rollover
That is certainly relevant to rollover, but it doesn't specify any means by which the new DS records can be placed in the parent zone. You're correct, there's no mechanism for doing this within the DNS. You need to update DS records through your registrar just as you do with NS records and glue. I hear there's an effort under way to develop an in-protocol mechanism for DS tracking, but I don't know how far along it is. The mechanism that occurs to me is to have a new RRtype, say CDS, with identical format to the DS record, but placed in the child zone ( and signed by the child zone). You've got a chicken-egg problem there: How does the parent know it should trust the key that signed the CDS? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
hashes. However, NSEC records are sometimes returned in response to DO=0 queries, Wouldn't that be an implementation bug? Not if it was an ANY query. Otherwise, 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] rfc4641bis: NSEC vs NSEC3.
Using NSEC instead of NSEC3 because you fear SHA1 collisions does not seem sensible, as if you fear SHA1 collisions, you have other more significant problems with DNSSEC to worry about, and thus this is not, in my opinion, reasonable. And it isn't sensible to suggest users worry about it. If we are going to mention it, it should be in security considerations, saying NSEC3 is dependent upon certain properties of its hash algorithm (I forget now whether it is collision resistance, pre-image resistance or or what), but this should also point out the whole of DNSSEC is predicated on similar qualities. +1 except for the if. It is mathematically possible for collisions to occur with one approach and not the other, and it would be irresponsible not to make note of the fact, even if we agree that the chances of this occurring in nature are negligible. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
This is absurd. If we're going to do this, I'd like the security considerations to reflect all of the non-zero probabilities of errors occuring (those that have a higher probability). I just answered this point in private mail to someone else, failing to realize until after I'd sent it that it was off-list, so I'll repeat myself... My point is not to say that hash collisions are a problem or that NSEC3 is a poor choice. My point is that it's bad form to make mathematically false statements--even if they're *almost completely* true--and especially so when you get anywhere near cryptographers. NSEC3 is exactly as good as NSEC is a mathematical statement. It's very, very close to true, but in math that still makes it false. NSEC3 is as good as NSEC except under conditions so fantastically improbable that it's safe to ignore them is a few more words, but has the benefit of actually being *true*, and I think that's what the draft should say. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
I think Olafur's point is a good one, but I'm unhappy with the prose. Some suggested changes below. Same here. Nits: There are to mechanisms to provide authenticated proof of s/to/two/ Each mechanism includes a list of all the RRTYPEs present at the s/includes/stores/ The clear text version has its one RRtype for negative answer, Clear text one uses NSEC record and the obfuscated one used NSEC3. I didn't know how to rephrase that, because if I understand it I think what I understand is wrong (but that's obviously not the case, so probably I don't understand it). I think he meant each version has its own RRtype. Suggested change: Each mechanism uses a specific RRTYPE to store information about the RRTYPEs present at the name: the clear-text mechanism uses NSEC, and the obfuscated-data mechanism uses NSEC3. It may also be worth mentioning that the two mechanisms are usually referred to by the names of their corresponding RR types. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Key sizes was Re: I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt
That is fine, but so is 1024 bit KSKs. The text in RFC 4641bis makes it clear that KSKs should be rollable in case of an emergency; the effort to do so is greater, but not that much greater, than rolling a ZSK. Considering the necessity of getting new DS/DLV records into the parent/DLV zones and/or getting public keys properly distributed to everyone who needs them (either directly or via ITAR or other key repositories) it sure seems to me that the effort to roll a KSK is that much greater. Rolling a ZSK doesn't require coordination with anyone else. The WG should decide which seems better to recommend: a) KSKs longer than ZSKs because KSKs are thought of as needing to be stronger b) KSKs the same strength as ZSKs because neither should be weak enough to be attacked I prefer (b), but (a) keeps coming up in this discussion. It's a little imprecise, but I'm inclined to think of key lifetime as an aspect of key strength. A 1024-bit key that rolls over every week may be stronger, in a sense, than a 2048-bit key that stays around for twenty years--the second one could be broken within its lifetime, the first one probably not. IMHO it's reasonable to make recommendations with that tradeoff in mind; a ZSK may be as long as a KSK, or it may be shorter if it's rolled over more frequently. (I think 4641bis already says something along those lines.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
I presented the real-world statistical data to support my claim that DNSSEC requires to much work. That is, it is hardly deployed because it requires to much work. The reason it's hardly deployed is that people don't see the point. COM and the root zone aren't signed, so there's no perceived benefit. Most people would agree that *any* amount of work is too much when there's no perceived benefit. It would be more interesting to see what percentage of .SE and .BR domains are signed: There *is* some perceived benefit there, and an infrastructure in place. I would expect the cost/benefit analysis to shift in favor of DNSSEC under those circumstances. I actually agree with you that DNSSEC using BIND is more fiddly, arcane and time-consuming than it ought to be. (And I intend to improve it.) But that flaw is in the tools, not the protocol. There are lots of other things about network configuration that used to be fiddly and arcane and have since become simple; you seem to be arguing that DNSSEC won't follow suit, but I see no technical reason why it shouldn't. -- Evan Hunt -- [EMAIL PROTECTED] Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adopt draft-koch-dnsop-resolver-priming as WG work item?
None of the below makes any difference. We do not know what instructions Vixie has given Austein, and we do not need to know. The considerations for conflict of interest are well established: [...] Austein needs to avoid participating in issues that affect his company, its financial position, or that of his co-workers. Is this just a statement of general principles, or are you suggesting that in the particular discussion at hand, Paul Vixie's having expressed opinions about IPR claims, their effect on the RFC process, and the desirability for RFC's to be implementable in free/open-source software, constitutes a conflict of interest? Should Rob recuse himself from *any* matter that Paul's sent an email about? What about opinions Paul may have discussed with Rob privately? Or just things he's vaguely thought about, without saying anything? -- Evan Hunt -- [EMAIL PROTECTED] Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
