Nicholas Weaver wrote:
>> Don't solve a simple problem in such a complex way.
>
> If it can affect users, it should be testable from the user's system if
> possible.
The way to solve a complex problem is "divide and conquer".
The obvious point of division is the caching resolver.
You insistin
On Sep 30, 2011, at 5:56 PM, Masataka Ohta wrote:
> Nicholas Weaver wrote:
>
>> Correct. But this is why you need to have queries that check the
>> caching server AS WELL. The CHAOS queries are useful here, as
>> are queries for the cached normal data, and queries which infer
>> glue policy so
Nicholas Weaver wrote:
> Correct. But this is why you need to have queries that check the
> caching server AS WELL. The CHAOS queries are useful here, as
> are queries for the cached normal data, and queries which infer
> glue policy so you can know if/what the cached normal data is being
> used
On 30/09/2011 14:22, Nicholas Weaver wrote:
> The Old Fashoned Mail Reader Flame War below: Everyone else just
> stop reading now and save your eyeballs.
By all means carry on with the discussion of the identification of
anycast nameserver instances, but Mail Reader Flame Wars are not in
the sco
Your technical comments:
>> b: These should have a TTL of 0 seconds and/or support a
>> prepended, cache-busting wildcard.
>
> Loss of synchronization can occur between cached normal data
> and uncached identification data. And, as I already mentioned
> what is broken may be the caching serve
Nicholas Weaver wrote:
> Note: The following is manually formatted because
because you choose not to use a feature of modern mail
composers?
>> As for subtlety, what if, the information is cached and stale?
>
> Good point, but there are easy solutions:
You are still missing the subtlety.
> a
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
Nicholas Weaver
Sent: Thursday, September 29, 2011 1:13 PM
To: Masataka Ohta
Cc: Paul Vixie; dnsop@ietf.org; Nicholas Weaver
Subject: Re: [DNSOP] A new appoarch for identifying anycast name server
Note: The following is manually formatted because
you are incapable of using a modern mail reader OR
have deliberately misconfigured your modern mail reader
OR are reading the message using a buggy archive:
On Sep 29, 2011, at 9:34 AM, Masataka Ohta wrote:
> Nicholas Weaver wrote:
>
>> I think
Nicholas Weaver wrote:
> I think you're missing something subtle here, both in this comment and in the
> "Do it in IP layer" comment.
I'm afraid it's you.
> This proposal allows debuging information about the "recursive
resolver TO anycast authority" path, a path which the user
AND anycast oper
On Sep 29, 2011, at 7:40 AM, Masataka Ohta wrote:
>>
>> And we're already seeing today, and expect more in the future,
>> systems where the front-line support instructions include
>> "run a one-click or two-click tool", rather than "run dig".
>
> It means those who can use "run a one-click or tw
Nicholas Weaver wrote:
>>> that happens sometimes. however, i often end up in an email conversation
>>> with
>>> a problem reporter, and i often ask them to run certain "dig" commands. so,
>>> even if i can't reach a recursive server, a feature like this can still help
>>> me.
>>
>> It may work
On Sep 29, 2011, at 4:05 AM, Masataka Ohta wrote:
>> that happens sometimes. however, i often end up in an email conversation
>> with
>> a problem reporter, and i often ask them to run certain "dig" commands. so,
>> even if i can't reach a recursive server, a feature like this can still help
>>
Paul Vixie wrote:
> that happens sometimes. however, i often end up in an email conversation with
> a problem reporter, and i often ask them to run certain "dig" commands. so,
> even if i can't reach a recursive server, a feature like this can still help
> me.
It may work for you if you don't r
On Thu, 29 Sep 2011, Paul Vixie wrote:
that happens sometimes. however, i often end up in an email conversation with
a problem reporter, and i often ask them to run certain "dig" commands. so,
even if i can't reach a recursive server, a feature like this can still help
me.
+1
May or may no
On Thursday, September 29, 2011 07:34:55 am Masataka Ohta wrote:
> The problem is that the report is unreliable. As your assumption is:
> > The purpose I see in this proposal, that cannot be handled by
> > the IP layer, is to tell me which anycast instance is seen
> > by some recursive name server.
Paul Vixie wrote:
>> Certainly, you, as an end user, can do so.
>
> i think i could diagnose problems reported on my authority server if
> i could get a recursive name server to tell me which of my anycast
> instances it is talking to.
The problem is that the report is unreliable. As your assump
On Tue, 27 Sep 2011 22:51:09 +0900
Masataka Ohta wrote:
> Paul Vixie wrote:
>
> > The purpose I see in this proposal, that cannot be handled by the
> > IP layer, is to tell me which anycast instance is seen by some
> > recursive name server. All our current diagnostics rely on
> > contacting th
On Sep 28, 2011, at 5:47 AM, Joe Abley wrote:
>
> On 2011-09-27, at 14:21, Edward Lewis wrote:
>
>>> We respond honestly to queries for HOSTNAME.BIND, VERSION.BIND, ID.SERVER,
>>> VERSION.SERVER as well as RFC5001/NSID on L-Root, for example.
>>
>> It's not a matter of honesty.
>
> No inferen
On 2011-09-27, at 14:21, Edward Lewis wrote:
>> We respond honestly to queries for HOSTNAME.BIND, VERSION.BIND, ID.SERVER,
>> VERSION.SERVER as well as RFC5001/NSID on L-Root, for example.
>
> It's not a matter of honesty.
No inference intended; what I meant was we let the software report its a
Bill Woodcock wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>
>
>
>On Sep 27, 2011, at 2:21 PM, Edward Lewis wrote:
>> Whether this is a DNSOP WG item rests on how broad the interest is
>
>On Sep 27, 2011, at 1:17 PM, Warren Kumari wrote:
>> I for one am interested and willing to w
Bill Woodcock wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>
>
>
>On Sep 27, 2011, at 2:21 PM, Edward Lewis wrote:
>> Whether this is a DNSOP WG item rests on how broad the interest is
>
>On Sep 27, 2011, at 1:17 PM, Warren Kumari wrote:
>> I for one am interested and willing to w
I have noticed that the good source of entropy for even
load balancing with reply suppression for duplicated
query is source port number and message-id, which means
identifying query is unstable.
Masataka Ohta
__
On Tue, Sep 27, 2011 at 02:21:48PM -0400,
Edward Lewis wrote
a message of 34 lines which said:
> I'd have to say that it has been a long time since there was a
> trouble ticket that needed to know which any cast instance was being
> hit by the user.
I suspect it will become more and more comm
Edward Lewis wrote:
> There's nothing wrong with anyone implementing this. But whether this is
> a DNSOP WG item rests on how broad the interest is and if there's a need
> to coordinate for interoperability reasons.
Identification of a server is an issue to be handled by a unicast
address at th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sep 27, 2011, at 2:21 PM, Edward Lewis wrote:
> Whether this is a DNSOP WG item rests on how broad the interest is
On Sep 27, 2011, at 1:17 PM, Warren Kumari wrote:
> I for one am interested and willing to work on this (responding for bean
>
On Sep 27, 2011, at 2:21 PM, Edward Lewis wrote:
> At 13:53 -0400 9/27/11, Joe Abley wrote:
>> Not very useful for Neustar, maybe, but I would suggest that your
>> requirements in this regard are likely not to be universal.
>
> No argument with that. But since the question was asked... What I
On Tue, 27 Sep 2011 14:21:48 EDT, Edward Lewis wrote:
>At 13:53 -0400 9/27/11, Joe Abley wrote:
>>Not very useful for Neustar, maybe, but I would suggest that your
>>requirements in this regard are likely not to be universal.
>
>No argument with that. But since the question was asked... What I
>
At 13:53 -0400 9/27/11, Joe Abley wrote:
Not very useful for Neustar, maybe, but I would suggest that your
requirements in this regard are likely not to be universal.
No argument with that. But since the question was asked... What I
meant is that although there are places that will want to i
On 2011-09-27, at 10:09, Edward Lewis wrote:
> A noble idea, but alas not terribly useful.
Not very useful for Neustar, maybe, but I would suggest that your requirements
in this regard are likely not to be universal.
We respond honestly to queries for HOSTNAME.BIND, VERSION.BIND, ID.SERVER,
V
A noble idea, but alas not terribly useful.
If this were available, we'd disable it in anything we deploy nor
build it into our code base.
At 11:26 -0700 9/25/11, wrote:
Hi all,
Our research group has been looking at assessing anycast usage.
(We have a technical report about our early findi
Paul Vixie wrote:
>> That is an issue better handled by IP layer.
>
> The purpose I see in this proposal, that cannot be handled by the IP layer, is
> to tell me which anycast instance is seen by some recursive name server. All
> our current diagnostics rely on contacting the server itself to se
On Tuesday, September 27, 2011 09:49:03 am Masataka Ohta wrote:
> Xun wrote:
> > Unicast address of an
> > anycast server is very useful for many diagnostics, however, as
> > DNS queries is sent to the anycast address and the path is decided
> > by routing system, knowing the set of unicast address
Xun wrote:
>> So, what diagnosis, are you considering, becomes possible
>> only by your proposal?
> The particular diagnostic that our
> proposal tries to provide is to tell which one of a set of
> anycast servers responses to a DNS query.
It's a reception by a hospital clerk rather than a diagn
Thank you very much, Masataka!
Quoting Masataka Ohta :
> I'm forwarding a mail from Xun as he mistakenly send it not to
> the list but to me.
>
> Masataka Ohta
>
> Original Message
> Quoting Masataka Ohta :
>
> > xun...@isi.edu wrote:
>
I'm forwarding a mail from Xun as he mistakenly send it not to
the list but to me.
Masataka Ohta
Original Message
Quoting Masataka Ohta :
> xun...@isi.edu wrote:
>
> > One result of that work is that we think additional information
> > w
Quoting Paul Hoffman :
> On Sep 25, 2011, at 1:53 PM, xun...@isi.edu wrote:
>
> > Sure, thanks for the advise. We can add "_" for "instance_id" and
> "node_id"
> > also, "_instance_id._ns-diagnostics.$ORIGIN",
> > "_node_id._ns-diagnostics.$ORIGIN"
>
> Sounds good.
>
> > Yes, the is not the fir
xun...@isi.edu wrote:
> One result of that work is that we think additional information
> would make anycast dianosis much easier---
How can it be made much easier?
All the anycast servers should have unicast addresses to be
used for zone transfer, which can be used for most, if not all,
diagnos
On Sep 25, 2011, at 1:53 PM, xun...@isi.edu wrote:
> Sure, thanks for the advise. We can add "_" for "instance_id" and "node_id"
> also, "_instance_id._ns-diagnostics.$ORIGIN",
> "_node_id._ns-diagnostics.$ORIGIN"
Sounds good.
> Yes, the is not the first time we have this terminology problem. "n
On Sun, Sep 25, 2011 at 12:19 PM, Paul Hoffman wrote:
> On Sep 25, 2011, at 11:26 AM, xun...@isi.edu wrote:
>
> > We have a draft of our proposal with rationale at
> > http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt
>
> Instead of "ns-diagnostics", using "_ns-diagnostics" woul
On Sep 25, 2011, at 11:26 AM, xun...@isi.edu wrote:
> We have a draft of our proposal with rationale at
> http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt
Instead of "ns-diagnostics", using "_ns-diagnostics" would be much better. The
"_ at the beginning of a label is not a hostn
Hi all,
Our research group has been looking at assessing anycast usage.
(We have a technical report about our early findings at
ftp://ftp.isi.edu/isi-pubs/tr-671.pdf if you're interested.)
One result of that work is that we think additional information
would make anycast dianosis much easier---we
41 matches
Mail list logo
