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

2. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt2 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

3. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt3 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

4. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt4 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)

5. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt5 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

6. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt6 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...

7. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt7 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...

8. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt8 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...

9. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt9 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

10. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt10 * 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

11. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt11 * 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"?

12. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt12 * IN 900 DNAME blah DNAME (specification) has problems Nothing special in the wild card case Can essentially treat DNAME as a CNAME generator

13. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt13 * IN 900 SOA........ Don't think this needs discussion Anyone else?

14. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt14 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

15. 15 July 2003draft-ietf-dnsext-wcard-clarify-00.txt15 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