15 july 2003draft-ietf-dnsext-wcard-clarify-00.txt1 wildcard clarify...

15 July 2003 draft-ietf-dnsext-wcard-clarify-00.txt 1

Wildcard Clarify

draft-ietf-dnsext-wcard-clarify-00.txt


Outline (of Doc)

• 1 Introduction• 2 Defining the Wild Card Domain Name• 3 Defining Existence• 4 Impact of a Wild Card Domain In a Query Msg• 5 Impact of a Wild Card Domain On a Response• 6 Authenticated Denial and Wild Cards• 7 Analytical Proof ...• Apdx A: Subdomains of W C Domain Names


Since last time

• With "last time" = March/SF Meeting

• These have been done– Became a WG document– Addition of a proof to formalize the

notion/definition of the closest encloser


Proposal

• Split Document• Pre-DNSSEC and DNSSEC parts

– "NXT" appears just once in s1 (as reason for the work)

– "NXT" appears only in s6 and s7 besides that

• Therefore– 1-5 and Appendix A a clarification to RFC

1034– 6, 7 to NXT place (draft ? part of protocolbis)


Clarifying 1034 (Pre-DNSSEC)

• Existence statement already in document

• Impact of Wild Card domain name owning– CNAME– NS– DNAME– SOA

• Related to CNAME - change to 4.3.2.-3c


Requirements against 1034

• R2.1 A domain name ... MUST begin• R2.2 A server MUST treat a WC ...• R3.1 An authoritative server MUST treat a

domain name as existing ...• R3.2 An authoritative server MUST treat a

domain name that has neither ...• R4.1 A WC domain name acting as a QNAME ...• R4.2 A WC domain name appearing ... RDATA ...


DNSSEC part

• Rules for NXT's as part of authenticated denial as it relates to wild card

• Fix up the proof

• Add "recipe" resulting from proof

• Question - where/how will this text appear?– Is this a clarification or a change - that's the

question...


Req's against DNSSEC

• R6.1 ...authenticated denial MUST reveal...• R6.2 If a zone is signed...• R6.3 When synthesizing a positive answer...• R6.4 When synthesizing a negative answer...• R6.5 ...an authoritative name error, the answer...• R6.6 ...in which there is an exact match of the...• R6.7 A resolver MUST confirm ...• R6.8 A resolver MUST confirm ...• R6.9 A resolver MUST confirm ...


Existence

• 1034's words on existence are too vague (everything exists) yet defines a "name error" for non-existence

• Adjusted definition in new draft, previously discussed


* IN 900 CNAME blah

• According to 4.3.2, there is no problem, although most implementations do not follow specification

• A CNAME at a wcard ought to return the CNAME iff the CNAME was asked for

• So - no problem here, but we will revisit 4.3.2-3.c later because of this


* IN 900 NS blah

• MAY? SHOULD? MUST? reject zone on "load"– Suggestion seems to be "no" to all

• User confusion– Document why this doesn't work– Puts pressure on step 2 of algorithm

• Do * NS's make other data at * "glue"?


* IN 900 DNAME blah

• DNAME (specification) has problems

• Nothing special in the wild card case

• Can essentially treat DNAME as a CNAME generator


* IN 900 SOA .. .. ... .

• Don't think this needs discussion

• Anyone else?


Change to 4.3.2-3.c

• Says (basically) when a QNAME matches a '*', return the records that match QTYPE

• Does not say "if there's a CNAME, chase it" but apparently many implementations do

• Proposed change (to 1034) - add CNAME chasing to this step


Summary "Actions"

• Split• Existence (as written)• "* NS" add text to make it clear• Modify step 3.c of 4.3.2 (in 1034) to chase

CNAME's at WC match• Move other text to DNSSEC doc• Add "recipe" resulting from proof, edit proof

15 july 2003draft-ietf-dnsext-wcard-clarify-00.txt1 wildcard clarify...

Documents