Subject: [DNSOP] A new appoarch for identifying anycast name server instance

From: [email-masked]
Date: Sun, 25 Sep 2011 11:26:46 -0700

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'd like to use
in-band class-IN TXT records to augment what is done today
with class-CHAOS records today (RFC-4892).  In discussing
our findings and proposed approach with ISC, they recommended
we put together an internet-draft that documents our proposal.

We have a draft of our proposal with rationale at
http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt

We'd love to get feedback from the working group,
and to know if this sort of diagnosis would be something
appropriate for the WG to take up.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Sep 2011 12:19:19 -0700

> 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" meme seems to be accepted by nearly everyone in the DNS world.

You do not define the difference between an "instance" and a "node", and RFC 4892 doesn't define "node". Either clearly differentiate them here, or maybe just get rid of "node".

--Paul Hoffman

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 26 Sep 2011 09:19:02 +0900

[email-masked] wrote:

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

So, what diagnosis, are you considering, becomes possible
only by your proposal?

Also, I'm afraid a fantastic idea of "anycast node" of
RFC4892 is a result of broken specification of IPv6 anycast
(yes, IPv6 is broken in several ways), which assumes there
should be more than one anycast servers sharing an anycast
address on a link. Anyway, we can't discuss anything
meaningful about "anycast node", because its definition
is too fuzzy.

As the terminology is very confusing with "node" of domain
tree and "node" of IPv6, the entire idea of "anycast node"
should better be silently ignored.

						Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Sep 2011 10:09:37 -0400

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, <[email-masked]> wrote:
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 Sep 2011 13:53:19 -0400

> 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, VERSION.SERVER as well as RFC5001/NSID on L-Root, for example.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Sep 2011 14:21:48 -0400

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 implement 
this, there are many that won't, including us.  (Lecture on internal 
monitoring, et.al., elided.)

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.

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.

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

---

From: John Heidemann <[email-masked]>
Date: Tue, 27 Sep 2011 13:00:29 -0700

On Tue, 27 Sep 2011 14:21:48 EDT, Edward Lewis wrote: 
>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.
>
>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.

This discussion from several folks suggests that security and access
control are worth thinking about more than the current draft does.

As for the WG scoping question:  there was enough interest that RFC-4892
was written in 2007.  What's proposed is, in one sense, a more general
RFC-4892.  If that was intesting enough then, has anything changed to
make the topic no longer interesting?

Part of our motivation is that if we make diagnosis easier and more
powerful, perhaps new people will want to do it.  For example, enabling
customers of a service to independently validate they're getting the
coverage they're paying for.

(Of course, you have to decide if that example is a reason for, or against :-)

   -John Heidemann

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Sep 2011 16:17:25 -0400

On Sep 27, 2011, at 2:21 PM, Edward Lewis wrote:

> No argument with that.  But since the question was asked...  What I meant is that although there are places that will want to implement this, there are many that won't, including us.  (Lecture on internal monitoring, et.al., elided.)
> 
> 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.
> 
> There's nothing wrong with anyone implementing this.  But whether this is a DNSOP WG item rests on how broad the interest is

I for one am interested and willing to work on this (responding for bean counting..)

> and if there's a need to coordinate for interoperability reasons.
>

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 27 Sep 2011 16:47:24 -0700

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

> I for one am interested and willing to work on this (responding for bean counting..)

Likewise.  We don't need it internally, but it seems like a good idea, and I think we'd be happy to support it, if it were done well.  We're happy to work on it.

                                -Bill Woodcock
                                 Research Director
                                 Packet Clearing House

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 28 Sep 2011 11:11:41 +0900

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

Identification of some component within a server is an issue
totally depending on internal implementation of the server.

I can see nothing left for DNSOP WG.

						Masataka Ohta

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 28 Sep 2011 09:23:42 +0200

On Tue, Sep 27, 2011 at 02:21:48PM -0400,
 Edward Lewis <[email-masked]> wrote 

> trouble ticket that needed to know which any cast instance was being

I suspect it will become more and more common, with legal mangling of
the DNS (as is discussed in France) and various manipulation by
intermediaries (see 
<https://www.eff.org/deeplinks/2011/07/widespread-search-hijacking-in-the-us> or 
<http://www.dslreports.com/forum/r25921912-DLINK-Router-Advanced-DNS-Setup-Causing-Issues->).

So, I support the idea: there is a need here.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 28 Sep 2011 16:40:16 +0900

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Sep 2011 08:47:08 -0400

> It's not a matter of honesty.

No inference intended; what I meant was we let the software report its actual version number, and the actual hostname of the server rather than overriding them (as I've seen some people do).

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 28 Sep 2011 05:50:42 -0700

> No inference intended; what I meant was we let the software report its actual version number, and the actual hostname of the server rather than overriding them (as I've seen some people do).

Just a sampling of some of the version strings we've seen in scanning DNS resolvers and authorities:

"The name is BIND, James BIND"
"Enterprise I don't think so captain"
"13:54 <@zarkdav> well, one could write a zone file so that it returns a joke"
"666 the number of the beast...!"
"A kinky version of course"
"ALL YOUR BASE ARE BELONG TO US"
"All we are is dust in the wind"
"Are you still shivering? Are you still cold? Are you loathsome tonight? Does your madness shine bright?"
"Ash nazg durbatuluk, ash nazg gimbatul, ash nazg thrakatuluk agh burzum-ishi krimpatul."
"Aye, Carumba!  He's looking at me version string!"

(We have even received abuse complaints for querying for version strings!)

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Sep 2011 10:34:24 -0400

>DNS resolvers and authorities:
...
>(We have even received abuse complaints for querying for version strings!)

I think that hiding the version in a sarcastic way is going too far. 
I prefer to put in "contact xyz for this information."  We put in 
URLs to contact.

Version discovery never was part of the protocol, so I wouldn't be 
inclined to include it.  When offering a service though, hiding the 
unnecessary details is something I've come to appreciate.

One of the early lessons in this way came from the days when networks 
were "new" things.  Working on a multi-building campus and a new 
thing called "fiber" we got a spool of fiber coated in red.  Not 
orange, red.  The only difference was the color of the outer sheath.

Once some of our internal relying parties found out that we had used 
the "red" fiber they waged war to get the "orange" fiber to replace 
it.  Cooler heads prevailed and we swore never again to talk about 
the color of the fiber sheath in front of others.

As far as DNS as a service, I'd rather just have the customer say "I 
can't do this, and this is where I am".  Once customers begin to 
diagnose the situation, they generally set up incorrect expectations. 
With incorrect expectations comes resentment when the real fix goes 
in against what they thought should have happened.

---

From: David Conrad <[email-masked]>
Date: Wed, 28 Sep 2011 08:06:56 -0700

Ed,

On Sep 28, 2011, at 7:34 AM, Edward Lewis wrote:
> As far as DNS as a service, I'd rather just have the customer say "I can't do this, and this is where I am".  

How is a customer to know where they are in the network topology as seen from their ISP (particularly in a world of a myriad of twisty little tunnels, all alike)?

Regards,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Wed, 28 Sep 2011 11:36:59 -0400

At 8:06 -0700 9/28/11, David Conrad wrote:

>How is a customer to know where they are in the network topology as seen
>from their ISP (particularly in a world of a myriad of twisty little
>tunnels, all alike)?

If you ask me "+norec": "I don't know."

The answer to this would require conjecture about a situation which 
we don't come across in our daily activity.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 28 Sep 2011 09:28:20 -0700

On Sep 28, 2011, at 7:34 AM, Edward Lewis wrote:
> As far as DNS as a service, I'd rather just have the customer say "I can't do this, and this is where I am".  Once customers begin to diagnose the situation, they generally set up incorrect expectations. With incorrect expectations comes resentment when the real fix goes in against what they thought should have happened.

I disagree, and here's why...

A lot of the diagnosis needs to be done from tools running on the customer side.  The customer may have no role in interpreting the tool beyond performing a mouseclick or two to launch it (eg, something like Netalyzr running from the browser).

But in order for such tools to operate, the data in question needs to be accessible from the customer's computer.