Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.

[Stephane Bortzmeyer]

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.

[Ólafur Guðmundsson]

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.

[Ólafur Guðmundsson]

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.

[Shane Kerr]

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.

[Evan Hunt]

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.

[Mark Andrews]

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.

[Ray Bellis]

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.

[Ólafur Guðmundsson]

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.

[John R Levine]

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.

[Mark Andrews]

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.finch    http://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.

[Mark Andrews]

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.

[Tony Finch]

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.finch    http://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.

[Philip Homburg]

>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.

[Mark Andrews]

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.

[Wessels, Duane]

> 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.

[Mark Andrews]

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.

[John Levine]

>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.

[神明達哉]

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.

[Warren Kumari]

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.

[Edward Lewis]

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.

[Paul Hoffman]

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.

[Warren Kumari]

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.

[Warren Kumari]

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.

[Paul Hoffman]

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.

[Edward Lewis]

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.

[Shane Kerr]

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.

[Edward Lewis]

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.

[Shane Kerr]

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.

[Edward Lewis]

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