RE: [sitefinder-tech-discuss] Technical issues encountered by a k 12 site

[Owen DeLong <owen@delong.com>]

--On Wednesday, October 8, 2003 14:35 -0400 "Hollenbeck, Scott" 
<shollenbeck@verisign.com> wrote:

> You didn't send your reply to the mailing list.  Was that a conscious
> decision on your part or an inadvertent omission?  I'm replying personally
> as a courtesy to you, but I'd prefer to continue the conversation on the
> list.
It was a conscious decision.

> > While the synthesized response capability is clearly outlined in the
> > original RFCs, subsequent documents make a pretty convincing
> > case that it
> > should not be implemented arbitrarily in well established
> > TLDs.  As such,
> > it is not an unreasonable expectation on the part of an application
> > programmer that this behavior will not abruptly change for
> > .NET and .COM.
>
> Documents such as?  Things written in the last three weeks don't count as
> they don't overcome 16 years of post-1034 inertia.  I spent a considerable
> amount of time researching IETF RFCs (including BCPs) before writing a
> document describing guidelines for deploying wildcards in TLD zones.  I
> didn't find anything close to what you're describing above.
How about:
	Be conservative in what you send and liberal in what you accept.

I don't know exactly where that originated, but, I know it has been quoted
a lot within IETF and other Internet operational contexts.

A document describing implementations is one thing.  Implementing without
warning on TLDs that have 16+ years of non-wildcarded behavioral inertia
is quite another.

ICANN certainly makes a pretty good argument that Verisign's contracts
and/or cooperative agreements under which it manages the .NET and .COM
zone files ON BEHALF of ICANN also contain such prohibitions.

Noone is arguing that what you did violates the RFCs.  However, I think
you are hard pressed to argue that wildcards in the .NET and .COM zone
files do not violate good operational practice.  I think you are even
harder pressed to make a case that modifying .NET and .COM zone files
in such a major way without prior notice to the affected community
and without any sort of operational review by that community violates
many tenants of good engineering and operational practice.

Can you really try to make a case that sweeping changes without notice
to the affected userbase are a good thing in the operation of a critical
infrastructure component?

> > I've written lots of code that accounts for the possibility
> > of synthesized
> > responses which still has unexpected limitations encountered when such
> > responses take over all of .COM or .NET.  Verisign still has
> > yet to convey
> > a good methodology for reliably determining that such a synthesized
> > response has been received, let alone give the developers
> > time to distribute
> > resolver libraries which can correctly disregard such a response.
>
> A mechanism is described on page 4 of this document:
>
> http://sitefinder.verisign.com/pdf/sitefinderdevguide.pdf
Except it doesn't completely work.

foo.	IN	SOA	...
$ORIGIN foo.

*	IN	A	192.168.1.1
*	IN	MX	10	bad.mail.host.com.

icky	IN	A	192.168.1.1
	IN	MX	10	bad.mail.host.com.

Now, I query for icky.foo and I get a result.  Then, I query for
gorp.foo, and get the same result.  Which one is the wild-card
synthesized response, and, how do I tell?


> You didn't answer the question about whether or not a DNS protocol change
> would be helpful.
Changing the internet to accommodate Verisign's desire to make money is,
IMHO, not the correct answer.  Yes, a DNS protocol change could eventually
allow a workaround to this issue, and, may be useful on it's own merits
(adding an IsWildCard? flag to the response packet, for example).  However,
doing so would have to go through the full IETF process, and, then, there
would need to be a delay while implementers built and tested code that
supported such features.  Other ramifications and operational concerns
would have to be examined.  This would be a lengthy process, and, certainly
doesn't mitigate Verisign simply implementing such a change today or
any time in the foreseeable future.


Since you want this back on the list, I've added the list back in.

Owen