Subject: [DNSOP] New Draft Charter

From: Peter Koch <[email-masked]>
Date: Tue, 11 Mar 2008 04:05:14 +0100

Dear WG,

after several attempts, here is the most recent version of the new DNSOP
charter to be discussed in tomorrow's WG session:

-----------------------------------------------------------------------------

The DNS Operations (DNSOP) Working Group will develop and review guidelines
for the correct, efficient and secure configuration of DNS authoritative
servers, resolvers, and DNSSEC validators.
Target audiences for those guidelines are zone administrators as well as
software developers who provide tools for DNS zone administration or (default)
server/resolver/validator configuration.

The group will perform the following activities:

1) develop or review guidelines for chosing zone configuration
   parameters that affect inter-server or server-resolver communication,
   including but not limited to SOA RR parameters, TTL values, and glue
   information

2) develop or review guidelines for any DNSSEC specific operational
   parameters, such as key length or key validity periods

3) investigate and identify requirements of DNSSEC to the lower layers,
   both transport and network
4) develop or review operational guidelines that address the specifics of
   IPv4/v6 coexistence and transition

5) review the use of existing DNS frameworks (SRV, DDDS) in other protocols,
   especially focussing on operational consequences and scalability, most
   importantly when these frameworks are used in other wg's protocol proposals.

6) develop and review guidelines for resolver (stub and full) behaviour,
   including search path and timing issues as well as query strategies.

7) establish terminology and methodology for performance measurements
   of servers, resolvers or the service as such.

8) identify the requirements for a name server configuration and control
   protocol.

To avoid overlap with the DNS Extensions working group, the DNSOP group
will not change the on the wire behaviour of the DNS.  Terminology issues
will, where appropriate, be addressed in coordination with DNSEXT.

-----------------------------------------------------------------------------

This version is expected to take into account the feedback given on the list
and during the WG meetings in and after 2006 as well as recent additions
to the set of active work items.

-Peter
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Mar 2008 07:36:14 -0400

On Tue, Mar 11, 2008 at 04:05:14AM +0100,
 Peter Koch <[email-masked]> wrote 

>    of servers, resolvers or the service as such.

Warning: for other protocols, this work is apparently done by WGs
specialized in benchmarking (bmwg, pmol), with the help of the WG
specialized in the technology.

I suggest that participants check the charters and work of these
benchmarking WGs before.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Mar 2008 07:36:14 -0400

---

From: Dean Anderson <[email-masked]>
Date: Tue, 11 Mar 2008 10:37:53 -0400 (EDT)

So root and gTLD DNS server operations supervision is off the charter?  
It used to be the first item.  This appears to affect ISOC IETF
commitments to ICANN to provide this technical role.

I'm not certain I'm against that--I just want to clarify that this isn't
an oversight.

1. Define the processes by which Domain Name System (DNS) software
      may be efficiently and correctly administered, configured, and
      operated on Internet networks. This will include root zone
      name servers, gTLD name servers, name servers for other DNS
      zones, iterative DNS resolvers, and recursive DNS resolvers.
      As part of this effort, the group will produce documents
      explaining to the general Internet community what processes
      and mechanisms should be employed for the effective management
      and operation of DNS software. 

		--Dean

On Tue, 11 Mar 2008, Peter Koch wrote:

> for the correct,From [email-masked]  Tue Mar 11 07:41:10 2008
Date: Tue, 11 Mar 2008 10:37:53 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Peter Koch <[email-masked]>
Cc: IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] New Draft Charter
Sender: [email-masked]

So root and gTLD DNS server operations supervision is off the charter?  
It used to be the first item.  This appears to affect ISOC IETF
commitments to ICANN to provide this technical role.

I'm not certain I'm against that--I just want to clarify that this isn't
an oversight.

1. Define the processes by which Domain Name System (DNS) software
      may be efficiently and correctly administered, configured, and
      operated on Internet networks. This will include root zone
      name servers, gTLD name servers, name servers for other DNS
      zones, iterative DNS resolvers, and recursive DNS resolvers.
      As part of this effort, the group will produce documents
      explaining to the general Internet community what processes
      and mechanisms should be employed for the effective management
      and operation of DNS software. 

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

 efficient and secure configuration of DNS authoritative

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Joe Abley <[email-masked]>
Date: Tue, 11 Mar 2008 10:53:54 -0400

> So root and gTLD DNS server operations supervision is off the charter?

I'm not sure it was ever on the charter.

The paragraph you quoted seems to suggest that the attention of the  
working group is equally-focussed on root, TLD and all other  
nameservers, whether authority-only servers or not.

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 11 Mar 2008 10:53:54 -0400

Joe

---

From: Peter Koch <[email-masked]>
Date: Tue, 11 Mar 2008 16:15:42 +0100

Dean,

> So root and gTLD DNS server operations supervision is off the charter?  

to the extent that is has never been there, yes.

> commitments to ICANN to provide this technical role.

If you could support this observation by tangible textual reference, that would
be appreciated. As a side note, there is an IETF liaison to ICANN, independent
of whatever WG charter.

>       zones, iterative DNS resolvers, and recursive DNS resolvers.

My recollection of the previous discussion of this exact issue is that
people were in favour of not mentioning any particular systems in the
hierarchy especially to avoid the perception conveyed above.  Note however,
that the charter as proposed would _not_ prevent the DNSOP WG from, say,
updating RFC 2870.

-Peter
_________________From [email-masked]  Tue Mar 11 08:18:36 2008
Date: Tue, 11 Mar 2008 16:15:42 +0100
From: Peter Koch <[email-masked]>
To: IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] New Draft Charter
Sender: [email-masked]

Dean,

> So root and gTLD DNS server operations supervision is off the charter?  

to the extent that is has never been there, yes.

> commitments to ICANN to provide this technical role.

If you could support this observation by tangible textual reference, that would
be appreciated. As a side note, there is an IETF liaison to ICANN, independent
of whatever WG charter.

>       zones, iterative DNS resolvers, and recursive DNS resolvers.

My recollection of the previous discussion of this exact issue is that
people were in favour of not mentioning any particular systems in the
hierarchy especially to avoid the perception conveyed above.  Note however,
that the charter as proposed would _not_ prevent the DNSOP WG from, say,
updating RFC 2870.

-Peter

______________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Mar 2008 11:30:56 -0400

Dear colleagues,

> nameservers, whether authority-only servers or not.

While that's true, the older text also explictly says that the WG is
interested in administration, configuration, and operation of the DNS:

      Define the processes by which Domain Name System (DNS) software may be
      efficiently and correctly administered, configured, and operated on
      Internet networks.

It seems to me that that additional scope is worth retaining.  Perhaps this
sentence

      The DNS Operations (DNSOP) Working Group will develop and review
      guidelines for the correct, efficient and secure configuration of DNS
      authoritative servers, resolvers, and DNSSEC validators.

could be altered slightly to 

      The DNS Operations (DNSOP) Working Group will develop and review
      guidelines for the correct, efficient and secure configuration,
      administration, and operation of DNS authoritative servers, resolvers,
      and DNSSEC validators.

?

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Mar 2008 11:30:56 -0400

Dear colleagues,

?

A

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 11 Mar 2008 16:34:44 +0100

It is in the current charter ...

	jaap

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 11 Mar 2008 16:34:44 +0100

jaap

---

From: Dean Anderson <[email-masked]>
Date: Tue, 11 Mar 2008 12:09:27 -0400 (EDT)

> nameservers, whether authority-only servers or not.

I didn't say the charter was exclusively oriented to root and gTLD
operations. But the current charter explicitly includes them, and the
proposed new charter does not.

This is not the first time we've discussed these issues. The last time
changes to the charter were proposed, I brought up the same issue. Back
then I opposed removing root and gTLD operations from the charter. Now,
I'm not so certain it isn't a good idea.  As I wrote back then:

  It seems to me the issues outlined in the current charter element
  above are still a fundamental and important part of the DNSOP mission,
  particularly with respect to the ICANN MoU and RFC 2870, which give a
  substantial role to the IETF on DNS Root server operations.

There is still an effect on the ICANN MoU and RFC 2870. For one thing,
updating RFC 2870 would appear to be out of scope in the proposed new
DNSOP charter.

The change in my position is that I'm no longer quite so certain root
and gTLD operations are a vital part of the IETF or DNSOP mission.  I
think the subject of root and gTLD supervision is a vital part for
_someone_ or _something_, but perhaps not the IETF.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 11 Mar 2008 12:09:27 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 11 Mar 2008 12:24:40 -0400 (EDT)

> be appreciated. As a side note, there is an IETF liaison to ICANN, independent

I'm not sure what you mean to dispute. The text of the charter I quoted
cites "This will include root zone name servers, gTLD name servers
[...]" I don't think it can be made plainer.

The liason role is communicative; the liason communicates the consensus
of (in this case) DNSOP.  The person of liason has not previously been
the sole technical expert provided by the IETF. But if that becomes so,
this isn't what is described in the MoU.  The IETF technical expertise
is the combined contributions of its members through consensus and broad
industry support.  The liason cannot represent a non-existant consensus.  
If there is merely one person (the liason) then the value of that
opinion is also reduced, as there is no genuine industry consensus in
the opinion of just one person.

> hierarchy especially to avoid the perception conveyed above.

People in favor of changing the charter indeed held the position you
describe. But my recollection is that the charter wasn't changed; those
people didn't have a consensus to change the charter that way at that 
time.

> Note however, that the charter as proposed would _not_ prevent the
> DNSOP WG from, say, updating RFC 2870.

Under what provision of the new charter would RFC 2870 fall under?

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 11 Mar 2008 12:24:40 -0400 (EDT)

--Dean

---

From: Peter Koch <[email-masked]>
Date: Fri, 14 Mar 2008 04:18:16 +0100

On Tue, Mar 11, 2008 at 11:30:56AM -0400, Andrew Sullivan wrote:

[...]

>       administration, and operation of DNS authoritative servers, resolvers,

Since the omission of "administration, and operation" was kind of an oversight and
Andrew's suggestion found support, this will be re-added as proposed above.

Rob and I will coordinate with the bmwg chair on the "perf & measurement" part
of the charter and then issue a WGLC, after which we'll enter negotiations with
the AD(s) regarding deliverables and milestones.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Fri, 14 Mar 2008 04:18:16 +0100

[...]

-Peter

---

From: Peter Koch <[email-masked]>
Date: Fri, 14 Mar 2008 05:06:11 +0100

Dean,

> [...]" I don't think it can be made plainer.

the fact that name servers dealing with a certain level in the DNS hierarchy or
with certain parts of the DNS tree are not or are no longer explicitly mentioned
does not imply that they could not taken into special consideration where
appropriate.

> this isn't what is described in the MoU.  The IETF technical expertise

IETF Liaisons are appointed by and report to the IAB.  There is an IAB
statement regarding the IETF's Liaison to the ICANN Board of Directors at
<hFrom [email-masked]  Thu Mar 13 21:08:44 2008
Date: Fri, 14 Mar 2008 05:06:11 +0100
From: Peter Koch <[email-masked]>
To: Dean Anderson <[email-masked]>
Cc: IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] New Draft Charter
Sender: [email-masked]

Dean,

> [...]" I don't think it can be made plainer.

the fact that name servers dealing with a certain level in the DNS hierarchy or
with certain parts of the DNS tree are not or are no longer explicitly mentioned
does not imply that they could not taken into special consideration where
appropriate.

> this isn't what is described in the MoU.  The IETF technical expertise

