Subject: a new wild card can of worms

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Feb 2005 11:31:57 -0500

Considering discussions on wildcards that have arisen in the context 
of "spam-reducing efforts involving the DNS" I think that perhaps 
something needs to be clarified in RFC 2782.

In RFC 2782 the SRV RR is defined.

# The format of the SRV RR
#
#    Here is the format of the SRV RR, whose DNS type code is 33:
#
#         _Service._Proto.Name TTL Class SRV Priority Weight Port Target

Note that the owner name is "_Service._Proto.Name"

Later this appears:

#   Name
#         The domain this RR refers to.  The SRV RR is unique in that the
#         name one searches for is not this name; the example near the end
#         shows this clearly.

Admittedly, the example referred to:

#   In this example, a client of the "foobar" service in the
#   "example.com." domain needs an SRV lookup of
#   "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
#   box.example.com." and/or the other hosts named.  The size of the SRV
#   reply is approximately 365 bytes:

is correct and should clear things up, but still some folks have come 
to believe that "_foobar._tcp.*.example." would cover the foobar 
service over TCP on all unlisted "hosts."

IMHO, the start of the confusion  it the mixing of what the SRV 
document calls a "Name" and the use of domain names in wildcards. 
I'm thinking this as I re-edit text on (empty) non-terminal wildcards.

Should I try to add a "Wildcards and SRV" record section?  (As in the 
Wildcards and NS, CNAME, etc., that are already in the draft.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield

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

---

From: Alex Bligh <[email-masked]>
Date: Mon, 07 Feb 2005 17:06:57 +0000

>#         name one searches for is not this name; the example near the end

Is the ambiguity you are referring to the confusion between "Name" (capital
'n') and the two uses of "name" in the 2nd line? Or the fact that that
what is searched for is a QNAME not a "name" (whatever that means here)
and that cannot contain wildcards? Or the that it is unclear whether
wildcard-clarify's prescriptions apply to the "name one searches for",
it's corresponding RR in the zonefile, or "this name"?

The definition itself seems to be self-referential to me: "The domain this
RR refers to" does not seem right - the RR *refers* to the entire
concatenation of labels doesn't it (i.e. the RR *is* _Service._Proto.Name)?
Surely this is in fact "the label(s) to which the _Service and _Proto are
prepended by the resolver to generate a QNAME to perform a search" or
similar.

Alex

---

From: John Levine <[email-masked]>
Date: 7 Feb 2005 17:21:43 -0000

>service over TCP on all unlisted "hosts."

I don't know anyone in the non-loony anti-spam community who thinks
that x.*.y matches anything other than x.*.y, but I don't see any
reason that a sentence or two reminding people that SRV prefixes don't
change the wildcard rules would hurt.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: Peter Koch <[email-masked]>
Date: Mon, 07 Feb 2005 18:28:48 +0100

> service over TCP on all unlisted "hosts."

yes, but not necessarily due to an ambiguity in 2782.

> document calls a "Name" and the use of domain names in wildcards. 

RFC 2782 combines the syntax definition of the SRV RR type with the definition
of a very particular use case. That's why the owner name is given structured
with "Name" being only one component.

> Wildcards and NS, CNAME, etc., that are already in the draft.)

Extending the query space by prefixes was probably introduced by SRV RRs
but is not restricted to those. So, the pecularities of 'wildcards and SRV'
do not arise from the RR type but from the particular use of the namespace
it kind of induces. Now, hopefully you manage to explain this to the target
audience better than I did.

-Peter

PS: And please don't forget the hint that *.example.com doesn't really
    match "everything" below "example.com" :-)

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Feb 2005 13:29:16 -0500

>it's corresponding RR in the zonefile, or "this name"?

Definitely yes to the first option.  Basically, "Name" in caps != the 
QNAME, whether or not any asterisk label or wildcard is in play.

What I would add in a section on SRV's and wildcards would be 
something along the lines that the "matched portion of the name is 
the service-protocol-*N*ame, not just *N*ame."

E.g.
          *.example.               TXT  "blah"
          _foobar._tcp.*.example.  TXT  "blah blah"

   QNAME = "_foobar._tcp.host1.example.", QTYPE=TXT (ignore QCLASS)

    The rdata returned is "blah".  (Not the other.)

>prepended by the resolver to generate a QNAME to perform a search" or

I guess the misunderstanding is what you mean by "prepended by the 
resolver."  IMHO, a DNS protocol element ought not change the name 
being looked up.  However, the shim layer between the GUI and the DNS 
protocol element is allowed to make the transformation.

By "resolver" above, do you mean the code that is specific to an 
application or specific to the DNS?  Maybe perhaps specific to a 
middleware-like shim.

Hmmm.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Feb 2005 13:40:19 -0500

>of a very particular use case. That's why the owner name is given structured

I think you've pointed out something important...mixing use case with 
definition.  (Like the WhoIs "spec" rewrite.)

>     match "everything" below "example.com" :-)

Had to think about that one. Again. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Alex Bligh <[email-masked]>
Date: Mon, 07 Feb 2005 18:45:13 +0000

--On 07 February 2005 13:29 -0500 Edward Lewis <[email-masked]> wrote:

>> The definition itself seems to be self-referential to me: "The domain
>> this RR refers to" does not seem right - the RR *refers* to the entire
>> concatenation of labels doesn't it (i.e. the RR *is*
>> _Service._Proto.Name)? Surely this is in fact "the label(s) to which the
>> _Service and _Proto are prepended by the resolver to generate a QNAME to
>> perform a search" or similar.
>
> resolver."  IMHO, a DNS protocol element ought not change the name being
> looked up.  However, the shim layer between the GUI and the DNS protocol
> element is allowed to make the transformation.
>

I meant they are prepended by the (waves hands) "thing doing the
resolving" i.e. before it gets to wire protocol. That could either
be the application, a shim layer, or the low level resolver library
(I don't think there is any reason why a resolver library might not
do the concatenation itself and have a function like
  int getsrvrecord(char * name, char * service, char * proto,
                   struct srvrecord * data );
and in fact for all I know libresolv might have just that - too lazy
to look).

Alex

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Feb 2005 13:48:50 -0500

>and in fact for all I know libresolv might have just that - too lazy

Ahh, good point there.

I suppose it's not so important whether the thing that takes a *N*ame 
and makes a QNAME is a "DNS element" so much as it's important that 
what appears on the wire is the QNAME and, even more so, that the 
server answering the query does not do the *N*ame to QNAME conversion.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar