Subject: Deployment of standards compliant nameservers

From: Mark Andrews <[email-masked]>
Date: Tue, 21 May 2013 10:26:39 +1000

I call upon the IESG to discuss with IANA, the RIRs, ICANN
and TLD operators how to deal with the problems caused by the
deployment of non standards compliant nameservers.

	For a long time there have been operational problems
cause by the deployment of non standards compliant nameservers that
fail to respond to DNS queries directed at them or respond incorrectly.

	The biggest problem with respect to deployment of new
types is nameservers that fail to respond to types they don't
understand.  RFC 1034 allows for several different responses:

* name error
* no error no data
* not implemented
* refused
* formerr

"Name error" and "no error no data" are the expected responses for
queries with unknown types.  This is reinforced by RFC 3597.  But
any of the other responses is acceptable.  Failure to respond however
is not acceptable.  It introduces systematic timeouts which are
indistinguishable from network errors without extended analysis of
query response behaviour.

While the percentage of nameservers misbehaving like this are
relatively small they have a disproportionate effect on protocol
development.  They are also easily identifiable when looked for by
querying for a know type at a name that is know to exist, the zone
apex, that is supported by virtually all nameservers (e.g. A) and
querying for a random unallocated type, then querying again for the
original type.  If you get a answer, no response, answer then the
nameserver in question almost certainly has this issue and you are
not looking at a dead server or network congestion issue.

I'm not sure what the solution should be but regular audits of
delegated nameservers by infrastructure operator and removal of
delegations after a grace period to correct the faulty nameserver
and checking of nameserver behaviour at registration time would go
a long way to addressing the problem.

Removal of the delegation is one of the suggested remediations
identified in RFC 1034 for nameservers that are causing operational
problems.  It is not the first step by it is a step in the process.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: manning bill <[email-masked]>
Date: Mon, 20 May 2013 17:37:48 -0700

I believe that there are a couple of problems with this plea…

1) - The IETF has -never- tested for or assured compliance with their document series.
2) - The only DNS test suite I am aware of is the older TAHI test suite from http://www.tahi.org/ - which was focused on IPv6 development and is now closed.
3) - The full DNS standards fail to include the RFC 2026 language that would suggest mandatory capabilities.

So, while a nice idea, it is hardly practical from an IETF (or any top-down) perspective…

/bill

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 May 2013 11:23:17 +1000

In message <[email-masked]>, manning bill writes:
> I believe that there are a couple of problems with this plea.
>

Which has what to do with requesting that a known problem get fixed?
One that is clearly caused by nameservers operating outside the
expected behaviour of nameservers.

> 2) - The only DNS test suite I am aware of is the older TAHI test suite
> from http://www.tahi.org/ - which was focused on IPv6 development and is
> now closed.

Well I didn't ask for a complete compliance test to be run.  I ask for
a specific test for a known problematic issue to be run.

> would suggest mandatory capabilities.

And this has what to do with the issue?  Yes older RFCs don't all
use the formal language of RFC 2026.  That doesn't mean that the
intent was not clear or that one should not address operational
issues that arise.

> So, while a nice idea, it is hardly practical from an IETF (or any
> top-down) perspective.
>
> /bill
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 May 2013 18:41:16 -0700

> Which has what to do with requesting that a known problem get fixed?

One has to test for compliance in order to determine if the problem exists in a particular implementation.

> expected behaviour of nameservers.

No offense, but your view of "clearly" and "expected" have sometimes been at odds with other folks in the DNS protocol community. Your request that the IETF do conformance testing might first be based on assurance that the DNS protocol community agrees on those. After that, "someone" can probably do testing. And after that, "someone" might be able to get people to take action against non-conformant implementations.

--Paul Hoffman

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 May 2013 21:44:29 -0400

It seems like a first step might be to set up a web page and/or write up 
an I-D with

a) a description of the problem
b) documentation a procedure and/or code that can be used to test name 
server software for compliance
c) recommendations for zone operators that delegate to other zones

The next step might be for TLD operators to encourage the TLD registrars 
to (a) inform their customers of this issue, (b) test their customers' 
servers, and report the test results to their customers.   Ideally those 
registrars would be able to refer their customers to updated or improved 
servers.

Longer term it might be appropriate to do some other things, like
a) define standard tests for compliance
b) define a mechanism by which a server could be queried to find out its 
implementation name, version, etc.

Keith

p.s. I wonder if the problem you describe might at least partially be 
caused by DNS proxies and interception proxies, including but not 
limited to those incorporated in consumer-grade routers.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 May 2013 12:20:05 +1000

> exists in a particular implementation.

It doesn't have to be the IETF that does the testing.  In fact the
IETF doesn't have access to the list of servers that need to be
tested however the operators of the parent zones do.  Alternatively
it can be done on a piecemeal basis by examine logs and then looking
up whois entries and complaining that the nameservers are causing
operational problems to the operators,  the complaining to the
parent zone, then complaining to the courts when the parent zone
operators fail to take action as directed by RFC 1034.

> No offense, but your view of "clearly" and "expected" have sometimes been
> at odds with other folks in the DNS protocol community. Your request that
> the IETF do conformance testing might first be based on assurance that
> the DNS protocol community agrees on those. After that, "someone" can
> probably do testing. And after that, "someone" might be able to get
> people to take action against non-conformant implementations.

RFC 1034 describes how to answer a query.  It clearly states that new
query types are expected.

"However, the domain system is intentionally extensible.  Researchers are
continuously proposing, implementing and experimenting with new data
types, query types, classes, functions, etc.  Thus while the components
of the official protocol are expected to stay essentially unchanged and
operate as a production service, experimental behavior should always be
expected in extensions beyond the official protocol.  Experimental or
obsolete features are clearly marked in these RFCs, and such information
should be used with caution."

It also states how to constuct a response and it doesn't state
"only known types".

   3. Start matching down, label by label, in the zone.  The
      matching process can terminate several ways:

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

The DNS also has response codes to say that a nameserver doesn't
implement a part if the specification, that it don't want to answer
a particular query, that a internal error occured, that you don't
understand or can parse the query.  These response codes cover just
about any conceivable error condition.  It is a query/response
protocol and a response is expected except under exceptional
circumstances.

Mark

---

From: manning bill <[email-masked]>
Date: Mon, 20 May 2013 19:41:49 -0700

as mentioned earlier,  only -ONE- known, public DNS conformance test suite has existed
and it was shut down last year due to lack of use.

since you want the courts involved, you are making some significant presumptions about the
liability of adherence to voluntary standards.

dead issue … move on.  Or persuade Yokogawa Electric Corporation to spin the test suite back up.

/bill

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 May 2013 12:45:06 +1000

> registrars would be able to refer their customers to updated or improved 

Ack.
 
> limited to those incorporated in consumer-grade routers.

When the problems exist on the nameservers of Fortune 500 companies
nameservers it isn't consumer-grade routers.  It is badly designed
nameservers or their load distributing front ends.

This is similar to the name error issue a nameserver vendor had
when responding to unknown types (e.g. AAAA) in the past.  The BBC's
nameservers were a prime example at the time (now fixed).  They
returned name error for a existing name (www.bbc.co.uk from memory).

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 May 2013 16:03:01 +1000

Keith asked for a ID.

Filename:        draft-andrews-dns-no-response-issue
Revision:        00
Title:           A Common Operational Problem in DNS Servers - Failure To Respond.
Creation date:   2013-05-21
Group:           Individual Submission
Number of pages: 5
URL:             http://www.ietf.org/internet-drafts/draft-andrews-dns-no-response-issue-00.txt
Status:          http://datatracker.ietf.org/doc/draft-andrews-dns-no-response-issue
Htmlized:        http://tools.ietf.org/html/draft-andrews-dns-no-response-issue-00

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 May 2013 11:07:27 +0200

On Tue, May 21, 2013 at 10:26:39AM +1000,
 Mark Andrews <[email-masked]> wrote 
 a message of 52 lines which said:

> delegations after a grace period

Let's not reinvent the wheel: I suggest to first study the experience
of the TLD which did exactly that. .fr had mandatory technical tests
of the name servers almost from its inception, until december
2012. The tool used for the tests was Zonecheck
<http://www.zonecheck.fr/>