IETF Liaisons are appointed by and report to the IAB.  There is an IAB
statement regarding the IETF's Liaison to the ICANN Board of Directors at
<http://www.iab.org/liaisons/icann/icann-liaison.html>.  Neither DNSOP nor
any other IETF WG is mentioned there and is at the sole discretion of the
IAB to consult with IETF WGs in its (the IAB's) role of assisting the
Liaison in executing their duties.  I asked you to provide tangible reference
(i.e. "chapter and verse") to support your view of DNSOP having a special
role w.r.t. root server operations.  I fail to see this information having
been provided.  Also, there was no support of your view. Therefore I consider
this issue closed.

> people didn't have a consensus to change the charter that way at that 

The sad fact is that me dropped the ball on the charter work.

> Under what provision of the new charter would RFC 2870 fall under?

The general clause

  The DNS Operations (DNSOP) Working Group will develop and review guidelines
  for the correct, efficient and secure configuration, administration, and
  operation of DNS authoritative servers, resolvers, and DNSSEC validators.

would certainly cover this.

-Peter [with hat]

ttp://www.iab.org/liaisons/icann/icann-liaison.html>.  Neither DNSOP nor
any other IETF WG is mentioned there and is at the sole discretion of the
IAB to consult with IETF WGs in its (the IAB's) role of assisting the
Liaison in executing their duties.  I asked you to provide tangible reference
(i.e. "chapter and verse") to support your view of DNSOP having a special
role w.r.t. root server operations.  I fail to see this information having
been provided.  Also, there was no support of your view. Therefore I consider
this issue closed.

> people didn't have a consensus to change the charter that way at that 

The sad fact is that me dropped the ball on the charter work.

> Under what provision of the new charter would RFC 2870 fall under?

The general clause

  The DNS Operations (DNSOP) Working Group will develop and review guidelines
  for the correct, efficient and secure configuration, administration, and
  operation of DNS authoritative servers, resolvers, and DNSSEC validators.

would certainly cover this.

-Peter [with hat]

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Mar 2008 18:52:44 -0400 (EDT)

What clause would DNS Root Anycast stability fall under?

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Mar 2008 18:52:44 -0400 (EDT)

--Dean

---

From: bill fumerola <[email-masked]>
Date: Fri, 21 Mar 2008 18:08:32 -0700

> What clause would DNS Root Anycast stability fall under?

anycast has so much more to do with routing than dns. dns just happens
to be an often used consumer of anycast. there are others. it seems
more appropriate to centralize problems with anycast routing in a
WG that deals with routing than one that deals with a consumer.

if i felt the use of anycast by root server operators is causing
instability, i would take that up with the individual root server
operator(s) that i was experiencing instability with. but i'm not.

this WG certainly doesn't have the authority to directly instruct
individual root server operators how to configure their networks.

IANA could intervene. however, i would imagine IANA would want to see
agreement amongst multiple respected experts in the areas of routing and
dns operations. they'd need proof that your claims of root server
instability as a result of the use of anycast.

given the previous results of threads started/hijacked by you for this
purpose in this WG, i'm not sure what sort of verbage in the charter
would grant you the soapbox on top of which you wish to preach.

if you want to prove anycast [in]stability i'd suggest submitting and
presenting a technical paper to a respected org (USENIX comes to mind,
there are others). even within the IETF, you don't even need a WG charter
to submit an internet draft. individual submissions are made all the
time. often, a WG picks them up after sufficient discussion and review.

reasonable minds cannot ignore solid evidence. surely every avenue (many
exist beyond this WG) hasn't been so jaded by past experiences as to
reject your valid technical arguments, if they exist.

-- bill

[ full disclosure: i work for a company that uses anycast for dns and
		   other services, without instability. if anything, it
		   is in my best interests to know about a wolf at the
		   door from using anycast. i've just never heard anything
		   more than loud barking.

---

From: bill fumerola <[email-masked]>
Date: Fri, 21 Mar 2008 18:08:32 -0700

-- bill

---

From: Dean Anderson <[email-masked]>
Date: Tue, 25 Mar 2008 17:33:20 -0400 (EDT)

> operator(s) that i was experiencing instability with. but i'm not.

Are you using TCP DNS? Most people don't use TCP DNS. That is changing,
though.  I guess I don't recall who your work for, or what kind of
service you assert to be anycasting. But please do send me the details
of your anycasted service.

Over the last 3 years, a number of reports have come out that indicate
there are indeed stability problems with TCP Anycast.  Mark Kosters
(then at Verisign)  reported that he detected the same IP addresses at
multiple Anycast root DNS servers over short time frames, indicating
either fast path changes or load balancing.  Theory also indicates
(RFC1812) and states explicitly (RFC1546) that TCP Anycast isn't stable
and must be avoided.

The rest of the Anycast users I've come across aren't actually using
anycast, but have confused Anycast (RFC1546) with load balancing, as in
the kind you get from an F5.  Stateful loadbalancing ala F5,Cisco, etc
loadbalancers is not Anycast.

> this From [email-masked]  Tue Mar 25 14:35:48 2008
Date: Tue, 25 Mar 2008 17:33:20 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: bill fumerola <[email-masked]>
Cc: Peter Koch <[email-masked]>, IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] New Draft Charter
Sender: [email-masked]

> operator(s) that i was experiencing instability with. but i'm not.

Are you using TCP DNS? Most people don't use TCP DNS. That is changing,
though.  I guess I don't recall who your work for, or what kind of
service you assert to be anycasting. But please do send me the details
of your anycasted service.

Over the last 3 years, a number of reports have come out that indicate
there are indeed stability problems with TCP Anycast.  Mark Kosters
(then at Verisign)  reported that he detected the same IP addresses at
multiple Anycast root DNS servers over short time frames, indicating
either fast path changes or load balancing.  Theory also indicates
(RFC1812) and states explicitly (RFC1546) that TCP Anycast isn't stable
and must be avoided.

The rest of the Anycast users I've come across aren't actually using
anycast, but have confused Anycast (RFC1546) with load balancing, as in
the kind you get from an F5.  Stateful loadbalancing ala F5,Cisco, etc
loadbalancers is not Anycast.

> individual root server operators how to configure their networks.

It does, (or perhaps "it did").  Previously, this WG had authority over
RFC2870. RFC2870 does give direct instructions for root server operators
on how to e.g., configure their networks, physical security, and a lot
of other things. The ICANN/IANA received this technical advice from the
IETF, and now imposes it on root server operators. I previouly opposed
removing the root server operations element from its charter. But now I
think this WG and the IETF shouldn't have that charge.

		--Dean

P.S.

The rest is about history or what ought to be. But I don't think the
future of root DNS server management ought to be the subject of this
working group, so just stop reading now unless you like history.

> instability as a result of the use of anycast.

Actually, it seems odd that anycast operations were allowed to begin
without proof of stability in the first place.  I've read all the
scientific research on Anycast. All but one paper are non-commital or
didn't address stateful anycast. These are all after 2002.  There is
nothing from 2002 or before when Anycast was first deployed.

The root server operators seem to (or ought to) have the obligation to
prove stability, both in theory and in experiment before they undertake
risky changes to the architecture of the internet.

Indeed, this seems to be another reason to update RFC2870, if it truly
allows root server operators to make such risky and architectural
changes without proof of stability.

> would grant you the soapbox on top of which you wish to preach.

Perhaps then you support having root DNS operators give me NSID keys so
that I can do anycast testing on roots, directly. My tests so far have
been indirect, or else not on roots. But of the tests so far, I can
detect anycast'd recursors on the internet.  So indirectly, I have
proven the Anycast DNS Instability by experiment.

[I did so by getting different packets returned from each (several
caches each cache a different response---I just wrote a special server
and a client to keep track of each unique answer sent and the responses
to the queries. When you see the different and previous answers from the
same IP address, there are multiple caches and anycast has been
detected.  TCP packets in the same situation would result in a
connection failure.]

> there are others). even within the IETF, you don't even need a WG
> charter to submit an internet draft. individual submissions are made
> all the time. often, a WG picks them up after sufficient discussion
> and review.

Vixie and companies have prevented the IETF from hearing about Anycast.  
Just 2 years ago, I was PR-actioned for talking about Anycast on this
very working group by a conflicted A.D. (This is still the subject of
ongoing legal actions, so I can't say just too much, but we can't forget
the history)

> reasonable minds cannot ignore solid evidence. surely every avenue
> (many exist beyond this WG) hasn't been so jaded by past experiences
> as to reject your valid technical arguments, if they exist.

Indeed. It must be the case that either the minds are unreasonable or
else there is no evidence.  There is substantial evidence in anecdote,
theory, and experiment. So now why are the minds unreasonable?  Hmm?
Money is known to make people act that way. Could it be that people make
money on Anycast?  Surely not here! Surely there is no bad faith and
conflict of interest!

> -- bill
> 
> [ full disclosure: i work for a company that uses anycWG certainly doesn't have the authority to directly instruct

It does, (or perhaps "it did").  Previously, this WG had authority over
RFC2870. RFC2870 does give direct instructions for root server operators
on how to e.g., configure their networks, physical security, and a lot
of other things. The ICANN/IANA received this technical advice from the
IETF, and now imposes it on root server operators. I previouly opposed
removing the root server operations element from its charter. But now I
think this WG and the IETF shouldn't have that charge.

		--Dean

P.S.

The rest is about history or what ought to be. But I don't think the
future of root DNS server management ought to be the subject of this
working group, so just stop reading now unless you like history.

> instability as a result of the use of anycast.

Actually, it seems odd that anycast operations were allowed to begin
without proof of stability in the first place.  I've read all the
scientific research on Anycast. All but one paper are non-commital or
didn't address stateful anycast. These are all after 2002.  There is
nothing from 2002 or before when Anycast was first deployed.

The root server operators seem to (or ought to) have the obligation to
prove stability, both in theory and in experiment before they undertake
risky changes to the architecture of the internet.

Indeed, this seems to be another reason to update RFC2870, if it truly
allows root server operators to make such risky and architectural
changes without proof of stability.

> would grant you the soapbox on top of which you wish to preach.

Perhaps then you support having root DNS operators give me NSID keys so
that I can do anycast testing on roots, directly. My tests so far have
been indirect, or else not on roots. But of the tests so far, I can
detect anycast'd recursors on the internet.  So indirectly, I have
proven the Anycast DNS Instability by experiment.

[I did so by getting different packets returned from each (several
caches each cache a different response---I just wrote a special server
and a client to keep track of each unique answer sent and the responses
to the queries. When you see the different and previous answers from the
same IP address, there are multiple caches and anycast has been
detected.  TCP packets in the same situation would result in a
connection failure.]

> there are others). even within the IETF, you don't even need a WG
> charter to submit an internet draft. individual submissions are made
> all the time. often, a WG picks them up after sufficient discussion
> and review.

Vixie and companies have prevented the IETF from hearing about Anycast.  
Just 2 years ago, I was PR-actioned for talking about Anycast on this
very working group by a conflicted A.D. (This is still the subject of
ongoing legal actions, so I can't say just too much, but we can't forget
the history)

> reasonable minds cannot ignore solid evidence. surely every avenue
> (many exist beyond this WG) hasn't been so jaded by past experiences
> as to reject your valid technical arguments, if they exist.

Indeed. It must be the case that either the minds are unreasonable or
else there is no evidence.  There is substantial evidence in anecdote,
theory, and experiment. So now why are the minds unreasonable?  Hmm?
Money is known to make people act that way. Could it be that people make
money on Anycast?  Surely not here! Surely there is no bad faith and
conflict of interest!

> 		   door from using anycast. i've just never heard anything

Hmm. Interesting metaphor. Perhaps it is one's interests to ignore the
wolf while one profits from the door being open. I guess that case, one
must be a coyote or some other predator to make the metaphor work.

ast for dns and
> 		   door from using anycast. i've just never heard anything

Hmm. Interesting metaphor. Perhaps it is one's interests to ignore the
wolf while one profits from the door being open. I guess that case, one
must be a coyote or some other predator to make the metaphor work.

---

From: bert hubert <[email-masked]>
Date: Tue, 25 Mar 2008 22:37:03 +0100

> though.  I guess I don't recall who your work for, or what kind of

Fwiw, I tried running TCP only some weeks ago, but you don't get far that
way if you actually want to talk to authoritative servers. Quite a sizeable
percentage are UDP only.

TCP to your resolver is another story - might in fact even be wise.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: bert hubert <[email-masked]>
Date: Tue, 25 Mar 2008 22:37:03 +0100

Bert