Subject: RE: Weird Wildcards Work item (on wildcards vs RR types, was Fau x wildcards)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 3 Mar 2005 12:43:00 -0800

Some folk could not read the pdf through a non-adobe reader.

Here it is in HTML.

> -----Original Message-----
> From: Hallam-Baker, Phillip 
> Sent: Thursday, March 03, 2005 2:05 PM
> To: 'David Blacka'; [email-masked]
> Subject: RE: Weird Wildcards Work item (on wildcards vs RR 
> types, was Faux wildcards)
> 
> 
> It might simplify the second issue somewhat if people 
> consider why people want wildcard SRV. They want to express 
> policy statements such as 'every email whose source DNS zone 
> matches the lexical expression *.verisign.com is signed'. 
> 
> 
> Having considered this problem at some length for a non-IETF 
> WG I think that there is a mechanism that would allow us to 
> achieve the same effect as an SRV wildcard without the need 
> to mess arround with DNS.
> 
> The basic idea is to introduce a pointer record that does not 
> require a prefix and hence works with the existing wildcard 
> scheme. We then define a lookup algorithm that says 'first 
> look for the prefixed SRV, if that is not found look for the 
> pointer, if that exists follow it and look for the prefixed 
> SRV there, otherwise return not found'. The algorithm 
> terminates with a maxium of three lookups.
> 
> The introduction of a 'weird wildcard' that provides the 
> expected semantics of * to administrator is also useful, this 
> can be achieved by means of macro-preprocessing if necessary.
> 
> 
> The attached file provides additional info and considers the 
> alternative options.
> 
> With respect to the Area Directors comments on the subject of 
> 'instant gratification' in the W3C call, yes I do want 
> instant gratification and I see no reason to have to 
> appologise for doing so. I am dealling with a problem of 
> Internet crime that is currently costing $500 million a year 
> and is likely to rise to $5 billion. I believe that the 
> architecture that I have proposed is just as well founded and 
> considerably better justified than alternatives that 
> introduce significant delays and deployment risk.
> 
> 
> This morning a major bank in Indonesia turned off their 
> online banking service. 
> 
> https://www.bankbii.com/information.asp
> 
> 
> I am entirely willing to accept an alternative proposal that 
> also achieves instant gratification. A proposal that does not 
> provide instant gratification does not meet my needs.
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of David Blacka
> > Sent: Friday, January 21, 2005 12:12 PM
> > To: [email-masked]
> > Subject: Re: Weird Wildcards Work item (on wildcards vs RR 
> > types, was Faux wildcards)
> > 
> > 
> > Ólafur Gudmundsson/DNSEXT co-chair wrote:
> > > 
> > > There seems to be in some peoples mind  a "need" for
> > mechanism to do a
> > > wild-card "like" thing.
> > > 
> > > Without having clear requirements and usage examples it is hard to
> > > judge
> > > what
> > > is wanted by the different people that have posted on the "Faux 
> > > wildcards" and
> > > "wildcards vs RR types" topic.  On the other hand we think 
> > that, given
> > > that we
> > > have been going in circles, continuing on list will not
> > lead us anywhere.
> > 
> > While I'm not personally invested in a new wildcard
> > mechanism, I would like to attempt to contribute to the 
> > discussion of what the issues are at the risk of restating 
> > the obvious.
> > 
> > It seems to me that when non-experts look at wildcards they
> > come to one of two conclusions:
> > 
> > 1. Wildcards don't match enough.
> > 
> > 2. Wildcards match too much.
> > 
> > 
> > Don't match enough:
> > 
> > My experience has generally shown that when a naive user is
> > introduced to wildcards, they generally expect the wildcards 
> > to apply in more situations than they actually do, leading to 
> > long-standing common errors (c.f. RFC 1034, section 4.3.3).  
> > The classic wildcard MX:
> > 
> >    $ORIGIN example.com
> >    *     IN MX  10 a
> >    a     IN A   1.2.3.4
> >    b     IN A   1.2.3.5
> >    mail  IN MX  b
> > 
> > The naive user generally expects the wildcard to match 
> <c.example.com,
> > MX> (which it will), <a.example.com, MX> (which it won't), and
> > possibly even <b.a.example.com, MX>, but not <mail.example.com, MX>.
> > 
> > That is, a possibly more natural interpretation of the 
> wildcard is one
> > of: this is the default MX record for the zone, use it when
> > no other MX in the zone applies.
> > 
> > 
> > Match too much:
> > 
> > This typically comes up when folks struggle with wildcards
> > interacting with DNS records that use so-called "name hacks", 
> > like the SRV.  "Why can't I have a wildcard SRV?", they ask.  
> > Why cannot a DNS server exhibit a great deal of control over 
> > how a wildcard matches?  So we see proposals that look like:
> > 
> >    _http._tcp.*.example.com. IN SRV ....
> > 
> > where the expected behavior is that
> > <_http._tcp.foo.example.com, SRV> matches, but 
> > <bar.example.com., SRV> does not, and 
> > <_smtp._tcp.foo.example.com., SRV> certainly does not.
> > 
> > The limits of how much control this wildcard mechanism should
> > have are not typically well explored by such proposals.  
> > However, the example above might be considered a lower bound 
> > of control.  An upper bound might be to use regular 
> > expressions as wildcard matching rules. (Not that regular 
> > expressions represent a real upper limit -- any arbitrarily 
> > complex language could be defined).
> > 
> > While I personally cannot think of many interesting uses for
> > an expressive (say regular expression-based) selectively 
> > matching wildcard, my gut feeling is that there would be.
> > 
> > I do not necessarily think that there is a call for multiple
> > new wildcard mechanisms.  The first issue (match too little) 
> > could be handled by a zone pre-processor (by which I mean 
> > that the desired semantics are *expressible* using current 
> > DNS, but just verbose), and/or a single new mechanism could 
> > encompass both behavioral issues.
> > 
> > -- 
> > David Blacka    <[email-masked]>
> > Sr. Engineer    VeriSign Applied Research
> > 
> > --
> > to unsubscribe send a message to
> > [email-masked] with the word 'unsubscribe' 
> > in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/namedroppers/>
> > 
>