Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On Wed, Mar 02, 2016 at 10:10:09AM +0100, Shane Kerr wrote a message of 29 lines which said: > I can see that implementors such as yourself like won't bother with > a special-cased version, and that adding code to restrict this > technique to the root only is likely to be MORE WORK. I know at least one case of an implemented option which is to the root only when it could be more general: https://doc.powerdns.com/md/recursor/settings/#root-nx-trust So, not all implementers think the same. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On Wed, Mar 2, 2016 at 9:10 AM, Shane Kerr wrote: > Evan, > > I think that moving Fujiwara's fuller proposal forward will likely take > an extra year and don't see any conflict with the cheese shop approach > really. However since the cheese shop won't likely result in any > running code, I also agree with the suggestion to focus on the general > case. > > Why? Everything we need is in the current draft, if anything there is only cutting of text to do. I think the indicator Flag that I (and others) proposed is a bad idea and should either removed or put in the OPT record If we keep it simple then the world will look like this: - resolver MAY apply ANC when it suits them, CD bit is ignored for caching when ANC is in use - Auth operators MUST assume they have no control over if resolvers use ANC and are limited to pleading for help when under attack. In this world we are no worse off than today. Large Auth server operators can only hope that the big resolver farms like Google, OpenDNS, Verisign, Level3, and do ANC. For the record the local-root-zone operation does exactly what the Cheese shop wants to do just requires two processes in some cases. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On Wed, Mar 2, 2016 at 6:49 AM, Evan Hunt wrote: > On Wed, Mar 02, 2016 at 08:06:39AM +1100, Mark Andrews wrote: > > ANC does not work for zones using OPTOUT. This is just about all > > TLDs and similar zones. > > To be pedantic, it doesn't work for optout ranges. I don't actually know > offhand of any zones that mix optout and non-optout, though, so it's a > fairly pointless quibble. > > > > That then leaves leaf zones. Here sites will not want ANC for their > > own zones internally. Externally there is only real benefit if you > > are under a random prefix DoS attack. > > Random prefix DoS attacks are prevalent enough nowadays to make > this seem like a rather significant exception. > +1 > > The downsides should be manageable. We can implement ANC so that it's > separately enabled or disabled for different namespaces, and put a TTL > cap on NSEC/NSEC3 records in zones that have ANC enabled. > I personally think we should start up a conversation on good practices for TTL's based on the fact we have reliable, fast, dynamic Internet. > > I agree with the suggestion upthread that we address the general case > instead of the root-only solution. > > We agree Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
Evan, At 2016-03-02 06:49:43 + Evan Hunt wrote: > I agree with the suggestion upthread that we address the general case > instead of the root-only solution. I can see that implementors such as yourself like won't bother with a special-cased version, and that adding code to restrict this technique to the root only is likely to be MORE WORK. (Although realistically there will probably need to be domain whitelisting & blacklisting in the resolvers in any case, because in DNS nothing works and everything is horrible and how does this stuff work at all?) I think that moving Fujiwara's fuller proposal forward will likely take an extra year and don't see any conflict with the cheese shop approach really. However since the cheese shop won't likely result in any running code, I also agree with the suggestion to focus on the general case. Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On Wed, Mar 02, 2016 at 08:06:39AM +1100, Mark Andrews wrote: > ANC does not work for zones using OPTOUT. This is just about all > TLDs and similar zones. To be pedantic, it doesn't work for optout ranges. I don't actually know offhand of any zones that mix optout and non-optout, though, so it's a fairly pointless quibble. > That then leaves leaf zones. Here sites will not want ANC for their > own zones internally. Externally there is only real benefit if you > are under a random prefix DoS attack. Random prefix DoS attacks are prevalent enough nowadays to make this seem like a rather significant exception. The downsides should be manageable. We can implement ANC so that it's separately enabled or disabled for different namespaces, and put a TTL cap on NSEC/NSEC3 records in zones that have ANC enabled. I agree with the suggestion upthread that we address the general case instead of the root-only solution. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
In message <56d5b830.80...@bellis.me.uk>, Ray Bellis writes: > > > On 01/03/2016 15:26, =D3lafur Gu=F0mundsson wrote: > > > Thus I consider your document a distraction, we should push the general > > solution not a special case > > +1 > > Ray ANC can be both good and bad depending upon where it is used in the DNS. For the root zone and DLV there is no downside to using ANC for those zones but the benefits of using ANC will decrease as the root zone increases in size (the ANC hit ratio will drop). ANC does not work for zones using OPTOUT. This is just about all TLDs and similar zones. For in-addr.arpa and ip6.arpa it may actually have strong negative consequences and you can't bring up a machine and have it be useful for certain classes of work until the NSEC* records have cleared the cache. Think bring up a replacement SMTP server. That then leaves leaf zones. Here sites will not want ANC for their own zones internally. Externally there is only real benefit if you are under a random prefix DoS attack. I actually don't see much benefit in deploying this generally. Mark > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On 01/03/2016 15:26, Ólafur Guðmundsson wrote: > Thus I consider your document a distraction, we should push the general > solution not a special case +1 Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On Mon, Feb 29, 2016 at 4:03 PM, Warren Kumari wrote: > > > On Mon, Feb 29, 2016 at 10:04 AM Shane Kerr > wrote: > >> Ed, >> >> At 2016-02-29 14:34:39 + >> Edward Lewis wrote: >> > I don't think I was clear - this is only about the DNS protocol. This >> > document proposes that the DNS protocol behave differently depending on >> > the data being carried (QNAME) in it's own messages. >> >> [...] >> >> > This isn't about processing different values differently, this is about >> > changing the behavior of the protocol based on environmental factors. >> > Ah. So you don't like identifying magic zones (other than in-addr.arpa, >> ip6.arpa, .example, .local, ...). Fair enough. >> >> But AIUI, the proposal is an observation that Fujiwara's >> NXDOMAIN-from-NSEC proposal can be implemented safely today for the root >> zone, so we may as well go ahead and do that while considering wider >> usage. >> > > > Yup. I believe we should still pursue Fujiwara's document, but that is > likely to take a significant time, and there are hurdles to overcome. This > document limits things to a subset where we know things work correctly (and > seem OK within 4035) - once we have demonstrated that things work OK here, > it paves the way for more aggressive NSEC. > > Warren, Can you list the issues you think need addressing in Fujiwara's document other than saying that zones signed with "Opt-out" there will be gaps where the technique can be applied, but gaps with opt-out bit set can not be protected. Thus I consider your document a distraction, we should push the general solution not a special case Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
>> It seems to me that deploying code under the assumption of only limited >> caching of negative results is a good way to block all kinds of future >> work, or alternatively, you may be in for a lot of pain if other people >> decide that negative caching is more important. > >ANC was deliberatedly decided against when DNSSEC was being developed >to avoid all of these issues. DNSSEC secured the DNS, it did not >change the semantics of the lookups. ANC changes the semantics of >the DNS. So, if there is good enough motivation for ANC, then maybe NSEC could have been invented independently. >> For example, if you are about to add foo.example.com and you want to find >> the zone cut, then looking up $DOES_NOT_EXIST.example.com will give you >> the zone cut without revealing anything about 'foo'. > >No it doesn't. The zone cut may be foo.example.com. You can't >avoid making a query for foo.example.com. Looking for >$DOES_NOT_EXIST.example.com does not tell you which zone contains >foo.example.com. In the unlikely event you want to update information at an apex, instead inserting names that are not supposed to exists at all, and you are also not aware you are inserting at apex, you can also use $DOES_NOT_EXIST.foo.example.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
Having done this myself, I think there are several situations in which it is common to look up a name shortly before adding it to a zone. e.g. you expect a name to exist, whoops, fix the omission, then have to wait a TTL. Or you are trying to come up with a domain name that hasn't already been registered and you forget to send the query to the TLD servers instead of the local cache. If these is the worst problems that ANC causes, I think we agree they're not all that bad. Can be quite annoying if the TTL is long. Even so, I like aggressive negative cacheing. Same here. It solves real problems for things like IPv6 rDNS lookups. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
In message , Tony Finch writes: > Mark Andrews wrote: > > In message <20160229225356.56583.qm...@ary.lan>, "John Levine" writes: > > > > > > >You could apply the technique to any signed zone where you are not > > > >worried about not having instant visibility after adding a new name > > > >to the zone. > > > > > > I don't understand this. If I ask for foo.example and get NXDOMAIN, > > > and 10 ms later you add a record at foo.example, my negative answer is > > > cached for your SOA TTL is. > > > > For 99.9% of names you don't look them up unless you have > > a priori knowledge that the name exist. > > Having done this myself, I think there are several situations in which it > is common to look up a name shortly before adding it to a zone. e.g. you > expect a name to exist, whoops, fix the omission, then have to wait a TTL. > Or you are trying to come up with a domain name that hasn't already been > registered and you forget to send the query to the TLD servers instead of > the local cache. Accidents vs doing it every time you add a new machine / service is very different proposition. > Can be quite annoying if the TTL is long. Even so, I like aggressive > negative cacheing. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Forties, Cromarty, Forth, Tyne, Dogger, Fisher, German Bight, Humber: South, > veering west, 6 to gale 8, occasionally severe gale 9 in Forties and Fisher, > decreasing 4 or 5 for a time. Moderate or rough, occasionally very rough. > Occasional rain or snow, fog patches. Moderate or poor, occasionally very > poor. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
In message , Philip Homburg writes: > >Yes, ANC breaks using the DNS for Internet reachability testing. > > > >Named has code to return zero TTLs on negative answers to SOA queries > >to avoid polluting caches with NXDOMAIN results when searching for > >zone cuts. Nsupdate and similar tools need to be able to find the > >containing zone of names that are about to be added and cached > >NXDOMAIN responses are a right-royal-pain-in-the-butt if you want > >to lookup the name just after you have added it to the DNS. > > Did you ever consider making this work assuming more aggressive negative > caching? It requires caches to not do ANC for SOA lookups or for there to be a explict option to not do ANC. Searching for containing zone is just a real life example of the impact of getting a NXDOMAIN when you don't want it as a side effect of something else. > It seems to me that deploying code under the assumption of only limited > caching of negative results is a good way to block all kinds of future > work, or alternatively, you may be in for a lot of pain if other people > decide that negative caching is more important. ANC was deliberatedly decided against when DNSSEC was being developed to avoid all of these issues. DNSSEC secured the DNS, it did not change the semantics of the lookups. ANC changes the semantics of the DNS. > For example, if you are about to add foo.example.com and you want to find > the zone cut, then looking up $DOES_NOT_EXIST.example.com will give you > the zone cut without revealing anything about 'foo'. No it doesn't. The zone cut may be foo.example.com. You can't avoid making a query for foo.example.com. Looking for $DOES_NOT_EXIST.example.com does not tell you which zone contains foo.example.com. > If you want to test something, create a zone that is designed to be tested, > for example, one with low ttls everywhere. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
Mark Andrews wrote: > In message <20160229225356.56583.qm...@ary.lan>, "John Levine" writes: > > > > >You could apply the technique to any signed zone where you are not > > >worried about not having instant visibility after adding a new name > > >to the zone. > > > > I don't understand this. If I ask for foo.example and get NXDOMAIN, > > and 10 ms later you add a record at foo.example, my negative answer is > > cached for your SOA TTL is. > > For 99.9% of names you don't look them up unless you have > a priori knowledge that the name exist. Having done this myself, I think there are several situations in which it is common to look up a name shortly before adding it to a zone. e.g. you expect a name to exist, whoops, fix the omission, then have to wait a TTL. Or you are trying to come up with a domain name that hasn't already been registered and you forget to send the query to the TLD servers instead of the local cache. Can be quite annoying if the TTL is long. Even so, I like aggressive negative cacheing. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger, Fisher, German Bight, Humber: South, veering west, 6 to gale 8, occasionally severe gale 9 in Forties and Fisher, decreasing 4 or 5 for a time. Moderate or rough, occasionally very rough. Occasional rain or snow, fog patches. Moderate or poor, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
>Yes, ANC breaks using the DNS for Internet reachability testing. > >Named has code to return zero TTLs on negative answers to SOA queries >to avoid polluting caches with NXDOMAIN results when searching for >zone cuts. Nsupdate and similar tools need to be able to find the >containing zone of names that are about to be added and cached >NXDOMAIN responses are a right-royal-pain-in-the-butt if you want >to lookup the name just after you have added it to the DNS. Did you ever consider making this work assuming more aggressive negative caching? It seems to me that deploying code under the assumption of only limited caching of negative results is a good way to block all kinds of future work, or alternatively, you may be in for a lot of pain if other people decide that negative caching is more important. For example, if you are about to add foo.example.com and you want to find the zone cut, then looking up $DOES_NOT_EXIST.example.com will give you the zone cut without revealing anything about 'foo'. If you want to test something, create a zone that is designed to be tested, for example, one with low ttls everywhere. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
In message <5d514d0f-cafd-405c-821c-c2cf3b7fa...@verisign.com>, "Wessels, Duane" writes: > > > On Feb 29, 2016, at 3:36 PM, Mark Andrews wrote: > > > > > > In message <20160229225356.56583.qm...@ary.lan>, "John Levine" writes: > >>> You could apply the technique to any signed zone where you are not > >>> worried about not having instant visibility after adding a new name > >>> to the zone. > >> > >> I don't understand this. If I ask for foo.example and get NXDOMAIN, > >> and 10 ms later you add a record at foo.example, my negative answer is > >> cached for your SOA TTL is. Using NSEC to synthesize responses > >> doesn't fundamentally change the situation, it just increases the set > >> of names that negative cache entries will cover and maybe changes the > >> time if the NSEC and SOA TTLs are different. Unless all of your TTLs > >> are zero, there's no such thing as a new name that's instantly visible > >> to every client. > > > > For 99.9% of names you don't look them up unless you have > > a priori knowledge that the name exist. This means you don't have > > many NXDOMAIN records in a cache sans DoS attacks, prefixes to known > > names (e.g. TLSA for service) and Internet reachability tests using > > the DNS etc. Even with search lists you are looking for a known > > name with a set of suffixes. You are not looking for unknown names. > > [CITATION NEEDED] Please? > > Actual data seems to tell a different story: > > $ sudo tcpdump -n -i eth0 -c 10 dst host a.root-servers.net and src host > 74.125.74.4 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 00:14:53.448321 IP 74.125.74.4.36867 > 198.41.0.4.domain: 53200 [1au] A? > u2t11ngt0b-7j.unarubxvgjclkbxmgmfim.tv.adelina.local. (81) > 00:14:53.609935 IP 74.125.74.4.60074 > 198.41.0.4.domain: 47352 [1au] A? > cid:4104657c5b1627c4161ccc7fcb012308.box. (69) > 00:14:53.767055 IP 74.125.74.4.64713 > 198.41.0.4.domain: 30524 [1au] > ? eait3235vr0vk.clients3.google.com.gp3.s86.loc. (74) > 00:14:53.953686 IP 74.125.74.4.49501 > 198.41.0.4.domain: 8537 [1au] SRV? > _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.teh-system.local. (97) > 00:14:54.095375 IP 74.125.74.4.49952 > 198.41.0.4.domain: 35033 [1au] > ? g2xkqe1z1kj1h.ups.virool.com.gbiad. (63) > 00:14:54.096339 IP 74.125.74.4.59901 > 198.41.0.4.domain: 6762 [1au] A? > HH.gkab.loc. (40) > 00:14:54.143732 IP 74.125.74.4.49996 > 198.41.0.4.domain: 42468 A? > q2jv2af4g-jzh.dns1.be.weather.com. (51) > 00:14:54.231436 IP 74.125.74.4.42995 > 198.41.0.4.domain: 52187 [1au] > ? oobca2949e5mc.bd.unba.lan. (54) > 00:14:54.238082 IP 74.125.74.4.54627 > 198.41.0.4.domain: 47410 A? > byz-372osga4d.dns3.be.weather.com. (51) > 00:14:54.321907 IP 74.125.74.4.64277 > 198.41.0.4.domain: 62335 [1au] > SRV? neesb94pfizrq._ldap._tcp.us179._sites.dc._msdcs.gvsucentr.corp. (91) I see nothing there that disproves my statement. There are lots of leaked names but nothing that says that the lookup wasn't based on a known name. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
> On Feb 29, 2016, at 3:36 PM, Mark Andrews wrote: > > > In message <20160229225356.56583.qm...@ary.lan>, "John Levine" writes: >>> You could apply the technique to any signed zone where you are not >>> worried about not having instant visibility after adding a new name >>> to the zone. >> >> I don't understand this. If I ask for foo.example and get NXDOMAIN, >> and 10 ms later you add a record at foo.example, my negative answer is >> cached for your SOA TTL is. Using NSEC to synthesize responses >> doesn't fundamentally change the situation, it just increases the set >> of names that negative cache entries will cover and maybe changes the >> time if the NSEC and SOA TTLs are different. Unless all of your TTLs >> are zero, there's no such thing as a new name that's instantly visible >> to every client. > > For 99.9% of names you don't look them up unless you have > a priori knowledge that the name exist. This means you don't have > many NXDOMAIN records in a cache sans DoS attacks, prefixes to known > names (e.g. TLSA for service) and Internet reachability tests using > the DNS etc. Even with search lists you are looking for a known > name with a set of suffixes. You are not looking for unknown names. [CITATION NEEDED] Please? Actual data seems to tell a different story: $ sudo tcpdump -n -i eth0 -c 10 dst host a.root-servers.net and src host 74.125.74.4 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 00:14:53.448321 IP 74.125.74.4.36867 > 198.41.0.4.domain: 53200 [1au] A? u2t11ngt0b-7j.unarubxvgjclkbxmgmfim.tv.adelina.local. (81) 00:14:53.609935 IP 74.125.74.4.60074 > 198.41.0.4.domain: 47352 [1au] A? cid:4104657c5b1627c4161ccc7fcb012308.box. (69) 00:14:53.767055 IP 74.125.74.4.64713 > 198.41.0.4.domain: 30524 [1au] ? eait3235vr0vk.clients3.google.com.gp3.s86.loc. (74) 00:14:53.953686 IP 74.125.74.4.49501 > 198.41.0.4.domain: 8537 [1au] SRV? _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.teh-system.local. (97) 00:14:54.095375 IP 74.125.74.4.49952 > 198.41.0.4.domain: 35033 [1au] ? g2xkqe1z1kj1h.ups.virool.com.gbiad. (63) 00:14:54.096339 IP 74.125.74.4.59901 > 198.41.0.4.domain: 6762 [1au] A? HH.gkab.loc. (40) 00:14:54.143732 IP 74.125.74.4.49996 > 198.41.0.4.domain: 42468 A? q2jv2af4g-jzh.dns1.be.weather.com. (51) 00:14:54.231436 IP 74.125.74.4.42995 > 198.41.0.4.domain: 52187 [1au] ? oobca2949e5mc.bd.unba.lan. (54) 00:14:54.238082 IP 74.125.74.4.54627 > 198.41.0.4.domain: 47410 A? byz-372osga4d.dns3.be.weather.com. (51) 00:14:54.321907 IP 74.125.74.4.64277 > 198.41.0.4.domain: 62335 [1au] SRV? neesb94pfizrq._ldap._tcp.us179._sites.dc._msdcs.gvsucentr.corp. (91) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
In message <20160229225356.56583.qm...@ary.lan>, "John Levine" writes: > >You could apply the technique to any signed zone where you are not > >worried about not having instant visibility after adding a new name > >to the zone. > > I don't understand this. If I ask for foo.example and get NXDOMAIN, > and 10 ms later you add a record at foo.example, my negative answer is > cached for your SOA TTL is. Using NSEC to synthesize responses > doesn't fundamentally change the situation, it just increases the set > of names that negative cache entries will cover and maybe changes the > time if the NSEC and SOA TTLs are different. Unless all of your TTLs > are zero, there's no such thing as a new name that's instantly visible > to every client. For 99.9% of names you don't look them up unless you have a priori knowledge that the name exist. This means you don't have many NXDOMAIN records in a cache sans DoS attacks, prefixes to known names (e.g. TLSA for service) and Internet reachability tests using the DNS etc. Even with search lists you are looking for a known name with a set of suffixes. You are not looking for unknown names. ANC changes that. It effectively adds lots of NXDOMAIN records for stuff you don't have a priori knowledge of, for unknown names. Yes, ANC breaks using the DNS for Internet reachability testing. Named has code to return zero TTLs on negative answers to SOA queries to avoid polluting caches with NXDOMAIN results when searching for zone cuts. Nsupdate and similar tools need to be able to find the containing zone of names that are about to be added and cached NXDOMAIN responses are a right-royal-pain-in-the-butt if you want to lookup the name just after you have added it to the DNS. SOA and NS are the only two types that should exist in every zone and looking these up works even when the authoritative servers don't support negative caching. For UPDATE you need to do both SOA and NS lookups to work out where to send the UPDATE message to. You start with the name to be added/removed and query for a SOA record at that name, you keep stripping the left hand label until you get a positive answer or a negative answer with a SOA record. You then make a NS query for the owner of the SOA record. For completeness you could also start with NS lookups and then perform a SOA lookup with optimisations if you get a cachable negative response. Mark > If someone's going to argue that you carefully watch your query stream > and only add new names for which there hasn't been a NXDOMAIN query > within the appropriate interval from any of your DNS servers, I'll > believe it when I see it. > > R's, > John > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
>You could apply the technique to any signed zone where you are not >worried about not having instant visibility after adding a new name >to the zone. I don't understand this. If I ask for foo.example and get NXDOMAIN, and 10 ms later you add a record at foo.example, my negative answer is cached for your SOA TTL is. Using NSEC to synthesize responses doesn't fundamentally change the situation, it just increases the set of names that negative cache entries will cover and maybe changes the time if the NSEC and SOA TTLs are different. Unless all of your TTLs are zero, there's no such thing as a new name that's instantly visible to every client. If someone's going to argue that you carefully watch your query stream and only add new names for which there hasn't been a NXDOMAIN query within the appropriate interval from any of your DNS servers, I'll believe it when I see it. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
At Tue, 01 Mar 2016 08:24:05 +1100, Mark Andrews wrote: > > > >Please no. (Ed might disagree with me on this.) I think every document > > > >that talks about the DNS in the IETF is about the IANA-administered DNS > > > >except where loudly noted. > > > > > > I very much disagree coming from operating DNS on networks other than the > > > global public Internet. > > > > I'm with Ed here. In my understanding RFCs of DNS related protocols > > generally don't make such explicit notes but are still generally used > > in DNS operations in closed intranet. And I think that's more > > sensible default interpretation. So, if a document relies on specific > > characteristics of the IANA-administered DNS like this draft, it's > > better to note that explicitly (on the other hand, I don't think we > > should consider draft-fujiwara-dnsop-nsec-aggressiveuse to be limited > > to the IANA-administered DNS simply because it doesn't loudly note it > > can be used more generally). > You could apply the technique to any signed zone where you are not > worried about not having instant visibility after adding a new name > to the zone. It is the later that is a property of the root zone > which is missing in many others. People want to be able to create > a delegation in .com and have it available for use within a couple > of minutes. In case you are replying to my message: I guess we're talking about different things...I thought that the specific point in this sub-thread is that *given the author's intent is to focus on the root zone*, whether this should be explicitly noted or whether we should rather omit such a note as the obvious. You seem to talk about whether we should focus on the root in the first place or whether nsec-aggressiveuse is risky or not in general. That's a totally different discussion, on which I already stated I have no particular opinion. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
In message , =?UTF-8?B?56We5piO6YGU5ZOJ?= writes: > At Mon, 29 Feb 2016 16:54:49 +, > Edward Lewis wrote: > > > >Please no. (Ed might disagree with me on this.) I think every document > > >that talks about the DNS in the IETF is about the IANA-administered DNS > > >except where loudly noted. > > > > I very much disagree coming from operating DNS on networks other than the > > global public Internet. > > I'm with Ed here. In my understanding RFCs of DNS related protocols > generally don't make such explicit notes but are still generally used > in DNS operations in closed intranet. And I think that's more > sensible default interpretation. So, if a document relies on specific > characteristics of the IANA-administered DNS like this draft, it's > better to note that explicitly (on the other hand, I don't think we > should consider draft-fujiwara-dnsop-nsec-aggressiveuse to be limited > to the IANA-administered DNS simply because it doesn't loudly note it > can be used more generally). > > -- > JINMEI, Tatuya You could apply the technique to any signed zone where you are not worried about not having instant visibility after adding a new name to the zone. It is the later that is a property of the root zone which is missing in many others. People want to be able to create a delegation in .com and have it available for use within a couple of minutes. That said .COM is OPTOUT (NSEC3 is fine) so you can't do ANC there anyway but the principle still applies to other zones. I'm not worried about this one at all and no one else should be either if you think about it. This is a opportunistic optimisation. If you have the NSEC records then you can synthesis the negative response. If you don't, which will happen with a fresh cache, then you perform a lookup, validate the response, etc. The worst that will happen is that you waste time looking for NSEC records in the cache and don't find them. Mark > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
At Mon, 29 Feb 2016 16:54:49 +, Edward Lewis wrote: > >Please no. (Ed might disagree with me on this.) I think every document > >that talks about the DNS in the IETF is about the IANA-administered DNS > >except where loudly noted. > > I very much disagree coming from operating DNS on networks other than the > global public Internet. I'm with Ed here. In my understanding RFCs of DNS related protocols generally don't make such explicit notes but are still generally used in DNS operations in closed intranet. And I think that's more sensible default interpretation. So, if a document relies on specific characteristics of the IANA-administered DNS like this draft, it's better to note that explicitly (on the other hand, I don't think we should consider draft-fujiwara-dnsop-nsec-aggressiveuse to be limited to the IANA-administered DNS simply because it doesn't loudly note it can be used more generally). -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On Mon, Feb 29, 2016 at 11:27 AM Paul Hoffman wrote: > On 29 Feb 2016, at 8:13, Warren Kumari wrote: > > > I *think* that the document / proposal implicitly handles this case > > already. > > Please make the "if the root zone isn't signed with NSEC then fall back" > explicit. Implicit to you is confusing to others. > > > > If the root (of whatever tree / name resolution system you have) is > > not > > DNSSEC signed, you do not get back valid NSEC records. If you do not > > get > > back valid NSEC records, there is no work to do. > > It's more than that. It is "and you have to go back to doing 4035". > "If the root zone is no longer DNSSEC signed with NSEC records then this document no longer applies. Resolvers MUST continue to work in such an environment." Not sure where I can add the "do 4035" wording - if the root is no longer DNSSEC signed, 4035 doesn't apply at all. I think that the above text handles things, but I may be missing something... > > > I guess I could sprinkle "DNS" all over: > > "The scope of this document is limited to the special case of > > recursive > > DNSSEC validating resolvers querying the root zone.", e.g > > "The scope of this document is limited to the special case of > > recursive > > DNSSEC validating resolvers querying the IANA administered DNS root > > zone." > > Please no. (Ed might disagree with me on this.) I think every document > that talks about the DNS in the IETF is about the IANA-administered DNS > except where loudly noted. > I added "global DNS root zone." initially, but I've just removed global (in the editor copy / github version - I'm try to incorporate people's comments as I get them, so that folk can follow along at home and make sure that I'm accurately capturing what they are requesting. Current version is (hopefully always!) at: https://github.com/wkumari/draft-wkumari-dnsop-cheese-shop/ ) > > --Paul Hoffman > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On 2/29/16, 11:26, "Paul Hoffman" wrote: >Please no. (Ed might disagree with me on this.) I think every document >that talks about the DNS in the IETF is about the IANA-administered DNS >except where loudly noted. I very much disagree coming from operating DNS on networks other than the global public Internet. This isn't about alternate versions of root zones, but about separating the operations ecosystem from the protocol engineering architecture. On 29 Feb 2016, at 6:12, Shane Kerr wrote: >Can't a couple sentences address this concern? > >"If the root zone is not DNSSEC signed with NSEC records then the >Cheese Shop is closed and this document does not apply. Resolvers MUST >continue to work in such an environment." I have problems with this. It's not that the proposal would be okay if wrapped in 15 layers of "this only works for this small problem, don't extrapolate". Setting a precedent for special handling of one zone would be a bad example for future expeditions. Some might take this as meaning that assembling an NXDOMAIN from DNSSEC negative answers can only ever be done for the root zone. The question I have is "why is the root zone special?" Why is it supposedly a simple use case? The draft document does not establish why the root is special. Quoting section 2: # The scope of this document is limited to the special case of # recursive DNSSEC validating resolvers querying the root zone. This # is because the root zone has some well known properties which make it # a special case - we know it is DNSSEC signed, and uses NSEC, the # majority of the queries are "junk" queries, the rate of change is # relatively slow, and there are no odd corner cases such as wildcards. For any zone I can discover any of these things. We can tell if the data set is supposed to be signed, from that the zone, the presence of wildcards, and so on. A cache could, in a few retrievals, obtain all of the relevant records to determine a name error. in Section 3: # For the limited use case of this document (the DNS root) we believe # that this is an acceptable trade off - the (current) TTL of the # "negative cache" (in the SOA) is the same as the NSEC TTL (1 day). Again - what's significant? The values - for any zone easily discoverable. The timing? The TTL setting here is one hand clapping, what's the rate of queries toward the zone? It's relative. My discomfort regarding fracturing the protocol is that the recommendation is to alter a core algorithm of DNS resolvers (not tools around the DNS) based on the qname believed to be managed from the root zone. Will the "only-root" remain, will this open the barn for other protocol hacks to be special for a particular zone? Those are future considerations that drive me to keep operation optimizations out of the core algorithm. More pragmatically, what happens to code drops that restrict this to just the root once it is opened up to the rest of the tree? More planned obsolescence? I don't see why aggressive use of DNSSEC negative answers is any more or less risky at other levels of the hierarchy. I don't see why the root is special. I'm not convinced by the draft that it is. And I don't see this as much of an interoperability issue. We know that not all resolvers are written to be equal - there are domain names that appear in the upper rankings of URL activity that cannot be resolved via conventional means - yet people get to the sites. Resolvers already do funky things - and as someone who has been on the authoritative side for a long time, there's no standard behavior across resolvers. (Server selection, anyone?) So, why worry about this in an IETF document? Why don't implementers just try it and then compare "performance" (in quotes because I leave it up to the viewer to define the measurement)? What about an "experimental" describing trying this, with metrics for success, to be follow up in a year or so with numbers on the trade off? The mere documentation of how might be enough for some developers to include this in their code. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On 29 Feb 2016, at 8:13, Warren Kumari wrote: I *think* that the document / proposal implicitly handles this case already. Please make the "if the root zone isn't signed with NSEC then fall back" explicit. Implicit to you is confusing to others. If the root (of whatever tree / name resolution system you have) is not DNSSEC signed, you do not get back valid NSEC records. If you do not get back valid NSEC records, there is no work to do. It's more than that. It is "and you have to go back to doing 4035". I guess I could sprinkle "DNS" all over: "The scope of this document is limited to the special case of recursive DNSSEC validating resolvers querying the root zone.", e.g "The scope of this document is limited to the special case of recursive DNSSEC validating resolvers querying the IANA administered DNS root zone." Please no. (Ed might disagree with me on this.) I think every document that talks about the DNS in the IETF is about the IANA-administered DNS except where loudly noted. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On Mon, Feb 29, 2016 at 9:12 AM Shane Kerr wrote: > Ed, > > At 2016-02-29 12:51:16 + > Edward Lewis wrote: > > > On 2/25/16, 17:58, "DNSOP on behalf of Warren Kumari" > > wrote: > > > > >We have recently updated "Believing NSEC records in the DNS root" > > >(https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01). > > > > My objection to this document is based on the draft's proposal to specify > > a change to the protocol based on the data being carried in one > particular > > deployment of the protocol. > > Interesting concern, although I don't see how it can be otherwise. We > don't know what the properties of future protocols will be, so I don't > know how we can specify the behavior of resolvers using such protocols > would be. > > > If the DNS is built to assume that the root zone is DNSSEC signed with > > NSEC records and this is then "burned into software" the other > > inter-networks will be given the choice of having to turn on DNSSEC and > > NSEC for their root zone or developing other software. (Or...other > > inconvenient mitigations.) > > Can't a couple sentences address this concern? > > "If the root zone is not DNSSEC signed with NSEC records then the > Cheese Shop is closed and this document does not apply. Resolvers MUST > continue to work in such an environment." > I *think* that the document / proposal implicitly handles this case already. If the root (of whatever tree / name resolution system you have) is not DNSSEC signed, you do not get back valid NSEC records. If you do not get back valid NSEC records, there is no work to do. I guess I could sprinkle "DNS" all over: "The scope of this document is limited to the special case of recursive DNSSEC validating resolvers querying the root zone.", e.g "The scope of this document is limited to the special case of recursive DNSSEC validating resolvers querying the IANA administered DNS root zone." I'm (as always) happy to accept text - I've tossed Shane's in to make it clearer (?) - editor copy: https://github.com/wkumari/draft-wkumari-dnsop-cheese-shop I also have some comments from Jinmei (thanks!) to incorporate, hopefully later this afternoon. W > > Cheers, > > -- > Shane > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On Mon, Feb 29, 2016 at 10:04 AM Shane Kerr wrote: > Ed, > > At 2016-02-29 14:34:39 + > Edward Lewis wrote: > > I don't think I was clear - this is only about the DNS protocol. This > > document proposes that the DNS protocol behave differently depending on > > the data being carried (QNAME) in it's own messages. > > [...] > > > This isn't about processing different values differently, this is about > > changing the behavior of the protocol based on environmental factors. > Ah. So you don't like identifying magic zones (other than in-addr.arpa, > ip6.arpa, .example, .local, ...). Fair enough. > > But AIUI, the proposal is an observation that Fujiwara's > NXDOMAIN-from-NSEC proposal can be implemented safely today for the root > zone, so we may as well go ahead and do that while considering wider > usage. > Yup. I believe we should still pursue Fujiwara's document, but that is likely to take a significant time, and there are hurdles to overcome. This document limits things to a subset where we know things work correctly (and seem OK within 4035) - once we have demonstrated that things work OK here, it paves the way for more aggressive NSEC. > > Nothing about it prevents Fujiwara's technique from moving on, and > eventually being more widely deployed. If changes are needed in the > root or resolver behavior later... well, they would have been needed > anyway, right? > > > Yup. We view this as complementing, not competing with aggressive-nsec. > I don't expect to change your mind but hopefully I understand your > position and can thus disagree with your actual stance. ;) > > Cheers, > -- > Shane > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On 29 Feb 2016, at 6:12, Shane Kerr wrote: Can't a couple sentences address this concern? "If the root zone is not DNSSEC signed with NSEC records then the Cheese Shop is closed and this document does not apply. Resolvers MUST continue to work in such an environment." Shane's proposal would be a good addition and should alleviate Ed's concern. That is, the proposal is "in this zone at this time, X makes Y possible". Adding "If you implement this proposal, you have to check whether X still is valid and, if not, go back to what you were doing before" is a good idea. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On 2/29/16, 10:03, "Shane Kerr" wrote: >Ah. So you don't like identifying magic zones (other than in-addr.arpa, >ip6.arpa, .example, .local, ...). Fair enough. What's magic about any of them? In the protocol they all are processed the same. There is no "reverse DNS" protocol, what's confusing is that there is a convention for storing addresses in the DNS. (E.g., myhost.*.foo.bar.in-addr.arpa. is an acceptable domain name. Applications never seriously look it up.) If asked on port 53, name servers will return NXDOMAIN for names under "example." and "local." if those names lack NS sets in the root zone. All magic treatment of those names occur in other software layers. >I don't expect to change your mind but hopefully I understand your >position and can thus disagree with your actual stance. ;) I have no idea why assembling a NXDOMAIN response from cached DNSSEC negative answers is any different if the QNAME is managed by the root zone or is managed by a zone delegated away from the root. The only thing unique to the root zone is that there is no authority that can publish the root zone's DS record, which has nothing to do with the question at hand. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
Ed, At 2016-02-29 14:34:39 + Edward Lewis wrote: > I don't think I was clear - this is only about the DNS protocol. This > document proposes that the DNS protocol behave differently depending on > the data being carried (QNAME) in it's own messages. [...] > This isn't about processing different values differently, this is about > changing the behavior of the protocol based on environmental factors. Ah. So you don't like identifying magic zones (other than in-addr.arpa, ip6.arpa, .example, .local, ...). Fair enough. But AIUI, the proposal is an observation that Fujiwara's NXDOMAIN-from-NSEC proposal can be implemented safely today for the root zone, so we may as well go ahead and do that while considering wider usage. Nothing about it prevents Fujiwara's technique from moving on, and eventually being more widely deployed. If changes are needed in the root or resolver behavior later... well, they would have been needed anyway, right? I don't expect to change your mind but hopefully I understand your position and can thus disagree with your actual stance. ;) Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On 2/29/16, 9:12, "DNSOP on behalf of Shane Kerr" wrote: >Interesting concern, although I don't see how it can be otherwise. We >don't know what the properties of future protocols will be, so I don't >know how we can specify the behavior of resolvers using such protocols >would be. I don't think I was clear - this is only about the DNS protocol. This document proposes that the DNS protocol behave differently depending on the data being carried (QNAME) in it's own messages. (I.e., the rule could be stated: if the QNAME is a single label, then if the QTYPE is NSEC the NSEC can be used to assemble other NXDOMAIN responses. This assumes the root zone owns only single label names [and is DNSSEC signed with NSEC], which might not be true for all root zones.) This isn't about processing different values differently, this is about changing the behavior of the protocol based on environmental factors. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
Ed, At 2016-02-29 12:51:16 + Edward Lewis wrote: > On 2/25/16, 17:58, "DNSOP on behalf of Warren Kumari" > wrote: > > >We have recently updated "Believing NSEC records in the DNS root" > >(https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01). > > My objection to this document is based on the draft's proposal to specify > a change to the protocol based on the data being carried in one particular > deployment of the protocol. Interesting concern, although I don't see how it can be otherwise. We don't know what the properties of future protocols will be, so I don't know how we can specify the behavior of resolvers using such protocols would be. > If the DNS is built to assume that the root zone is DNSSEC signed with > NSEC records and this is then "burned into software" the other > inter-networks will be given the choice of having to turn on DNSSEC and > NSEC for their root zone or developing other software. (Or...other > inconvenient mitigations.) Can't a couple sentences address this concern? "If the root zone is not DNSSEC signed with NSEC records then the Cheese Shop is closed and this document does not apply. Resolvers MUST continue to work in such an environment." Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
On 2/25/16, 17:58, "DNSOP on behalf of Warren Kumari" wrote: >We have recently updated "Believing NSEC records in the DNS root" >(https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01). My objection to this document is based on the draft's proposal to specify a change to the protocol based on the data being carried in one particular deployment of the protocol. (The temptation to define the special protocol behaviors for a special use case came up when we'd considered altering the DNSSEC signing definition for dotCOM. At the time, a 750K delegation-large zone was larger than a 100MHz PC could handle. We didn't, eventually an "opt-out" proposal was adopted that would work with any zone.) The DNS protocol is used in more than just the global public Internet. I.e., there are other inter-network environments in production use, run independently of the internet. The cross-over between the such environments and the internet is the use of the same software. If the DNS is built to assume that the root zone is DNSSEC signed with NSEC records and this is then "burned into software" the other inter-networks will be given the choice of having to turn on DNSSEC and NSEC for their root zone or developing other software. (Or...other inconvenient mitigations.) This has nothing to do with whether NXDOMAIN responses can or should be assembled by a DNS intermediary. That's an entirely different question. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop