Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
* Daisuke HIGASHI: > draft-fujiwara-dnsop-fragment-attack-01: > >> 3. Current status >> >> [Brandt2018] showed that Linux version 3.13 and older versions are >> vulnerable to crafted ICMP fragmentation needed and DF set packet and >> off-path attackers can set some of authoritative servers' path MTU >> size to 296. >> >> The author tested Linux version 2.6.32, 4.18.20 and FreeBSD 12.0. >> Linux 2.6.32 accepts crafted "ICMP Need Fragmentation and DF set" >> packet and path MTU decreased to 552. Linux 2.6.32, Linux 4.18.20 >> and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and >> path MTU decreased to 1280. >> >> Linux version 4.18.20 may ignore crafted ICMP packet. > >I confirmed that Linux 4.18 (Ubuntu 18.10) accepts crafted ICMP > on "plain" UDP socket. And if sockopt IP_PMTUDISC_DONT is set to sockets > (many DNS implements do this) sender host generates fragmented packets > caused by crafted ICMP. > >Determining whether a DNS implementation on Linux accepts > crafted ICMPv4 or not is somewhat confusing and need to investigate > with caution: > > - Latest Linux seems to still accept crafted ICMPv4 by default. >Linux 3.15 introduced a new socket option IP_PMTUDISC_OMIT >which makes sockets ignore PMTU information and send packet with DF=0. >With this option sending socket never honor PMTU information and > fragmentation >is done if and only if the packet size exceeds outgoing interface MTU. > > - Some DNS implementation (BIND 9.9.10 / Unbound 1.5.0 and later) utilize > IP_PMTUDISC_OMIT option if available. So these DNS implementation on > Linux 3.15 (or later) > won't accept crafted ICMP. > (I submitted a patch to NSD for enabling this feature. > https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4235 ) Correct, this was the intent. There is another essential Linux kernel change: not using the path MTU when forwarding packets. Otherwise, a Linux hypervisor (or router), after receiving an ICMP packet directed to itself, would reassemble the packet and re-fragment it to the cached (spoofed) path MTU. I believe it's this commit: commit 69647ce46a236a355a7a3096d793819a9bd7c1d3 Author: Hannes Frederic Sowa Date: Wed Feb 26 01:20:41 2014 +0100 ipv4: use ip_skb_dst_mtu to determine mtu in ip_fragment ip_skb_dst_mtu mostly falls back to ip_dst_mtu_maybe_forward if no socket is attached to the skb (in case of forwarding) or determines the mtu like we do in ip_finish_output, which actually checks if we should branch to ip_fragment. Thus use the same function to determine the mtu here, too. This is important for the introduction of IP_PMTUDISC_OMIT, where we want the packets getting cut in pieces of the size of the outgoing interface mtu. IPv6 already does this correctly. > - Some Linux distribution is based on older version (like Linux 3.10) > but has IP_PMTUDISC_OMIT feature by backporting. > > I found that IP_PMTUDISC_OMIT feature is backported to Red Hat > Enterprise Linux 7 > (it's Linux 3.10 based) but they didn't backport corresponding macro > definition to glibc header. > So BIND9's / Unbound's IP_PMTUDISC_OMIT feature on current RHEL7 > won't be enabled > regardless of kernel feature. > (Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1684874 ) Yes, this is about to be fixed. But applications can use the constant directly if necessary (it's not architecture-specific and will never change). All in all, I do not think it is necessary or desirable to send DF=1 responses. The backwards compatibility impact would be too large. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
* Tim Wicinski: > For the ZONEMD RR Type, where in the registry do the authors think it > should go? While some of that falls on the Expert Review process, I think > the document authors should capture their rationale in the document. If > the proposed RR Type is greater than 256 (which I think it does), it does > not appear to require a Standards Track document, just Expert Review. There is some talk in the draft about blocking ZONEMD queries through recursive resolvers, which wiuld put it into the meta RR space, I think. (But I disagree that there wouldn't be a loss of functionality—if the ZONEMD record contained the size of the zone, clients might want to query it, verify its signature, and only download the specified number of bytes.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
* John R. Levine: > On Sat, 28 Jul 2018, Florian Weimer wrote: >> A malicious server might never stop sending data, or claim that the >> transfer is ridiculously large. If the zone digest does not include >> information about the amount of data, this can only be detected after >> the server ended transmission, at which time the ZONEMD digest can be >> compared. But at this point, the client may already have filled its >> storage with garbage data, unless the double transfer trick is used. > > I realize that hypothetically a malicious server could send you a large > file of garbage. But that can happen any time you downlaod a file from > anywhere. It doesn't strike me as something that needs special hackery > for this rather specific case. A lot of other updaters use HTTPS, which does not have this issue if the terminating party is also the source of the data. Those that do not use other mechanisms. There is quite a bit of previous work in this area (see <https://theupdateframework.github.io/> for specific take on this subject), and the current ZONEMD draft does not acknowledge this, even though its goals are broadly similar. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
* Paul Wouters: > Another reason for an rr count number in the rrtype. The typical RR size is perhaps 1/300 of the protocol maximum (much less without DNSSEC), so this is only sufficient for small zones. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
* John R. Levine: that the served zone is too large. Otherwise, the receiver has to download the entire zone before it can determine that the hash does not match. ... > >> On the other hand, clients will likely have a pretty good idea for the >> size of the zone, so they could transfer it twice: ... > > Now I'm really confused. To avoid downloading the whole zone you download > it twice? > > Could you explain in simple terms why you can't download the zone, check > the digest and signature, and either use it or discard it? A malicious server might never stop sending data, or claim that the transfer is ridiculously large. If the zone digest does not include information about the amount of data, this can only be detected after the server ended transmission, at which time the ZONEMD digest can be compared. But at this point, the client may already have filled its storage with garbage data, unless the double transfer trick is used. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
* John Levine: > In article <87h8kp7sqf@mid.deneb.enyo.de> you write: >>The ZONEMD record should contain a size indicator for the zone, >>something that allows a receiver to stop downloading if it is clear >>that the served zone is too large. Otherwise, the receiver has to >>download the entire zone before it can determine that the hash does >>not match. > > I don't understand why this is a problem that needs solving. Are we > really attacked by broken zone files with large amounts of added junk, > that are so large that reading them through before discarding them is > a practical performance problem? It's a practical problem if you want to update the zone from a completely untrusted source. I assumed that was in scope for ZONEMD. On the other hand, clients will likely have a pretty good idea for the size of the zone, so they could transfer it twice: Once for computing the authenticated size, in hashing-only mode, once they realize that the size of the new version exceeds the current version by 15% (or so). And after the authenticated size is known, they download the new version for real. This complexity could be avoided if the server simply told how many bytes have been hashed in the digest. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
* Duane Wessels: > I wouldn't be opposed to this in principle -- say an RR count field. That doesn't really bound the amount of transferred data, I think, because RR size can still vary widely. I believe something that counts the hashed bytes would be more helpful and about as easy to implement. > For this to be useful in an unsigned zone then all you need is for the > ZONEMD (with RR count field) to be received early in the AXFR. If it > is at the end then this field doesn't help. > > For a signed zone, we'd have to think about whether the ZONEMD record > should be DNSSEC validated before trusting the RR count field. If yes > then you need the signatures and NSEC* records too, so it becomes sort > of complex when you'd be able to trust and check the RR count. Could you query it before the transfer. > But it seems to me like this is better suited to be a feature of AXFR > in general, rather than ZONEMD. It depends on what you want to achieve with ZONEMD. If you want to prevent trivial, but potentially persistent DoS attacks with custom root servers, you need it in ZONEMD. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
The ZONEMD record should contain a size indicator for the zone, something that allows a receiver to stop downloading if it is clear that the served zone is too large. Otherwise, the receiver has to download the entire zone before it can determine that the hash does not match. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
* Paul Vixie: > in other words we should re-order rrsets by default, so that very few > people or agents are ever prone to think their order is stable. the spec > says they are unordered, but human nature says, expect more of what > you're seeing. But the client has to sort them again based on shared prefix length with its own address. I think we should fix that as well, otherwise the overall protocol disadvantages new entrants who cannot get a contiguous prefix in which they can place all their load balancer endoints, so that they are immune from that mandatory client sorting. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
On 06/15/2018 05:45 PM, Erik Nygren wrote: I suspect starting assumptions are roughly in the range of: * Recursive (and stub?) resolvers (SHOULD/MUST?) do some form of round-robin in RRset responses. * There are a variety of ways to implement round-robin (randomize, permute, etc). * Server operators need to be aware that round-robin may be a part of a load balancing scheme (especially if capacity is far greater than average demand) but should not be relied on exclusively. (Perhaps with examples of why...) Am I missing something in-terms of an existing BCP to this effect? Unless all addresses happen to have identical shared prefix length with the client address (that is, count-leading-zeros(client-address XOR server-address) is the same), RFC 6724 Rule 9 requires that clients do *not* perform random server selection. I think this was a mistake in RFC 3484, and it is still wrong. But I think procedurally, you cannot change this in a BCP. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested
On 04/13/2018 04:47 PM, bert hubert wrote: 2) Try: ping goes-via-embedded-nul.tdns.powerdns.org ping goes-via-embedded-space.tdns.powerdns.org. ping goes-via-embedded-dot.tdns.powerdns.org. None of these resolve when I try them, I wonder if that is because implementations want CNAMEs to be 'host names', or if this a chain of bugs. Not practically very relevant, but still. It is relevant because sometimes * wildcards leak into such CNAME chains: https://sourceware.org/bugzilla/show_bug.cgi?id=12154 glibc should just filter out such wildcards, and not completely reject the answer. (I think that stub resolvers should stop processing CNAMEs completely and use the actual QNAME, after search list processing, as the canonical name, but that is controversial.) I'm slightly worried that a naïve implementation of the skipping introduces a denial-of-service vulnerability because parsing many binary domain names can be quite costly, requiring millions of cycles and expanding to 6 MiB in total for 64 KiB packet. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Clarifying referrals (#35)
On 11/28/2017 08:50 PM, Andrew Sullivan wrote: That leaves the task of the referrals definition. I have some new text below: ---%<---cut here--- Referral: A type of response in which a server, signalling that it is not authoritative for an answer, provides the querying resolver with an alternative place to send its query. A referral contains an empty answer section. It contains the NS RRset for the referred-to zone in the authority section. It may contain RRs that provide addresses in the additional section. The AA bit is clear. Is the goal to describe behavior of current (and perhaps past) implementations, or what the behavior should be under ideal circumstances? Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt
On 09/21/2017 06:50 AM, Paul Vixie wrote: both ideas are wrong. what we have to do is arrange to fragment, using the ipv6 extension header, all ipv6 udp, for a period of not less than five years. noone who blocks ipv6 extension headers should be able to get reliable ipv6 udp services. we have to make this problem felt where it is made. we must NOT work around it to insulate the makers of the problem from the costs of their actions. I disagree with this approach. Just avoid fragmentation altogether. We know that it's harmful and can be used to bypass existing DNS hardening features. Within five or ten years, packet rates have increased so much that the additional protection afforded by the 32-bit reassembly ID in IPv6 isn't sufficient anymore, either. IP fragmentation is dead. Use something else. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Redefining name canonicalization
On 04/21/2017 05:08 PM, Bob Harold wrote: I can understand you wanting a "getfqdn" function to return the FQDN (fully qualified domain name) without doing canonicalization. But just so we are clear on the DNS terms, "access.redhat.com" and "access.redhat.com.edgekey.net" are "aliases" "e133.b.akamaiedge.net" is the canonical name. access.redhat.com is an alias for access.redhat.com.edgekey.net. access.redhat.com.edgekey.net is an alias for e133.b.akamaiedge.net. e133.b.akamaiedge.net has address 104.67.69.246 I'm aware of the terminology. I just think that in terms of RFC 3493, it would make sense to restrict the name transformation applied with AI_CANONNAME on the current internet, i.e. clarify that here If the AI_CANONNAME flag is specified and the nodename argument is not null, the function shall attempt to determine the canonical name corresponding to nodename (for example, if nodename is an alias or shorthand notation for a complete name). “alias” does not refer to CNAME chain resolution, but other forms of alias processing (like the slightly historic HOSTALIASES processing). This would help to address long-standing security issues in name canonicalization, e.g. in Kerberos deployments. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RCODE and CNAME chain
On 04/27/2017 11:31 AM, Mark Andrews wrote: If you want to advocate for changes to behaviour that is fine, but advocate for that. Just saying "shouldn't the rcode be NOERROR" isn't doing that. Then there is DNSSEC. If the target zone is signed and DO=1 is set in the query should you include the data from the target zone? Do you suggest to use data which is impossible to use under the trust rules because it is cryptographically signed? This would mean that many DNSSEC validation bugs turn into critical cache poisoning bugs because they can be used by off-path attackers to poison caches. (Usually, a single query for an attacker-controlled name would be enough, and it could likely be a PTR query.) I'm not sure if saving a server round-trip is worth it. In particular since the recursive resolver already has the infrastructure records for the target in cache if it can do cryptographic validation, it should know exactly where to fetch the target record anyway. In general, cryptography as the single line of defense is a very, very bad idea because it almost never works correctly. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On 04/20/2017 08:36 AM, Evan Hunt wrote: On Wed, Apr 19, 2017 at 10:47:24PM -0400, Paul Wouters wrote: ANAME could just be a regular RRTYPE without any special handling, meaning "go look there for up to date information on A/". It could come along A/ records using one of the existing bitmaps multi-type query proposals that have been suggested in the last two years. But, because there are always going to be legacy servers, the client would then need to send an ANAME query, and when it got no answer, send another query for A and . If clients were willing to do that, then they'd have been willing to use SRV, and we'd have standardized on that long since. This is simply not true. SRV is broken for almost any purpose, which is why it is only used for protocols which have mandated its use. Most name lookup interfaces only take a name and return an address. With these interfaces, it is technically impossible to synthesize a query name for a SRV lookup, and return the port number in the SRV record to the caller. (This even true for the RFC 3493 interface, which is often used without a service name argument, or a numeric service name.) An ANAME query to find a substitution name does not suffer from this problem. It fits well with existing name lookup interfaces. Which would've been fine, but browser vendors have had years to do it, and they never have. Why are you focusing on browsers? This is about the system name resolution service, which browsers still use to perform NIS/WINS/LDAP host name lookups, not just DNS. As I tried to explain above, SRV is incompatible with most of the traditional system name resolution interfaces. A name substitution with an ANAME redirection would not have this problem. Apparently, what they want is to send address queries and get redirected answers. And if we can't make them do the smart thing, at least we can give them an interoperable and standards-compliant way to do the dumb thing. I have no idea how to map most URI schemes to SRV lookups and resolve conflicts between port numbers, transport protocols in use (e.g., if QUIC is active), and service names (should an XMLRPC request get a different name?). Without that mapping, there is nothing that browser vendors could implement. What I'm trying to say: The SRV failure is not sufficient evidence that client-side name substitution would not see significant uptake because SRV works at the wrong layer(s). Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On 04/11/2017 10:47 PM, Evan Hunt wrote: On Tue, Apr 11, 2017 at 10:20:31PM +0200, Florian Weimer wrote: And in order to accommodate them, we upgrade the DNS server infrastructure across the Internet? Them, and web browser implementers who just don't want to use SRV. SRV wouldn't work anyway because it is incompatible with existing name resolution interfaces anyway. If you do not insist on using SRV, but something that is just an alias (like PTR, ANAME etc.) and processed in the client, it would be quite straightforward to put this into the stub resolver, and then all applications[*] would automatically get the addresses at the substitution name (SNAME). Disallow multiple substitution names per owner name and their chaining (but chaining to CNAME would be okay), and I think it would just work. But then DNS operators will worry about a 50% (from A/ to A//SNAME) to 150% (from A/ to A//SNAME plus A/ at the SNAME) increase in query load. (SRV would be worse because there could be multiple target names, all needing separate processing.) Would that be acceptable? I don't know. In fact, Firefox already solved the issue in the client: If you enter the zone apex, and no address record exists, it automatically redirects to the www name in the zone. Unfortunately, DNS operators broke that when they started rewriting NODATA responses, injecting ads into existing domains. So you really have to have addresses at the zone apex these days. Thanks, Florian [*] At least all applications which correctly deal with enterprise name lookup, which can involve NIS and LDAP, too, not just DNS. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On 04/11/2017 10:16 PM, Evan Hunt wrote: On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote: I don't see how you can detect loops without DNS protocol changes. The query that comes back will look like a completely fresh query. We can put a limit on the number of hops that are followed in populating the A and records for the expanded ANAME response. If that limit is exceeded, the ANAME record could be rejected by the auth; either the zone wouldn't load or address queries return SERVFAIL. But what happens when the target server also performs cache filling at the same time? Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On 04/11/2017 10:15 PM, Tony Finch wrote: On 11 Apr 2017, at 20:39, Florian Weimer wrote: On 04/11/2017 09:15 PM, Tony Finch wrote: That doesn't work if the web server is at 3rd party provider A but you want provider B's mail service not provider A's. I don't understand. I think it boils down to who operates the target DNS zone and how flexible they are. It has nothing to do with who runs the web server. In many cases the ANAME target will be a mass web hosting provider which doesn't have any flexibility in their DNS setup. And in order to accommodate them, we upgrade the DNS server infrastructure across the Internet? I understand that's how things work in practice, but I don't kike it. And you still don't want CNAME pointing at MX because of the interop problems. CNAME to MX is fine. Isn't this what's relevant here? Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On 04/11/2017 09:15 PM, Tony Finch wrote: On 11 Apr 2017, at 20:09, Florian Weimer wrote: On 04/11/2017 08:42 PM, Tony Finch wrote: If you have a subdomain that needs to be a mail domain and a web site, you need an MX pointing at your mail server and address records pointing at your web server. You can't use a CNAME because they are usually different servers. That's not a problem, you can have MX records at the CNAME target. That doesn't work if the web server is at 3rd party provider A but you want provider B's mail service not provider A's. I don't understand. I think it boils down to who operates the target DNS zone and how flexible they are. It has nothing to do with who runs the web server. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On 04/10/2017 12:04 PM, Peter van Dijk wrote: Section 3 is currently written in such a way that a recursive DNS lookup must be performed at the authoritative server side. I don't think it is necessary to require that. A recursive DNS lookup of the target is just one way to implement this. What other ways did you have in mind? Private arrangement with the target zone operator (that is, direct, out of-band access to the zone). In particular, the suggested recursive DNS lookup needs some form of distributed loop detection. Otherwise, a malicious customer could publish two zones with ANAME records and achieve significant traffic amplification, potentially taking down the DNS hoster. A hop count in an EDNS option or an “ANAME lookup in progress” indicator would be one way to implement this. Another approach would impose restrictions on the owner name of an ANAME record and its target, and restrict where CNAMEs can appear, so that a valid ANAME can never point to another valid ANAME. I’m not sure it’s feasible to forbid chaining ANAMEs. I do agree there is a vector for DoS here. Section 6 currently cowardly says “Both authoritative servers and resolvers that implement ANAME should carefully check for loops and treat them as an error condition.” but I am aware that more words are needed. I don't see how you can detect loops without DNS protocol changes. The query that comes back will look like a completely fresh query. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On 04/11/2017 08:42 PM, Tony Finch wrote: Paul Wouters wrote: Can you give me an example of deploying ANAME outside the zone APEX that is not solved by allowing a CNAME to point to a CNAME (which most code I think already allows anyway) https://www.ietf.org/mail-archive/web/dnsop/current/msg19909.html If you have a subdomain that needs to be a mail domain and a web site, you need an MX pointing at your mail server and address records pointing at your web server. You can't use a CNAME because they are usually different servers. That's not a problem, you can have MX records at the CNAME target. Also, mail domains cannot in practice be CNAMEs because of the disaster of RFC 821 / RFC 1122 mail domain canonicalization. I can see why this is a concern, but does current sendmail still rewrite the headers? (The envelope recipient is far less problematic.) Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On 04/11/2017 05:45 PM, Tony Finch wrote: Florian Weimer wrote: I think the introduction should discuss why it is not possible to push the CNAME to the parent zone, replacing the entire zone with an alias. You can't replace an entire zone with a CNAME if it has subdomains. ANAME records are not just for zone apexes. There are lots of other cases where address records need a different alias target from MX records, or NAPTR records, etc. Sure, but the document should list that. FWIW, I think the real problem is that it is perceived as cheaper to upgrade DNS servers than to support CNAME records in the provisioning infrastructure. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
On 04/07/2017 08:11 PM, Evan Hunt wrote: Title: Address-specific DNS Name Redirection (ANAME) I think the introduction should discuss why it is not possible to push the CNAME to the parent zone, replacing the entire zone with an alias. Section 3 is currently written in such a way that a recursive DNS lookup must be performed at the authoritative server side. I don't think it is necessary to require that. A recursive DNS lookup of the target is just one way to implement this. In particular, the suggested recursive DNS lookup needs some form of distributed loop detection. Otherwise, a malicious customer could publish two zones with ANAME records and achieve significant traffic amplification, potentially taking down the DNS hoster. A hop count in an EDNS option or an “ANAME lookup in progress” indicator would be one way to implement this. Another approach would impose restrictions on the owner name of an ANAME record and its target, and restrict where CNAMEs can appear, so that a valid ANAME can never point to another valid ANAME. Thanks, Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Mandated order of CNAME records in a CNAME chain?
* Mark Andrews:
> In message <87bmz3p4lt@mid.deneb.enyo.de>, Florian Weimer writes:
>> * Robert Edmonds:
>>
>> > I think there was already a thread on this topic recently on this list
>> > ("Order of CNAME and A in Authoritative Reply" from August 2015). There
>> > was some discussion over "adding" versus "appending" and it was pointed
>> > out that a lot of existing code (e.g., the BSD stub resolver) was
>> > written using the "add at the end" meaning.
>>
>> Are there stub resolvers which actually chase the CNAME chain?
>>
>> I assume it is quite common just to check the QNAME, and then extract
>> A/ records from the answer section without matching their owner
>> names (but potentially recording their owner name as the canonical
>> name of the host, even though that's rarely useful these days).
>
> No. libresolv has checked the owner names of the A (and )
> records for decades now skipping any records that don't match.
Okay. Is it necessary to retain those checks and even fix them to
avoid the CNAME ordering assumption?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Mandated order of CNAME records in a CNAME chain?
* Robert Edmonds:
> I think there was already a thread on this topic recently on this list
> ("Order of CNAME and A in Authoritative Reply" from August 2015). There
> was some discussion over "adding" versus "appending" and it was pointed
> out that a lot of existing code (e.g., the BSD stub resolver) was
> written using the "add at the end" meaning.
Are there stub resolvers which actually chase the CNAME chain?
I assume it is quite common just to check the QNAME, and then extract
A/ records from the answer section without matching their owner
names (but potentially recording their owner name as the “canonical
name” of the host, even though that's rarely useful these days).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free
On 03/23/2016 09:03 PM, Andrew Sullivan wrote: > I don't understand how it's a way to evaluate this claim. DNSSEC > includes a bit (DO) that says you're prepared to handle the additional > data in the answer section. Indeed, the unpreparedness of people for > this data was just exactly the reason for the DO bit. What isn't > clear to me is whether people implemented that as, "Take whatever > comes in the answer even if you didn't ask for it," or whether they're > looking for DNSSEC data. The latter is what DO says one is prepared > to do. DO was used initially for SIG and kept for RRSIG. For an early DNSSEC implementation, RRSIG was just another unsolicited RR type because it could only know about SIG. This suggests (to me at least) that practically speaking, DO isn't strongly tied to DNSSEC. Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free
On 03/22/2016 12:45 AM, Marek Vavruša wrote: > there was an interest in reducing latency for address record lookups. > Me and Olafur wrote a draft on adding records to A answers and > treating them as authoritative. This fixes latency issues with NS > A/ discovery in resolvers and improves caching for clients ( > already cached by the time client comes asking for it). > > Comments, feedback and snarky remarks would be great! > https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/ The glibc stub resolver already implements this draft in its response processing by accident. I was planning to fix that. I don't see how this proposal reduces latency or server load. We still have to do dual A/ queries. In the majority of cases, there is no record, so we have to wait for the second reply to arrive. We could reduce server load by sending the query only after the A response, but we'd have to send it in most cases because we cannot take absence of an RRset as proof of its non-existence. On the server side, doing lookups for all incoming A queries, on top of A lookups, isn't free (although it should be fairly cheap because the server at least knows where to send the query). Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free
On 03/22/2016 01:15 AM, Paul Vixie wrote: > > > Marek Vavruša wrote: >> ... >> >> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/ > > +1. we ought to have done this from the get-go. It did not work back then because unexpected RRsets in the answer broke resolvers. This is how we got the DO flag, I think. I doubt was any different from SIG in that regard, unknown is unknown after all. Therefore, technically, sending along should only be done for replies to DO=1 queries because there is a reasonable expectation that the recipient will be able to deal with unexecpted RRsets. Florian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Big reduction in the number of TLD zones blocking EDNS(1) queries
On 08/09/2015 01:29 AM, Joe Abley wrote: > At a guess I would imagine that the widespread interest in the most > recent BIND9 assertion failures with TKEY queries have caused code to > be upgraded everywhere. That seems unlikely to me. Many operators only deploy minimal changes, *especially* during an unscheduled security update. If you were running BIND 9.3 before, you are essentially running it afterwards as well. -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard
* Stephane Bortzmeyer: > On Wed, Jul 15, 2015 at 02:22:58PM -0700, > Francisco Obispo wrote > a message of 48 lines which said: > >> Well, even worse, what happens if decides >> to create a new dns-like protocol that uses .foo, does that mean >> that we should automatically block it? > > No need to speculate about "what happens". It already happened, the > vendor was Apple and the result was the registration of .local (first > use of RFC 6761). Wasn't this part of RFC 6761 specifically created to allow the reservation of .LOCAL, resolving the ICANN/IETF deadlock that had prevented this before? (In other words, the causal relationship is different, so it's not really an example of what could happen.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] another way to minimize ANY responses
* Tony Finch: > What does 2 return to 3? It can't send a signed NSEC because DO=0. ANY is special, you can get NSEC and RRSIG in responces with DO=0 (some implementations do that). With suitably aligned TTLs, I suppose you can even end up with just a NSEC/RRSIG RRset pair. NSEC3 is different because of the QNAME mismatch. There, the problem you describe actually exists, I think. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] another way to minimize ANY responses
* Evan Hunt: > 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.) Yes, this looks quite reasonable. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
* Olafur Gudmundsson: >> On Mar 18, 2015, at 11:55 AM, Paul Vixie wrote: >> >> we need a document that says "If you don't want to answer ANY, >> here's how to do it interoperably." we don't need to say "you >> should not answer ANY", but we do need to say "if you want to query >> for ANY, here's what might happen." that, sir, is a killing. we are >> killing ANY. there's no pretense. > > This is exactly what my goal is tell the upstream the type ANY will > not be answered. Upstream? Is reducing the number of ANY queries an immediate goal of yours? (Discounting any indirect effect that useless ANY answers will have on future application changes.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
* Paul Vixie: >> As a counterexample, RFC 6891 requires FORMERR responses without OPT >> RRs from implementations which do not support EDNS: >> >>Responders that choose not to implement the protocol extensions >>defined in this document MUST respond with a return code (RCODE) of >>FORMERR to messages containing an OPT record in the additional >>section and MUST NOT include an OPT record in the response. > > this language was very careful. older implementations cannot > "choose" behaviour relative to this standard. so, as an example of > what you're trying to convey, this text fails. They could patch the RCODE in the header and reflect the packet. That used to be a valid implementation option, and it was sort-of assumed by the previous EDNS0 version with its extended label types. It was the only way to generate a FORMERR response when you could not parse even the QNAME. (Or you could say that EDNS0 encouraged matching responses based on transaction IDs only, but let's not go there.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
* W. C. A. Wijngaards: > +1. Backwards compatibility means you cannot specify that existing > implementations have to change. Does it matter if they do not exist or are not considered practically relevant? As a counterexample, RFC 6891 requires FORMERR responses without OPT RRs from implementations which do not support EDNS: Responders that choose not to implement the protocol extensions defined in this document MUST respond with a return code (RCODE) of FORMERR to messages containing an OPT record in the additional section and MUST NOT include an OPT record in the response. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt
On 03/17/2015 04:16 PM, Christian Grothoff wrote: > it's a Lex Facebook, just like reserving ".local" was a Lex Apple. I'm not > generally against those at all, but I personally dislike that IETF > passes things > quickly if they are backed by multi-billion dollar companies, The reservation of “local” took more than a decade if I remember correctly, and it did not benefit just Apple. -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-ogud-dnsop-acl-metaqueries
* Tim Wicinski: > This starts a Call for Adoption for draft-ogud-dnsop-acl-metaqueries > > The draft is available here: > https://datatracker.ietf.org/doc/draft-ogud-dnsop-acl-metaqueries/ No real comments on adoptions below, just some technical issues. Is there are definition now what constitutes a meta-query or a meta type? Anyway, this draft makes makes it valid to respond to unknown RR types in queries with NOTIMP instead of NODATA or NXDOMAIN. Do we want that? (Authoritative servers with this behavior have seen some deployment.) NOTIMP is a poor choice for an ACL mechanism because most existing recursive resolvers will not cache it *and* will treat it as a hint to try another upstream server. The draft should be clearer about how to “suppress” a query. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
* Tony Finch: >> Evan Hunt wrote: >> > >> > 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. > > Maybe this could be a use for the NULL RRtype? :-) 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
* Evan Hunt: > (It doesn't address qmail's problem, but that's a lost cause no > matter which method is chosen.) I think it does. qmail already copes correctly with a partially cached ANY response (due to TTL mismatch between RRset), does it? The new behavior just looks like a partially cached response all the time. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
* Evan Hunt: > 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? Yes, I do. > They don't need to understand it, they just need to be able to receive > it without choking. Correct, or not too much choking. Entering a fallback path is acceptable and the desired behavior (if you can speak of such in this context). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
* Tony Finch: > I also tried a stupid hack to send an ANY RR in the response. BIND's > resolver treats this as a FORMERR and returns SERVFAIL to the client. What about introducing a new non-meta RR type for this purpose? It would not increase the response size by much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt
* Olafur Gudmundsson: > Title: Standard way for Authoratitive DNS servers to refuse ANY NOTIMP doesn't do that, it tells resolvers to query another name server for the zone. The authoriative server part of this proposal increases the number of upstream ANY queries instead of reducing them. I don't know if REFUSED is any better in this regard, probably not. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Definition of "validating resolver"
* Ted Lemon: > On Mar 8, 2015, at 6:31 PM, Ralf Weber wrote: >> I was told that the difference is that a security aware resolver does >> not validate, but instead relies on the "Validating Stub Resolver" to >> protect the user. So it would handle all the DNSSEC processing to the >> authoritative and would store the records with signatures in the cache, >> but it wouldn't check if they are valid. > > Doesn't this create an opportunity for a DoS attack based on > poisoning the cache with a record that won't validate? Yes, but that's inherent to DNSSEC and not specific to this configuration. For instance, you might cache bad glue records, which also prevents using DNSSEC to see that they are bad. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 03/12/2015 11:36 AM, Jan Včelák wrote: >> And does anyone actually use opt out with NSEC3? > > Yes, .com for example. My impression was that Opt-Out was the selling point > of > NSEC3, not the domain name hashing. Okay. Are they interested in switching to NSEC5? -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 03/12/2015 11:15 AM, Jan Včelák wrote: > On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote: >> Why not just do something simpler? The only thing NSEC5 really differs in a >> way that counts is not in the NSEC record but really just the DNSKEY >> handling, having a separate key used for signing the NSEC* records. >> >> So why define NSEC5 at all. >> >> Instead, just specify a separate flag for the DNSKEY record, "NSEC-only", >> sign the NSEC3 dynamically, bada bing, bada boom, done! > > This would not work. Anyone holding the NSEC-only private key could fake > denying answers for the zone. So if your zone is slaved by a less-trusted > party, they could still manipulate your zone. This is not possible with NSEC5. They can still respond with SERVFAIL instead of supplying a signed answer, achieving roughly the same result. A better argument would be support for opt out, where signatures from the online key could introduce unauthorized positive answers. It's still not a very strong argument, admittedly. The DNS software itself is likely signed by a key which is kept online (more or less). Online keys are less threatening than they used to be, and we aren't even talking about long-term keys baked into software, but short/medium-term keys which are easily replaced. And does anyone actually use opt out with NSEC3? -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 03/11/2015 05:19 PM, Jan Včelák wrote: >> It's not clear if the security goals make sense. What do zone operators >> gain if zone enumeration attacks are moved from offline to online, other >> than a need to provision additional server capacity? It's not that they >> can block resolution requests from large resolvers if a part of their >> client population participates in aggressive enumeration. > > It dependes whether you see zone enumeration as a problem. If I really want to enumerate a zone, I will just send my dictionary as queries, possibly through open resolvers. People are reckless like that. At least with NSEC3, polite attackers can do some of the processing off-line, without punishing authoritative servers or resolvers. NSEC5 takes away that option. Do the existing enumerators care? Who knows. >> Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in >> [RFC6234].” Are you sure that's right? > > You mean the reference to the RFC? Yes, I think it's right. Or am I > missing something? I'm guessing, but “NSEC5 hash” is probably what involves FDH. Based on your comment,s it's clearly *not* SHA-256, contrary to what I quoted above. > We deal with NSEC5 proofs and NSEC5 hashes (see the Terminology > section). The NSEC5 proof is the FDH (can be comptuted only by the > holder of the NSEC5 private key); the NSEC5 hash is an SHA-256 hash of > the NSEC5 proof (everyone can compute it, if they know the NSEC5 proof). > > So in your notation, an NSEC5 RR owner name should be: > Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey))) And the inner part (without the Base32 encoding) is the NSEC5 hash? Or is the SHA-256 hash skipped? You really need to make this explicit. > I agree that the description is insufficient. We will fix that. Thanks. -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Comments regarding the NSEC5
Hi Jan, do you plan to submit this to an IETF working group, or as an individual submission? It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in [RFC6234].” Are you sure that's right? In any case, most references to “NSEC5 hash” are underspecified. For example, in section 9.1, “The owner name of the NSEC5 RR is the NSEC5 hash of the original owner name encoded in Base32hex without padding, prepended as a single label to the zone name”, could be read in various different ways. It seems that Base32hex(SHA-256(Wire-Encode(owner name))) is meant, but it could also be read as SHA-256(Base32hex(owner name)) or something like that. There does not seem to be anything in the draft that describes how the RDATA of the NSEC5PROOF is computed. I think the intent is that it contains SHA-256(Wire-Encode(NSEC5 owner name)), and the validation is performed using a separate RRSIG record, signed with the NSEC5KEY public key. However, section 9.2 does not mention that the NSEC5PROOF record is accompanied by an RRSIG RRset. The rollover mechanism in section 9.3 does not work reliably. The old public key must be kept around until the TTL on the old NSEC5 and NSEC5PROOF RRs have expired (after the authoritative servers stopped serving them). The old public key cannot be removed immediately. It must be possible to re-fetch it in case a caching resolver expired it for some reason. In Section 11.1, “at least one of the keys MUST validate”: This MUST is misleading because the section is about validator behavior, it needs to be lower case because this section cannot establish constraints on validator input. There needs to be some discussion regarding the TTL on the NSEC5PROOF record, the validator should not accept arbitrary values there. These days, online signatures should really use a non-deterministic signature scheme. The deterministic FDH algorithm is very difficult to implement correctly. But it is not actually referenced in the draft, there are no protocol elements that use FDH values. As specified in the draft, the NSEC5 protocol still exposes the chain of SHA-256 hashes of owner names. It does not offer better protection against offline dictionary attacks than NSEC3. Florian -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Followup Discussion on TCP keepalive proposals
* John Heidemann: > DNS over TCP/53 is *already* persistent. No *protocol* changes are > needed. If you want to make the connections full-duplex instead of half-duplex, you need to negotiate connection teardown at the DNS layer. Otherwise, the TCP connection teardown will result in loss of already-transmitted responses. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
* Mark Andrews: > ENAME could be used immediately once the authoritative servers for > the zone support it. It would just be insecure until validators > catch up. Uhm. Why insecure and not bogus? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
* Mark Andrews: > In message <87y50auqqf@mid.deneb.enyo.de>, Florian Weimer writes: >> * Mark Andrews: >> >> >>>Another note is that the answer to the NS query, unlike the referral >> >>>sent when the question is a full qname, is in the Answer section, not >> >>>in the Authoritative section. It has probably no practical >> >>>consequences. >> >> >> >> Most resolvers do not make NS queries, and some authoritative servers >> >> do not return useful data (or any data at all). So using NS queries >> >> for zone cut discovery does not work reliably. >> > >> > Any resolver that is DNSSEC aware will make NS queries (whether >> > validating or not). >> >> Really? Where is this mentioned in the protocol RFCs? > > RFC 3658 > 2.2.1.2. Special processing when child and an ancestor share > nameserver I think this section is about DS queries, not NS queries. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
* Mark Andrews: >>>Another note is that the answer to the NS query, unlike the referral >>>sent when the question is a full qname, is in the Answer section, not >>>in the Authoritative section. It has probably no practical >>>consequences. >> >> Most resolvers do not make NS queries, and some authoritative servers >> do not return useful data (or any data at all). So using NS queries >> for zone cut discovery does not work reliably. > > Any resolver that is DNSSEC aware will make NS queries (whether > validating or not). Really? Where is this mentioned in the protocol RFCs? > Nameservers that fail to handle NS queries are broken. More NS > queries would be good for the overall health of the DNS as it would > flush out the broken servers. Sure, but in practice, no one wants to be the person who exerts this perssure on zone publishers. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] An approach to DNS privacy
* Phillip Hallam-Baker: >> If your ordinary resolver operator is a "carrier" is somewhat >> questionable, but resolver operators generally comply with requests >> for cleartext copies of traffic transitioning through their networks. >> >> I have no doubts that these operators will ask implementors to add the >> necessary features to keep these capabilities--or they will just turn >> on indiscriminate query logging. > We are not a carrier or an obligated party. We aren't, but the people who run our protocols and code mostly are. If they aren't, they comply with most requests directed at them just to avoid being declared a carrier or an obligated party explicitly. > The model where the carrier provides DNS resolution is bogus and > obsolete for the reasons you cite. I think we are being to see a move in a different direction, where end users are no longer in a position to run resolvers. For me, that's not just theoretical because I've been forced to switch hosting providers because my current one filters DNS traffic to certain ISC.ORG name servers, apparently in an ill-advised attempt at prevent their customers from taking part in amplification attacks. > People are tired of being spied on without due process. Lets see some of > the Abu Ghraib torturers facing criminal trial. And more encryption helps with that how? Abu Ghraib would have been just another prison with an abuse problem without the pictures leaking out. Proper cryptography with extensive key management could have prevented that. It is difficult to predict how technology will be used. A decade or two ago, many of us thought that encryption and the ubiquity of software vulnerabilities (or the fallibility of information systems in general) would help to keep powerful governments in check. When I first sketched the technology that is now cited in quite a few DNS privacy discussions, I thought I was doing something genuinely helpful. Now the picture is less clear. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
* Florian Weimer: > There is another privacy-enhancing approach that is not mentioned in > the draft: defensive delegations. For example, with current resolver > behavior, the lack of a delegation for 1.E164.ARPA means that queries > under that tree are sent to the E164.ARPA servers, which are scattered > around the globe. With a delegation, the delegation would be cached > and queries could be kept locally in the region. And another one: If you make your queries against a local copy of the DNS tree (which has been made irrespective of future demand), then nobody else will now which DNS records you are intersted in. This approach obviously weighs query privacy over database protection (whether as someone's intellectual property or with regards to domain owner privacy). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] An approach to DNS privacy
* Phillip Hallam-Baker: > But first, cite actual legal authority because I don't believe your > interpretation of the law is remotely correct. § 8 Abs. 3 TKÜV: | Wenn der Verpflichtete die ihm zur Übermittlung anvertraute | Telekommunikation netzseitig durch technische Maßnahmen gegen | unbefugte Kenntnisnahme schützt, hat er die von ihm für diese | Telekommunikation angewendeten Schutzvorkehrungen bei der an dem | Übergabepunkt bereitzustellenden Überwachungskopie aufzuheben. […] | If the obligated party [the organization to which these rules apply] | uses technical measures at the network layer to protect submitted | communications against unauthorized disclosure, it shall revert the | protections on these communications for the surveillance copy | provided at the handover interface. U.S. law is similar (47 U.S. Code § 1002 (b) (3), if that citation is correct): | A telecommunications carrier shall not be responsible for | decrypting, or ensuring the government’s ability to decrypt, any | communication encrypted by a subscriber or customer, unless the | encryption was provided by the carrier and the carrier possesses the | information necessary to decrypt the communication. If your ordinary resolver operator is a "carrier" is somewhat questionable, but resolver operators generally comply with requests for cleartext copies of traffic transitioning through their networks. I have no doubts that these operators will ask implementors to add the necessary features to keep these capabilities—or they will just turn on indiscriminate query logging. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] An approach to DNS privacy
* Phillip Hallam-Baker: > For a heavily trafficked resolver, the resolver-authoritative > interaction can be addressed with caching and by pre-fetching the > bulk of the requests. But this approach does not work so well for > the lightly trafficked resolver and especially not a local resolver > deployed in a home network. Does encryption really make a difference there? In most jurisdictions, home networks use recursive resolvers whose operators are required by law to provide cleartext copies to local authorities. Encryption won't change that. If it is about securing broadcast media, just run IPsec between the CPE and the first ISP router with trusted ARP and routing tables. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
* Stephane Bortzmeyer: > On Sat, Mar 08, 2014 at 06:07:48PM +0100, > Florian Weimer wrote > a message of 17 lines which said: > >> > It is. Section 2.2.2 >> >> Can you quote it here? > > 2.2.2. In the authoritative name servers Ahhh, this section heading is wrong, the section is actually discussing resolver. The text doesn't explicitly mention minimization, either. :) >A possible solution would be to minimize the amount of data sent from >the resolver. When a resolver receives the query "What is the >record for www.example.com?", it sends to the root (assuming a cold >resolver, whose cache is empty) the very same question. Sending >"What are the NS records for .com?" would be sufficient (since it >will be the answer from the root anyway). To do so would be >compatible with the current DNS system and therefore could be >deployable, since it is an unilateral change to the resolvers. There are some odd configurations out there where a query for www.foo.bar.example/IN/A returns data, but a query for foo.bar.example/IN/A returns NXDOMAIN. So it is backwards-compatible per specification, but a bit thorny to implement in practice. >[RFC2181] suggests an >algorithm to find the zone cut, so resolvers may try it. Do you refer to explicit NS queries? >Note that DNSSEC-validating resolvers already have access to this >information, since they have to find the zone cut (the DNSKEY record >set is just below, the DS record set just above). But they don't obtain this information in a privacy-enhancing way. >One should note that the behaviour suggested here (minimizing the >amount of data sent in qnames) is NOT forbidden by the [RFC1034] >(section 5.3.3) or [RFC1035] (section 7.2). Sending the full qname >to the authoritative name server is a tradition, not a protocol >requirment. ^ Typo. >Another note is that the answer to the NS query, unlike the referral >sent when the question is a full qname, is in the Answer section, not >in the Authoritative section. It has probably no practical >consequences. Most resolvers do not make NS queries, and some authoritative servers do not return useful data (or any data at all). So using NS queries for zone cut discovery does not work reliably. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
* Stephane Bortzmeyer: > On Sat, Mar 08, 2014 at 05:50:55PM +0100, > Florian Weimer wrote > a message of 22 lines which said: > >> The -sol draft mentions QNAME minimization without defining the >> term. > > It is. Section 2.2.2 Can you quote it here? It seems to be missing from the 00 version, or I'm horribly confused. > I'll add some more cross-references to make it easier to find it. Thanks. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS privacy : now at least two drafts
* Stephane Bortzmeyer: > I just posted a new version of the DNS privacy draft, > draft-bortzmeyer-dnsop-dns-privacy-01. The most important difference > is that it is now split in two, one pure problem statement, > draft-bortzmeyer-dnsop-dns-privacy and an exploration of possible > solutions, draft-bortzmeyer-dnsop-privacy-sol. The first one seems to > me (and to the AD) well adapted to dnsop. The second one mixes > solutions that may be in the realm of dnsop (such as qname > minimization) and solutions that would require a new WG (such as > encryption of DNS traffic). The -sol draft mentions QNAME minimization without defining the term. Is this about sending only as many labels as required to obtain a delegation from an authoritative server? There is another privacy-enhancing approach that is not mentioned in the draft: defensive delegations. For example, with current resolver behavior, the lack of a delegation for 1.E164.ARPA means that queries under that tree are sent to the E164.ARPA servers, which are scattered around the globe. With a delegation, the delegation would be cached and queries could be kept locally in the region. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Data model and field names for DNS in JSON or XML
* Stephane Bortzmeyer: > I'm aware of draft-mohan-dns-query-xml, which partially solves my > problem (except I would like the RDATA to be structured as well, not a > blob of "hexadecimal data"). In this area, draft-levine-dnsextlang-00 might be helpful. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS Server Selection document last call in MIF
* Stephen Morris: > In case you are not following MIF, nor have seen the email Andrew sent > to DNSEXT, there is a last call in MIF of > > http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-03.txt > > ... that may be of interest to people here. Curious. Is there an API proposal somewhere? I can't see how this can be implemented on top of the BSD sockets API, especially not with the weak end system model. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Do negative cache entries have to be consistent ?
* John Levine: > Since the TTL on a negative cache entry comes from the TTL on the SOA > returned with the NXDOMAIN, this means that they'll be returning SOAs > with different TTLs on different responses. This strikes me as > something that's not technically illegal, but that people who write > DNS caches didn't anticipate. Is it likely to break anything? > > Bonus question: with DNSSEC, a cache can use NSEC info to synthesize > NXDOMAIN responses for nearby addresses. Will inconsistent TTLs break > anything then? You can avoid both issues by introducing sub-zones for the network ranges which should receive longer TTLs. In the non-DNSSEC case, you can simply return a SOA record whose owner name is the full QNAME. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Fwd: Last Call: (Special-Use Domain Names) to Proposed Standard
* Joe Abley: > I don't think special-use names are a concept of the DNS in the > protocol sense, but rather a set of administrative conventions. LOCAL. is very much protocol-enshrined, but I think it has been reserved neither by IETF nor IANA. Would any other reserved name share a similar fate? Then you might be right in the sense that the IETF cannot set aside names for use at the protocol level. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] On resolver priming
* Paul Hoffman: > Conservative, yes; operationally prudent, no. This type of thing can > be pre-tested fairly easily. For example, once .net starts signing, > make a private signing of root-servers.net and hand it out to > friends and family and watch for any anomalous results. This is not sufficient because DNSSEC does not prescribe response contents, so different (root) servers (instances) will generate different responses from the same zone data, unless the specification is tightened considerably. In particular, such variation affects response sizes, which used to be a primary concern during the DURZ phase. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] New Version Notification - draft-gudmundsson-dnsext-srv-clarify-01.txt (fwd)
* Alfred: > My apologies for cross-posting, > but this is inherently a cross-wg and cross-area topic: > > The revised draft contains clarifications for DNS service discovery > using SRV RRs and suggests methods to deal with the restrictions > imposed by draft-ietf-tsvwg-iana-ports. It is intended that both > drafts will eventually be published in a coordinated manner. > > > Abstract > >The DNS SRV record has been specified in RFC 2052 and RFC 2782 for >use in dynamic service discovery for a domain. These two RFCs did >not clearly specify an IANA registry for the names of the services >and their underlying protocols. This document clarifies RFC 2782 >regarding the formation and use of the Service Prefix in the owner >name of SRV records, based on the unified IANA registry for "Service >Names and Transport Protocol Port Numbers". Wouldn't it be better to put that effort into a SRV successor which focuses on cryptographic binding and the introduction of (generic, cross-application) transports above TCP/UDP? Right now, we've got many protocols which can run over HTTP(S) and home-grown pseudo-transport layers, and with SRV records, it is not possible to figure out if HTTP is to be used or not. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
* Jim Reid: > So what? If the served zones are signed, it simply doesn't matter if > the address of a name server is spoofed or hijacked. This is only true if the whole DNS tree is signed (and if you don't value query privacy). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
* Roy Arends: > So, a collision (that is nothing more than a collision) is a problem > for NSEC3, but not for RSASHA1? You still need a collision over somewhat structured data. Chosen-prefix collisions (with different prefixes) are likely not *that* far away after that, and those break RSASHA1 completely (in the sense that you can register a crafted org domain name and get an RRSIG from org that fits example.org as well, with private key material known to you). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
* Olaf Kolkman: > 5.3.3. NSEC3 Salt > >The salt with NSEC3 is not used to increase the work required by an >attacker attacking multiple domains, but as a method to enable >creating a new set of hash values if at some point that might be >required. The salt is used as a "roll over". The FQDN RRlabel, >which is part of the value that is hashed, already ensures that brute >force work for one RRlabel can not be re-used to attack other RRlabel >due to their uniquenes. > >Key rollovers limit the amount of time attackers can spend on >attacking a certain key before it is retired. The salt serves the >same purpose for the hashes, which are independant of the key being > > > > Kolkman & GiebenExpires September 8, 2009 [Page 33] > Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 > > >used, and therefor do not change when rolling over a key. Changing >the salt would cause an attacker to lose all precalculated work for >that zone. > >The salt of all NSEC3 records in a zone needs to be the same. Since >changing the salt requires the NSEC3 records to be regenerated, and >thus requires generating new RRSIG's over these NSEC3 records, it is >recommended to only change the salt when changing the Zone Signing >Key, as that process in itself already requires all RRSIG's to be >regenerated. "However, unlike Zone Signing Key changes, NSEC3 salt changes do not need special rollover procedures. It is possible to change the salt each time the zone is updated." (Assuming that this is true, which I think it is.) Perhaps the following is helpful as well? 5.3.5 Response size considerations NSEC3 records are larger than NSEC records because of the embedded hashes. However, NSEC records are sometimes returned in response to DO=0 queries, pushing the response over the 512 byte limit and causing TCP fallback (or worse). This does not happen with NSEC3 records because their owner name does not normally match the queried name. Therefore, NSEC3 records provide better insulation of child zones from the DNSSEC deployment in the parent zone. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Priming query transport selection
* Jim Reid: > On 15 Jan 2010, at 13:20, Florian Weimer wrote: > >> DO is rather pointless because the priming response cannot be >> validated anyway (even if ROOT-SERVERS.NET were secure, which is >> currently not planned). > > It's not pointless. Validating the priming response requires two > operations. The first of these is checking the signature over the root > zone's NS RRset. Which won't be returned unless the DO bit is set. > [Let's avoid the rat-hole of a DNSSEC-aware resolver iteratively > querying for DNSKEYs, RRSIGs and so on.] I'm not sure this narrow perspective is helpful. Given the amount of work required to validate the priming response (which resolvers aren't required to do until they see a client query for ./IN/NS, similar to what happens with all the other NS RRsets), it really doesn't matter if you send a DO=0 query first, to get the addresses (in the additional section), and then a DO=1 query, to get the signature on the NS RRset (in the answer section). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Priming query transport selection
* Jim Reid: > The preferred approach might probably be along these lines: > [1] EDNS0 + DO with a buffer of 5-8K (ish) > [2] TCP + DO when [1] fails > [3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails > [4] EDNS0 (no DO) with a 1.5K (ish) buffer > [5] Vanilla UDP (no EDNS0) if [4] fails DO is rather pointless because the priming response cannot be validated anyway (even if ROOT-SERVERS.NET were secure, which is currently not planned). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Re: Computerworld apparently has changed DNS protocol
* Duane Wessels: > On Wed, 4 Nov 2009, Nicholas Weaver wrote: > >> Also, has someone done a study what the major recursive resolvers do >> on response failures from a root? Do they go to another first or do >> they try a smaller EDNS MTU? > > I gave a presentation on this at the DNS-OARC meeting last week: > > https://www.dns-oarc.net/files/workshop-200911/Duane_Wessels.pdf Have you installed any trust anchors in the resolver? (I don't think so, the packet numbers are a bit on the lower side for that.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Re: Computerworld apparently has changed DNS protocol
* Nicholas Weaver: > Also, has someone done a study what the major recursive resolvers do > on response failures from a root? Do they go to another first or do > they try a smaller EDNS MTU? Note that switching seems beneficial because six roots MTUs clearly support MTUs less than 1500, and seven roots probably don't (from my POV, numbers about a week old). It will be interesting to see if the root ops fix this before or after they've enabled large responses for DO=1. 8-/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Computerworld apparently has changed DNS protocol
* David Blacka: > I actually researched this, and need to spend some time cleaning up > the report before posting it to this list. But the bottom line is > that yes, all responses save a few at the apex of root are below 1500b > (actually, below 1100b). The responses that are larger are ". rrsig" > and ". any" (and ". dnskey" if minimal dnskey responses aren't used). > ". any" is the only one that would actually set TC if, say, the > advertised buffer size were set to 1280. What about a.root-servers.net/IN/A etc.? (Assuming that root-servers.net will be signed eventually.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Computerworld apparently has changed DNS protocol
* Alfred Hönes: > There must be a hidden trick to introduce DNS Jumbograms we just > forgot to mention The claims about firewall issues seems dubious to me. It's certainly not the 512 byte limit which is a problem here---I think we've got pretty good empiric evidence that it's not a problem anymore. Several root responses are already larger than 512 bytes, and you can't send mail to AOL or Yahoo if you're behind a firewall that swallows responses larger than 512 bytes. People tend to fix such things, especially if the Internet is a new thing to them and they want to communicate with each other, instead of merely being right and protocol compliant. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] Re: Computerworld apparently has changed DNS protocol
* Matthew Dempsky: > On Wed, Nov 4, 2009 at 11:26 AM, wrote: >> The current deployment plan is to stage things to push out large >> responses >> early - prior to having any actual DNSSEC usable data ... ostensibly >> to >> flush out DNSmtu problems. > > Is this plan to push out large responses indiscriminately, or only > in response to queries with DO=1? Eh, the protocol requires that those are sent only with DO=1. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00
* Alex Bligh: > Clearly a validating recursive nameserver not supporting > DOMAIN.LOCAL.ARPA may get a signed denial of existence for > LOCAL.ARPA, but that's just fine. LOCAL.ARPA doesn't > exist "there". Great, then we are in agreement actually. >> As I've tried to explain, spoofing by the resolver operator itself is >> the relevant issue here. It breaks the proposed protocol. Please >> tell me how I can explain this in a better way---perhaps I shouldn't >> say "spoofing" but "DNS rewriting", "NXDOMAIN redirection", >> "Sitefinder", "online help page", or something else, but it's really >> spoofing. > > Ah. I think I now understand what you mean. Well yes they can do that, but > they could do it anyway. There's an additional twist: If I have got a client device (not DNS proxy) which supports the proposed protocol, it will not work when I connect it to a network which uses a resolver that performs this type of spoofing, unless the spoofing resolver has specific support for this protocol. It's not "someone could do evil things and make it break", but "someone already does (perhaps evil) things, and it breaks". -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00
* Alex Bligh: > --On 21 October 2009 08:34:39 +0000 Florian Weimer wrote: > >>>> Mark, I din't think this is true given how the proposed protocol >>>> works. For a start, you often cannot fetch the DNSKEY RR for ARPA >>>> before running the protocol. >>> >>> Indeed LOCAL.ARPA would need to be unsigned. >> >> Not really. Why would it need to exist in the public tree at all? >> All we need is agreement from both ICANN and IETF that LOCAL.ARPA is >> reserved and not to be delegated in the official tree. > > OK, let's try this one again. LOCAL.ARPA is not delegated at all. > It is unsigned. If it is not delegated, it will be signed (as Mark pointed out). > Necessarily, ARPA. will have no records for LOCAL.ARPA Then its non-existence will be signed. > Moreover the queries into DOMAIN.LOCAL.ARPA are going to be made > in an environment where we suspect DNSSEC queries don't work, as > there is, ex hypothesi, possible a misbehaving proxy in the way. Right. (Otherwise, you wouldn't use class IN for this stuff.) > So there are two separate security risks: cache poisoning on the > recursive server (this needs addressing and I have some ideas), > and a theoretical Kaminsky style attack on the individual > non-DNSSEC queries to DOMAIN.LOCAL.ARPA. Don't worry too much about spoofing from off-path attackers. ISPs have plenty of means to prevent it (granted, for IPv4 directly over Ethernet, there's no standard way of doing things which conserves address space, but that's a different issue). As I've tried to explain, spoofing by the resolver operator itself is the relevant issue here. It breaks the proposed protocol. Please tell me how I can explain this in a better way---perhaps I shouldn't say "spoofing" but "DNS rewriting", "NXDOMAIN redirection", "Sitefinder", "online help page", or something else, but it's really spoofing. Note that this problem will not go away when you bring LOCAL.ARPA or DOMAIN.LOCAL.ARPA into existence. People say "NXDOMAIN redirection" but they really mean "arbitrary DNS manipulation". It doesn't stop at NODATA response or the second level of the tree. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00
* Ray Bellis: >> Mark, I din't think this is true given how the proposed protocol >> works. For a start, you often cannot fetch the DNSKEY RR for ARPA >> before running the protocol. > > Indeed LOCAL.ARPA would need to be unsigned. Not really. Why would it need to exist in the public tree at all? All we need is agreement from both ICANN and IETF that LOCAL.ARPA is reserved and not to be delegated in the official tree. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00
* Mark Andrews: > For LOCAL.ARPA to be accepted you need a break in the DNSSEC trust > chain. Mark, I din't think this is true given how the proposed protocol works. For a start, you often cannot fetch the DNSKEY RR for ARPA before running the protocol. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00
* Alex Bligh: > Could you amplify a bit on this one? I think what you are saying is > that recursive servers which do not support DOMAIN.LOCAL.ARPA > (and hence don't strip it out of any response to a recursive > query) can be subject to poisoning attacks which will result in > duff nameserver records being sent to clients that are aware > of the protocol. I was alluding to this: ; <<>> DiG 9.5.1-P3 <<>> @208.67.222.222 DOMAIN.LOCAL.ARPA ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44816 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;DOMAIN.LOCAL.ARPA. IN A ;; ANSWER SECTION: DOMAIN.LOCAL.ARPA. 0 IN A 67.215.65.132 ;; Query time: 41 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Tue Oct 20 13:12:32 2009 ;; MSG SIZE rcvd: 51 And 67.215.65.132 does not offer DNS service. > I think that is indeed a security concern, and perhaps not > one that can be brushed aside with the response "but such > servers can have any DNS query made to them poisoned anyway". ARPA will soon be signed, so I don't think this is much to worry about. If the powers that be finally agree to make NXDOMAIN/NODATA synthesis the default in the upcoming minor DNSSEC revision, this will also help to cut down the number of requests. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00
* Ray Bellis: > I've just submitted the following draft. This will work for a short time only because those proxies will likely be changed to return their own address for DOMAIN.LOCAL.ARPA. You cannot rely on a NXDOMAIN response for DOMAIN.LOCAL.ARPA when the resolver does not support this protocol due to widespread DNS poisoning. I wholeheartedly support the creation of LOCAL.ARPA, though. But you should mention that mDNS MUST NOT be used for LOCAL.ARPA (so that some people don't get funny ideas). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Key Management and Provisioningl was Re: .PR ...
* Roy Arends: > On Oct 7, 2009, at 8:57 AM, Florian Weimer wrote: > >> * Roy Arends: >> >>> At least for Nominet, I want (2) to do cross-checking, be able to >>> check what things look like before they enter the pipeline, >>> preferably >>> using the same channel as (1). Before I push the 'publish' button, I >>> want to check it in private. After I push the publish button, its in >>> the root, and world can check it with me, using dig. >> >> Have you already got this self-service capability for non-DS changes? > > > Yes. > Why do you ask? It's not mentioned in the procedure described at <http://www.iana.org/procedures/nameserver-change-procedures.html> as far as I can tell. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Key Management and Provisioningl was Re: .PR ...
* Roy Arends: > At least for Nominet, I want (2) to do cross-checking, be able to > check what things look like before they enter the pipeline, preferably > using the same channel as (1). Before I push the 'publish' button, I > want to check it in private. After I push the publish button, its in > the root, and world can check it with me, using dig. Have you already got this self-service capability for non-DS changes? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Trust History draft
* W. C. A. Wijngaards: > Hi, > > Just new in the dnsop wg tools page: > http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 I don't understand this part: | DNSSEC [RFC4034] validators that have been offline or have missed an | (emergency) rollover can use trust history service to get back on | track. The trust history location is assumed available from the | validator configuration. The validator then fetches old DNSKEY | RRsets and checks they form a chain to the latest key. Doesn't this defeat the purpose of key rollovers? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] measuring TCP query performance
* Paul Vixie: > since time is short, i would prefer a server-side change, supported by a > spec change (which means this would head back to namedroppers@) whereby > (bufsize<1220 && DO=1) would be treated as (DO=0). And what does the resolver with a trust anchor do with the DO=0 answer? Requery immediately because it assumes there's an attack? If you want to punish those non-compliant resolvers, you must not answer at all, hoping that the resolver timeout will calm things down. Obviously, you should play such tricks only on a separate set of root server addresses/names. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] how DNS redirect works with empty response
* JINMEI Tatuya / 神明達哉: > What does a recursive server that implements the DNS redirect service > do in this case? Empty responses are typically rewritten. "NXDOMAIN redirect" is a misnomer. > then I guess authoritative server implementors who don't like > NXDOMAIN redirect could introduce a "auto-site-finder" option, > defaulting to yes, which automatically adds a wildcard name (of some > meaningless RR type) at the apex of each authoritative zone:-) I don't think this trick will work. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Tony Finch: > On Thu, 16 Jul 2009, Florian Weimer wrote: >> >> If you want to address the issue with hotspot doorway pages, you need >> protocol changes. > > Better to use an intercepting proxy in that case, and for quarantining > infected hosts. Doesn't work if the user uses the employer's filtering proxy for web access. > Protocol changes aren't sufficient because if you just extend DNS > without adding restrictions then cunning people can obtain connectivity > via your resolver. This would have to be part of DHCP, I think. DNS s too late. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Jason Livingood: > Actual consumer behavior doesn¹t really seem to work that > way, but I¹m not a behavioral psychologist. ;-) FWIW, I think most > ISPs that introduce such services see around a 0.1% opt-out rate. I would expect a higher rate of Dnschange/Zlob infections at a typical U.S. ISP. IOW, the 0.1% number doesn't seem to include users who just use some external DNS service. Anyway, for many users, the browser interface really doesn't change much. That's why it's hard for me to believe that this is done to improve user experience. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Tony Finch: > On Thu, 16 Jul 2009, Florian Weimer wrote: >> >> (But I agree that a clean solution requires protocol development.) > > No, it just requires browser user interface improvements. If you want to address the issue with hotspot doorway pages, you need protocol changes. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Paul Hoffman: > Paul: that's over the top. Some of the services defined in the draft > are highly desired by some Internet users. Which ones? Currently, when a user enters "mcrsoft" in the address bar, many browsers will automatically send her to the Microsoft homepage. With spoofed answers, he reaches some intermediate page instead, which may or may not be helpful. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Alan Barrett: > I think that this sort of lying recursive resolver is a bad idea. > Instead, I suggest a new "SUGGESTION" RR type that could be returned > in the additional section of an error message. For example, if > you ask for www.example.invalid, you could get back an NXDOMAIN > error, with "SUGGESTION URL=http://10.2.3.4/www.example.invalid"; > in the additional section, and if you ask for censored.example. > you could get back a SERVFAIL response with "SUGGESTION > URL=http://10.2.3.4/why-we-censor.html"; in the additional section. This would be protocol development, so it's out of the scope of this WG. There's also the problem that some folks want to do DNS rewriting *now*. If client-side changes are required, they fear that they will out of business before they are implemented. (But I agree that a clean solution requires protocol development.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Jelte Jansen: > Ralf Weber wrote: >>> No redirection on SERVFAIL seems to be a strange recommendation. >>> Wouldn't this be a very good reason to provide a diagnostics page, >>> especially if there's been a DNSSEC validation failure? >> This sounds like an excellent idea to help DNSSEC adoption and >> is something that should go into the draft. >> > > then a SERVFAIL will also result in an e-mail bounce that says > connection refused Not a hard 5xx error? > instead of DNS error (assuming there's no e-mail > sink on the host that is redirected to). Fun times for the helpdesk. Only if the mail server falls back to the A record if the MX lookup results in SERVFAIL, which seems like a questionable approach to me. Anyway, I think DNS rewriting is mainly for folks who also block 25/TCP in- and outgoing or list the address space on the PBL and similar DNSBLs, so the SMTP argument is not really valid anymore. > Also, I don't see how the ISP trust anchor for DNSSEC would work (not > knowing the actual zone that it is supposed to cover in advance); it > might be a better idea to simply disable all redirects on DO==1. You can't use trust anchors to guide rewriting. You need to look at the zone contents to see what can be done. With NSEC3 opt-out, there's still lots of wiggle room (at least initially). Generally not spoofing on DO==1 is easier, of course. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Ralf Weber: > That really is an issue and could be addressed, there are a lot of > case where a A record for a domain doesn't exists, but one for > www.domain does exist. True, and some browser have code to deal with this. > Question then would be how that rewrite should be presented. As a > normal A answer or as CNAME referral which might be better as the > underlying web server might not answer for the domain without www. You can't create a CNAME alias to subdomain. And CNAMEs are not type-specific, so this would obscure SOA/NS/etc. at the zone apex. > That is not the intention and not what I read there. Diversion of > powers is a concept that is not even common among "western > democracies". The text tries to stay away from these political > issues, and instead makes clear that the local law, goverenment or > jurisdictions should be honored where appropriate. Can't you omit this stuff altogether? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Jason Livingood: > If anyone is interested and has time before IETF 75, I¹m happy to take > feedback before then obviously. Few players perform NXDOMAIN rewriting. Instead, ANCOUNT=0 rewriting is used. This causes all kinds of problems, including redirections for example.com when it hasn't got an A record (where some browser would just fall back to www.example.com), and bad interactions with IPv6 deployment (because all IPv6-only hosts suddenly have got an A record). The malicious site protection does not work reliably because it can be easily bypassed by the attacker, using IP addresses. Section 5.3 is pretty explicit in that government-mandated filtering decisions should be made by executive organs, and not the judiciary. The IETF should not try to regulate this and should certainly show more respect for separation of powers. It should mention that DNS-based filtering is not acceptable to many governments because it can be bypassed easily, and it is not possible to block content on popular sites where the collateral damage of a domain-wide block would be problematic. Section 7.1 should be more strongly worded. Rewriting stuff like search.msn.com (and reverse-proxying the HTTP traffic) must not be condoned by a RFC. Such things are just evil. No redirection on SERVFAIL seems to be a strange recommendation. Wouldn't this be a very good reason to provide a diagnostics page, especially if there's been a DNSSEC validation failure? As it stands, the product list in Section 8.3 serves no particular purpose. Some analysis which browser-based mechanisms are broken by DNS redirection might be helpful, but this could be done in a product-independet manner. Section 8.4 should mention that some (most?) rewriters do not rewrite subtrees which involve a delegation from the TLD level. This addresses a huge range of technical issues. DNSSEC interoperability doesn't work the way you expect because once the resolver is security-aware, it will set the DO bit queries, and you cant tell the non-validating resolvers from the validating ones. It's also not an all-or-nothing thing because validation depends on availability of trust anchors. So you'd have to spoof your answer according what's permitted by the signed data (particularly the NSEC(3) records; you don't have to validate the signatures yourself). The draft must mention DNSBL interactions (and, more generally, the impact on applications which use DNS as a transport for RPC). It should describe approaches how to mitigate issues identified (such as the IPv6 problem), and show the impact in terms of increased query count. There's also a policy impact for ICANN. Restricted TLDs such as .tel are not feasible if DNS rewriting essentially removes restriction on TLD contents. This also applies to e164.arpa subtrees, where some national regulators have requested that their subtrees can only be used for ENUM (and not arbitrary DNS information). While I'm mostly with Stephane regarding the merits of DNS rewriting, I think the IETF could still publish a draft on this topic. However, it should present pretty stringent requirements which ensure that rewriting does not adversely impact operations. The current draft is closer to a fig leaf, I'm afraid. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-livingood-dns-redirect-00
* Stephane Bortzmeyer: > Unless I'm wrong, the I-D about lying resolvers do not discuss the > issue of zone cuts. > > If I type www.doesnotexistatall.com (the SLD does not exist and so I > should get a NXDOMAIN), I get the IP address of the ad Web server. If > I type .afnic.fr, I will get this IP address as well, since the > QNAME does not exist (four 'w' instead of three) despite the fact that > the SLD does exist. This also interacts very badly the subdomain-based web trust model, so it should be mentioned in the Security Considerations section. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Problems with DS change in registry/registrar environment
* Patrik Fältström: > We have a problem when "a domain changes hands" and the private DS key > in some way is changed, should be changed, and sometimes is not > changed as it should. We all agree that could lead to a blackout, but > in many cases the blackout is not more serious than a normal blackout > when NS is changed. Just as a general point, not really addressing any specific concern: DNSSEC has *more* data to work with, so it is *easier* for a resolver to detect a zone transition and properly handle it. If you write a resolver in a way which *extends* downtime, instead of reducing it, you really aren't doing your job well. Now there's the slight architectural complication that validation is typically tacked onto the cache, without properly integrating it. Obviously, it's a real pain to get the right bad data out of the cache once you detect the problem in the validator. If your resolver suffers from this, it points out a major design issue. Resolver operators and implementors should deal with this, and not everyone else. I've been arguing for a while that this setup can't work reliable, is undesirable for various reasons (including reliance on channel security, which we want to get rid of by introducing DNSSEC!), and should be deprecated. This also applies to configurations were a resolver forwards to another one which has fewer trust anchors. Zone operators and domain owners can't predict resolver behavior because the RFCs do not tightly specify it. There is very likely no way to make zone changes in a way that pleases all resolvers. So most operators don't even try to do it. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC4641bis Section 4.4.5 proposed new text
* Antoin Verschuren: >There are multiple reasons why a registrant may want to change it's "its"? "their?" >changed so such rollover scenario will not work. Besides if zone >transfers are not allowed by the losing DNS operator and NSEC3 is >deployed in the zone then the gaining DNS operator will not have >certainty that all of the losing operator's RRSIGs are transferred. But you need that data anyway, to continue providing the content of the zone. So you can also provide for RRSIGs. But as you pointed, it's not going to help because the signature on the NS RRset has to change. >The second option is to sign the zone at the gaining DNS operator with >the existing keys from the losing DNS operator. This option is purely >theoretical, and should not be used in an operational environment since >it implies exposing the private keying material when it is handed over >from the losing to the gaining DNS operator. In practice, when using >Hardware Signing Machines (HSM's) it is not even possible to extract "Hardware Security Modules (HSMs)" (see the previous discussion). Moreover, the same key could be used for multiple zones, for different customers. >All three options require the losing DNS operator to cooperate in the >transfer process to some extend for the domain to work. This is because >with DNSSEC only one version of the truth can be validated by one single >trust anchor, where in the non DNSSEC world 2 or even more versions of >the truth are accepted by a non DNSSEC resolver. The mandating of the >cooperation by the losing DNS operator can either be handled by the >parent of the zone in registration policy, or in a bilateral contract >between the registrant and the DNS operator when the registrant >outsources it's DNS operations for his zone. I think it's been proposed to lock NS/DS records in the resolver to address this problem. Other resolver-side mitigation mechanisms are a side effect of dealing with the unsigned referral/glue issue. After all, if you've never validated the NS RRset and its addresses, a registrar switch is indistinguishable from a previously unnoticed attack based on a spoofed referral. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-rfc4641bis-01.txt
* Edward Lewis: > This comes from the observation that the contents of the database > sourcing the zone (whether a commercial-like database or a vi'd file) > are more critical than the private key. (If) They are sufficiently > protected and I'll just keep the private key behind the same > fortifications. So, what does an HSM add? I think the general idea is that if you have to edit your zone because it was tampered with, chances are that nobody will notice (or everybody will attribute it to routine maintenance). If your key is compromised and you have to replace it out of schedule, you might have got some explaining to do. 8-) Of course, this isn't a strong argument in favor of HSMs. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] "MX 0 ." standard way of saying "we don't do email" ?
* Paul Vixie: >> > As for "MX 0 ." the sooner this gets defined as no SMTP service for this >> > domain the better. The cost for changing this is only every going to >> > increase. >> >> It may take years before a significant portion of SMTP servers recognize >> root domains as meaning no service. > > that would never happen. most smtp initiators including embedded ones would > never be upgraded. they'll just make ". IN A" queries trying to chase down > this MX's target. Most embedded SMTP implementations do not perform mail routing. Those who do have got an automated software update mechanism, thanks to spam/AV filtering. "MX 0 ." is quite widely deployed as far as the DNS is concerned, so you root operators should already get the related A/ traffic. Theoretically, it shouldn't increase if there are more such MX records because of the two-stage nature of the lookup. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] "MX 0 ." standard way of saying "we don't do email" ?
> The MX RR will be ignored. There will be an DNS request and a > fallback to the A RR for security.eu.debian.org. Newer versions of > sendmail and Postfix will treat that MX RR as a bad MX and reject the > message instead of retrying. Exim also treats the record as a "no SMTP service here" indication. I would even go so far to call this a de-facto standard (which just hasn't been documented by the IETF). (BTW, your user agent mangled Ondřej's name.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
