Subject: wildcards draft

From: Alexis Yushin <[email-masked]>
Date: Tue, 18 Feb 2003 23:05:40 +0100 (CET)

Hi,

I dont like the wildcard clarification draft, what I'm saying is that I dont
like the idea of existance of non-existing or better put non-explicitly-configured
domains. It is quite non intuitive.

What's the main driver behing this clarification draft? NXT processing? Certain
implementation shortcomings?

Alexis

--
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: Alexis Yushin <[email-masked]>
Date: Wed, 19 Feb 2003 11:25:07 +0100 (CET)

Edward,

Intuitively I would expect a NXDOMAIN (in BIND language) for a domain
that I did not explicitly configure and that doesnt have any resource
data associated with it.

*.test.		MX	100 mailhost.test.
a.b.c.test.	MX	100 office.test.

As a user, the expected outcome of the above example would be to
route all the mail for *.test to mailhost.test with the exception
of a.b.c.test that'd go to office.test.

Before reading your draft I wouldnt have realized that I need to
put *.a.b.c.test, *.b.c.test and *.c.test to achieve my goal.

In the above example I would treat a.b.c as a one node, consisting
of three labels. I have to read the 1034 once over again and I'll
come back on the topic :)

Everybody have a nice day!

Alexis

Once Edward Lewis wrote:
>At 23:05 +0100 2/18/03, Alexis Yushin wrote:
>>Hi,
>>
>I don't exactly understand the question.
>
>It's not what exists or doesn't exist in a protocol, the issue is 
>what response is generated by a query.
>
>In RFC 1034 there are three concepts regarding existence.
>
>Wild cards are tools for synthesizing answers.  Whether you want to 
>say the an answer synthesized from a wild card represents existence 
>or not, the fact remains that an answer is obtained for the query.
>
>RFC 1034 does define an authoritative name error for queries whose 
>QNAME is neither a leaf with data nor an interior node.  In this 
>case, if the node does not exist, a query against it results in an 
>authoritative name error (NXDOMAIN in BIND lingo).
>
>The third incidence of 'existence' is the impact on the algorithm in 
>4.3.2, section C.  Given the defintion in 3.1, it's quite clear that 
>empty non-terminals play a role in the execution of 4.3.2-c, hence 
>they 'exist'.
>
>(I exist, ergo I impact a response, or, if a domain name falls in the 
>forest...)
>
>Someone asked me to write up text on wild cards.  Apparently some 
>feel it is unclear from RFC 1034, I just reiterated what is in that 
>RFC.
>
>Perhaps my question is - do you think the wild card draft differs 
>from RFC 1034?  I don't intend it to, but if that is the impression 
>it gives, the draft is in error.
>
>>Alexis
>>
>>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                          +1-703-227-9854
>ARIN Research Engineer
>
>

---

From: [email-masked]
Date: Wed, 19 Feb 2003 22:23:32 +1100

> Everybody have a nice day!

	Alexis.  The DNS is a tree structure.

	"a.b.c.test. MX 100 office.test" implicitly creates the parent
	domains (nodes) b.c.test, c.test, test and the root node.

			(root)
			  |
			test
			  |
			  c
			  |
			  b
			  |
			  a
	
	Once you put the names into a tree structure what is "intuitive"
	changes.

	Also I suggest that you read RFC 1033 and RFC 1035.  They are
	designed to be read together with RFC 1034.

	DNSSEC order is a alternate way to look at the zone contents
	but it hides the tree structure (and empty nodes) which is
	fundemental to understanding DNS.

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