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
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
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
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 tech
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
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
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
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 pro
>> 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
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
reg
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 th
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
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
>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 name
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
> 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.
>>
>>
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 NXDOMA
>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
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 opera
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
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
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 c
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 p
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 resolu
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/draf
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
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 b
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
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 diff
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
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
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 ba
32 matches
Mail list logo