1 / 15

Wildcard Clarify

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

theta
Download Presentation

Wildcard Clarify

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Wildcard Clarify draft-ietf-dnsext-wcard-clarify-00.txt draft-ietf-dnsext-wcard-clarify-00.txt

  2. 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 draft-ietf-dnsext-wcard-clarify-00.txt

  3. 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 draft-ietf-dnsext-wcard-clarify-00.txt

  4. 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) draft-ietf-dnsext-wcard-clarify-00.txt

  5. 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 draft-ietf-dnsext-wcard-clarify-00.txt

  6. 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 ... draft-ietf-dnsext-wcard-clarify-00.txt

  7. 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... draft-ietf-dnsext-wcard-clarify-00.txt

  8. 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 ... draft-ietf-dnsext-wcard-clarify-00.txt

  9. 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 draft-ietf-dnsext-wcard-clarify-00.txt

  10. * 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 draft-ietf-dnsext-wcard-clarify-00.txt

  11. * 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"? draft-ietf-dnsext-wcard-clarify-00.txt

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

  13. * IN 900 SOA .. .. ... . • Don't think this needs discussion • Anyone else? draft-ietf-dnsext-wcard-clarify-00.txt

  14. 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 draft-ietf-dnsext-wcard-clarify-00.txt

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

More Related