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 insisting on
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: Do
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 server.
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
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 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 you can
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 assumption
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.
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 not
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
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
me.
It
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 for you if you
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 two-click tool
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 operator
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
: 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 instance
Note: The following
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
Bill Woodcock wo...@pch.net 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
Bill Woodcock wo...@pch.net 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
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 actual
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 inference intended;
On Tue, 27 Sep 2011 22:51:09 +0900
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp 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
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 diagnosis
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 may not
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 see
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, xun...@isi.edu wrote:
Hi all,
Our research group has been looking at assessing anycast usage.
(We have a technical report about
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,
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
meant
-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
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 the
Quoting Paul Hoffman paul.hoff...@vpnc.org:
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
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 mo...@necom830.hpcl.titech.ac.jp:
xun...@isi.edu wrote:
One result of that work is that we think
Thank you very much, Masataka!
Quoting Masataka Ohta mo...@necom830.hpcl.titech.ac.jp:
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
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
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 hostname
On Sun, Sep 25, 2011 at 12:19 PM, Paul Hoffman paul.hoff...@vpnc.orgwrote:
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
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. node is
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,
38 matches
Mail list logo