Although these tests certainly contributed to the good technical
quality of the name servers, they were removed both for commercial
reasons (a registry has to make money to pay its employees) and
because it was easier to have the same rules for ccTLDs and gTLDs (and
ICANN forbids these technical tests in gTLDs).

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 May 2013 22:37:35 +1000

> ICANN forbids these technical tests in gTLDs).

Which is one of the reasons I wanted to IESG to bring ICANN into
the discussions.  It need to be a level playing field applied to
everyone.  Not also this is not checking the delegation.  It is
checking to nameserver implementation.  All ICANN documents I have
read presume that a RFC compliant nameservers are being deployed.

Nameservers that fail to respond are not RFC compliant.

Mark

---

From: Ray Bellis <[email-masked]>
Date: Tue, 21 May 2013 16:03:40 +0000

On 21 May 2013, at 02:44, Keith Moore <[email-masked]> wrote:

> p.s. I wonder if the problem you describe might at least partially be caused by DNS proxies and interception proxies, including but not limited to those incorporated in consumer-grade routers.

Those are already addressed in RFC 5625.

kind regards,

Ray

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 21 May 2013 10:28:05 -0700

On Mon, May 20, 2013 at 6:44 PM, Keith Moore <[email-masked]>wrote:

> caused by DNS proxies and interception proxies, including but not limited
> to those incorporated in consumer-grade routers.
>
>
>
Given the funny things some firewalls used to do to SMTP sessions, I
suggest tossing firewalls into that list.

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 May 2013 08:10:28 -0400

--On Tuesday, May 21, 2013 11:07 +0200 Stephane Bortzmeyer
<[email-masked]> wrote:

>...
> Although these tests certainly contributed to the good
> technical quality of the name servers, they were removed both
> for commercial reasons (a registry has to make money to pay
> its employees) and because it was easier to have the same
> rules for ccTLDs and gTLDs (and ICANN forbids these technical
> tests in gTLDs).

Occasional fantasies about IETF enforcement power and the
Protocol Police notwithstanding, it seems to me that, if one
wanted to require standards-conforming nameservers, the most
(and maybe only) effective way to do that would be requirements
in the contractual agreements between TLD registries and their
registrants.  Recursively applying requirements down the tree is
not a new idea; RFC 1591 uses that language more than once.

If we believe that standards-compliance would improve Internet
stability and/or security (to say nothing of the predictability
of the user experience), then ICANN's forbidding registries from
imposing technical conformance requirements, if true, would seem
to violate their charter and bylaws.  Do you have any idea where
that restriction came from?   Or what Mark and others should do
to get it changed?
 
best,
   john

---

From: Yoav Nir <[email-masked]>
Date: Wed, 22 May 2013 12:29:58 +0000

> not a new idea; RFC 1591 uses that language more than once.

We should be careful about requiring things like this (for whatever value of "we"). Recursively applying requirements means that "we" are requiring service providers (in this case registries) to pick fights with their customers. So instead of having an IETF protocol police, "we" expect service providers to act as local sheriffs.

It's not that service providers would never do this. There is some success in getting ISPs to shut down spammers, but they are likely to cooperate when the actions of the offenders are likely to damage either the service provider's infrastructure, or harm other customers.  This is not the case here. A DNS server that ignores unknown record types does not hurt anyone who only queries for A and AAAA records. And MX. It hurts people who try to deploy new record types, so for now, it hurts experiments. It reduces the likelihood of a major browser deploying a version with DANE enabled by default.  This is definitely harm, but beating one bad server into compliance does not fix the problem. 

So "we" would be asking service providers to take a step with positive costs (periodically testing servers, contacting customers, threatening them, and following up), all to prevent a kind of harm that would only be prevented if all other registrars in the world (or at least a vast majority) would do the same. And if that harm was mitigated, and all the DNS servers in the world were fixed, hardly anyone would notice.

Seems like a tough sell to me.

Yoav

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 22 May 2013 08:56:41 -0400

Back when I worked at a service provider, we helped customers with their DNS configurations, Sendmail, usenet news (yes, it was a long time ago), and other services.  If they were new customers, we would help them with the setup or if something was broken we would look at the configuration, look at dig results, etc.  

Shouldn't we be at the point where the applications running DNS services can ensure configurations are correct?  Wouldn't it be more efficient to work with the implementations to provide configuration validation or have easier input screens?  It was fine in 1997 to call someone at you SP, but this does not scale even with lots of service providers.  While tying this to contracts seems like a good idea, that is out of our hands at the IETF.  If we went down the path of enforcement through contracts, I wouldn't view this as picking fights, but rather a proactive service to 'help' customers.  Having said that, I think if we can improve the applications that generate their DNS files, it would be more effective long term.  While some teams are technical enough to validate their own DNS, others prefer more full service applications.  

Maybe a review of existing applications would be helpful for the community?  I just see the following on Wikipedia:
http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software
and
http://en.wikipedia.org/wiki/DNS_management_software

How about adding a column for compliance to RFCs?  Or a description that makes people aware of configuration problems caused when using certain packages?  This may start with known problems and work arounds, but ultimately lead to fixes in the products with automatic configuration validation.  This may not be the job of the IETF, but there must be groups we can work with to accomplish things like this.

Just a thought...

Best regards,
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Yoav Nir [[email-masked]]
Sent: Wednesday, May 22, 2013 8:29 AM
To: John C Klensin
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: Deployment of standards compliant nameservers

Yoav

---

From: John C Klensin <[email-masked]>
Date: Wed, 22 May 2013 10:00:58 -0400

--On Wednesday, May 22, 2013 12:29 +0000 Yoav Nir
<[email-masked]> wrote:

>> (and maybe only) effective way to do that would be
>> requirements in the contractual agreements between TLD
>> registries and their registrants.  Recursively applying
>> requirements down the tree is not a new idea; RFC 1591 uses
>> that language more than once.
> 
> We should be careful about requiring things like this (for
> whatever value of "we"). Recursively applying requirements
> means that "we" are requiring service providers (in this case
> registries) to pick fights with their customers. So instead of
> having an IETF protocol police, "we" expect service providers
> to act as local sheriffs.
>...

Actually, I was thinking about something a little different (and
should have been more explicit).  

I wouldn't suggest trying to mandate anything top-down.  If
nothing else, ICANN's track record for being able to enforce its
mandates is very poor (and that is arguably a good thing).  On
the other, we talk a lot about reputations and the advantages of
end sites being able to base policies on them.   If whatever the
actual restrictions that, according to Stephane, forbid TLDs
from imposing "we require you to have a competent nameserver and
will test" were removed then, especially with the coming huge
increase in TLDs, it would make it possible for registries to
compete on the degree to which they wanted to offer assurances
of quality DNS servers and services in subsidiary zones.
Would-be registrants who didn't want to play would have the
option of finding TLDs who did not have those restrictions.
That would create a new opportunity for enhanced competition and
differentiation among TLDs (which ICANN presumably favors along
with favoring security and stability) and would create a basis
for some DNS server certification activities (and even a
business model for them).

No mandate from the top, just elimination of whatever
restrictions now prevent registries from insisting on quality
operations in registrants if they wanted to.

It wouldn't get us to "everyone has to run a conforming server"
--which I consider impossible as long as producing
non-conforming servers is legal with governments enforcing the
rules if servers don't conform (and I really don't think  we
want to go there)-- but it would at least give a resolver an
indication of where conforming ones were guarantees and what
responses or non-responses they couldn't trust.

    john

---

From: SM <[email-masked]>
Date: Wed, 22 May 2013 13:57:10 -0700

At 05:56 22-05-2013, Moriarty, Kathleen wrote:
>providers.  While tying this to contracts seems like a good idea, 
>that is out of our hands at the IETF.  If we went down the path of 
>enforcement through contracts, I wouldn't view this as picking 
>fights, but rather a proactive service to 'help' customers.  Having
>  said that, I think if we can improve the applications that 
> generate their DNS files, it would be more effective long 
> term.  While some teams are technical enough to validate their own 
> DNS, others prefer more full service applications.
>
>Maybe a review of existing applications would be helpful for the 
>community?  I just see the following on Wikipedia:
>How about adding a column for compliance to RFCs?  Or a description 
>that makes people

RFC 1035 is updated by 24 RFCs.  There are a few errata which has 
been filed.  The topic says "standards complaint".  Which standard(s) 
does that refer to?  I read "compliance to RFCs", which RFCs does the 
implementation have to comply with?

