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: [email-masked]
Date: Wed, 19 Feb 2003 10:14:33 +1100

> implementation shortcomings?

	The main driving force is to demonstate that you only need
	a maximum of two NXT records to prove the non-existance of
	the qname.  One for the qname and potentially an additional one
	for the wildcard.

	People were saying that you need lots of NXT records which was
	just wrong. 

	Additionally it was counter intuitive returning NXDOMAIN
	for a name which clearly exist and RFC 1035 says should
	result in a NOERROR response.  It's also counter intuitive
	for a empty node to be used for wildcard processing but 
	to have it return NXDOMAIN.
	
	NXT processing can be done either way.  You just have to have
	agreement upon what is the correct RCODE for a empty node as
	the validator will reject the wrong RCODE.  DS is a major change
	and the validator needs to be re-written.

	DNSSEC should not change the basics of DNS.  It should be
	securing the DNS.  The wording in RFC 2535 could be interpreted
	to allow for both NOERROR and NXDOMAIN.

	Mark

	P.S. I've always though NXDOMAIN was wrong for the empty node
	case.

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Feb 2003 18:01:43 +0800

>domains. It is quite non intuitive.

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

>implementation shortcomings?

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

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

---

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