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

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

I'm not going to engage in a philosophical debate on a list that is
chartered to explore technical issues and solutions.  That debate is taking
place elsewhere.  Having said that and snipping through the non-technical
comments:

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

You first said "subsequent documents make a pretty convincing case that it
should not be implemented arbitrarily in well established TLDs".  Please,
provide specific references to support your statement.

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

By adopting a practice that wildcard RRs in TLD zones don't share addresses
with other RRs.  It can't be enforced, though, and so that's why I asked
about a protocol change being a better long-term solution.

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

I am taking a long-term view of this and I'm not referring to anyone's
business practices.  We have a statement from the IAB that wildcards are a
valid part of the DNS protocol.  We have statements from many people that
wildcards as-specified in the DNS protocol can cause problems.  The IETF has
ways to deal with specification issues and I think it appropriate to see
what (if anything) might need to be done to address any specification
deficiencies that might exist.  If a long-term solution is the only
solution, then that's good information.

-Scott-