It has been mentioned [1] on this mailing list that:

   "But there was no energy to get the work done and the drafts languished
    for months without any changes.  It still seems a worthwhile project,
    but there is no evidence that we have a population interested enough
    to do the work."

If the IETF discusses about contracts the discussion will evolve into 
turf wars (an acrimonious dispute between rival groups over territory 
or a particular sphere of influence).  The interesting point in the 
message (quoted above) is about providing information so that people 
can assess what's good or bad.  In my opinion it's doable (note that 
I am leaving out a few minor details :-)).

>mandates is very poor (and that is arguably a good thing).  On

:-)

>of quality DNS servers and services in subsidiary zones.

Yes.  I gather that domain name are registered to advertise services 
and that these services rely on working nameservers.

I was reading the following [2] (the reader is cautioned against 
drawing hasty conclusions):

   "AFNIC (The sole registrar of .fr domains) does not follow the 
ICANN policies
    for name server queries."

Here's a gem:

   "Other registrars are fully able to query our name servers on TCP port 43
   (the ICANN required port)."

Nameservers hosting Icelandic domains (.IS domains) must comply with 
requirements [3].

More reading [4]:

   "The .DE registry has certain requirements for nameservers that 
can be applied
    to .DE domains. Some of those requirements are that the 
nameserver IP addresses
    must be in separate class C networks, and that the nameserver 
must provide SOA."

For .NL domains, the nameservers must comply with the registry 
requirements [5].

People put more effort and money in trademarking strings than making 
the strings work.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg79409.html
2. https://my.bluehost.com/cgi/help/536
3. http://www.isnic.is/en/host/req
4. http://www.namecheap.com/support/knowledgebase/article.aspx/294/
5. http://www.opensrs.com/docs/opensrsrwi/nl_dns_requirements.htm

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 May 2013 09:42:09 +1000

> implementation have to comply with?
 
RFC 1034 and RFC 1035 I've tried to capture the reason why I started
this thread in:
http://tools.ietf.org/html/draft-andrews-dns-no-response-issue-01

Basically nameservers are supposed to reply to queries directed at
them.  RFC 1034 and RFC 1035 have enough error codes that you
should be able to reply to every query sent to them.   You don't
have to return the data.  You don't even have to understand the
query.  You do have to respond.

So if the message is 12 octets or bigger and the QR bit is set to
1 you should be able to respond.  RFC 1034 and RFC 1035 have a
response code for *every* possible message you receive.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 May 2013 12:49:45 +1000

In message <[email-masked]>, John C Klensin writes:
> mandates is very poor (and that is arguably a good thing).

Asking people to run a nameserver which "responds" to queries isn't
unreasonable by any stretch of the imagination regardless of their
economic circumstances.  The nameservers that people used in the
1980's did this correctly.  The default nameservers on general
purpose OS as shipped for the last 2 decades have done this correctly.

This includes free and commercial operating systems.

The one exception I am aware of is a Windows release where the server
responds to the first EDNS query but not to subsequent EDNS queries.
This only becomes a issue when the first response is lost or multiple
recursive servers share the same IP address.  Microsoft has fixed
this issue in later releases.  I am not sure if there is a service
pack that fixes this.

Requiring vendors to supply fixes to code that was never "fit for
purpose" regardless of its age is also reasonable.

> On

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 23 May 2013 09:41:45 +0200

> Seems like a tough sell to me.

Not worse than BCP38 ;-) 

OTOH, I have _personally_ done this. I introduced and enforced and got set
into policy that name servers hosting domains under .SE should actually
have the domain set up and working before we (I was at the registry then,
performing transfers between DNS hosting providers and similar work,
all very manual and pre-web 1.0) transfered the domain delegation to
the new set of servers.

I got yelled at quite a lot, but a lot of domain name holders
approved. Mostly the anger was from lazy hosting companies that didn't
mind having their customers with flapping delegations for a week.

It can be done, it won't be popular, but the side effects are good. Mostly. 

Due to <some pressure from someone> this policy has been discontinued. I
am not responsible anymore.

OTTH, I think Marks proposal has some merit. I have a pretty good idea 
where this comes from, but I think that we -- mostly -- have the tools 
in 1591, and other documents. 

OTFH, this won't help until the people shelling out money and other
resources to build and run infrastructure start paying attention.
The grunt work to be made here is mostly about making certain people
know that they should request compliance with the actual standards and
not a subset conveniently fitting the preselected candidate.

It is unclear to me whether people who are not reading the present set
of standards will start reading and paying attention this time around.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I'm GLAD I remembered to XEROX all my UNDERSHIRTS!!

---

From: John C Klensin <[email-masked]>
Date: Thu, 23 May 2013 06:37:03 -0400

--On Thursday, May 23, 2013 12:49 +1000 Mark Andrews
<[email-masked]> wrote:

> Asking people to run a nameserver which "responds" to queries
> isn't unreasonable by any stretch of the imagination
> regardless of their economic circumstances.  The nameservers
> that people used in the 1980's did this correctly.  The
> default nameservers on general purpose OS as shipped for the
> last 2 decades have done this correctly.
>...
> Requiring vendors to supply fixes to code that was never "fit
> for purpose" regardless of its age is also reasonable.

Mark,

Once more and then I'm dropping out of this discussion.  You may
think "requiring... is reasonable".  I might even agree with you
and note that such a requirement, if applied to software across
the board and especially if "promptly" were inserted somewhere
in the sentence, would cure many of the world's ills, not just
this problem with the DNS.   As a examples that causes even more
visible damage than DNS non-responses, I'd be delighted if every
system and web site that rejects email local-parts with "+" in
them as invalid were "required" to fix those bugs or if every
spammer were "required" to stop doing anything that violates the
letter or spirit of applicable protocols or laws.

Where I have a problem is with "required", especially having the
IETF require it.  If you like, write up a draft for a BCP that
would specify eternal damnation to any vendor who gets this
wrong and doesn't release a patch within three months.  I
suspect that most of the objections to approval of such a
document would be about how it would make us look silly, not
about whether the vendors deserve it.   The difficulties are
that we have no enforcement power at all and that the very
nature of an open Internet and voluntary standards implies that
people can ignore the latter.    

I wish every vendor were better behaved but the only steps I can
see that would actually make progress on the problem you are
trying to solve are:

* Removing obstacles to requirements and enforcement where the
latter is really possible.  If there is an ICANN barrier to TLDs
requiring working nameservers for names that are delegated,
interpreting "working" as conforming, and enforcing that
requirement, removing it would probably be a good idea, as would
an SSAC statement encouraging the practice in the name of a
stable and secure Internet.  (As you probably know, there was a
time when the "show that you have working nameservers first"
rule that Måns mentioned for .SE was pretty much the norm for
TLDs.)  But that isn't an IETF problem and this isn't the right
place to discuss it unless you think our approving a document
that says "1035 says don't do this, you really, _really_
shouldn't do this" would accomplish anything other than raising
the stress level between ICANN and the IETF.

* Educational methods to raise vendor awareness of the problem
and that point out that it shouldn't be hard to fix.  If you
think flaming a few of them by name or other methods of
education would be appropriate, go to it.  As others have sort
of suggested, a few "these packages are broken and their vendors
are clueless and unresponsive" web pages might be interesting --
just see how well ones with similar intent have worked in
stopping spam. Just don't bother doing it here: I not seen a
single posting that disagrees with you about how the DNS is
supposed to work.   Few, if any, of the offending vendors are
reading this list and those that are and haven't already rushed
out to fix their products presumably don't care.

* In principle, if any ICANN barriers to voluntary TLD
enforcement were removed, large-deployment DNS software vendors
could follow the model that some web browser applications used
with IDNA: figure out what policies are appropriate for a good
user or operations experience and then arrange to deliver a
really bad experience to those who don't voluntarily comply. 

* Governments do have the ability to make rules and enforce
them.  I personally believe that legislating conformance to a
government's understanding of Internet protocols would work out
badly but, if you disagree, try it locally and let us know how
it works out.  I look forward to reading that Australia has
incarcerated (or, better yet, flogged) a vendor of DNS software
that doesn't conformed to your norms or someone who was
irresponsible enough to run such software.

But, otherwise, hyperbole about "require" is just that:
hyperbole.

   best,
    john

What is don't see is