1 / 17

wcard draft

This document provides clear definitions of wildcard labels, asterisk labels, and synthesis sources in DNS, with a focus on DNSSEC implications. It addresses changes to wildcard signing and discusses the impact on query responses, including NXDOMAIN errors and protocol considerations. Additionally, it examines the role of DS records in relation to NS records and explores inconsistencies in handling *.DNAME queries. The text outlines proposed revisions to RFCs and offers insights into resolving confusion around SRV records.

wcarlile
Download Presentation

wcard draft

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. wcard draft Ed Lewis, editor 62nd IETF March 9, 2005 ed.lewis@neustar.biz

  2. State of the Document • -05 is in the Internet Draft repository • Recent changes • Title (removed "Clarifications") • Lots of reorganization of text • Inclusion of DNSSEC vs. Wildcards • More work on special types (since -05) • Not ready for last call! ed.lewis@neustar.biz

  3. What's (Still) Important • Clears up definition of "wildcard" • Defines "asterisk label", "wild card domain name", "closest encloser", and "source of synthesis" • Cleans up text in RFC 1034 and others • Changes "* CNAME" • Will be in -06: changes to signing (!!!) ed.lewis@neustar.biz

  4. Oh my! Changes to signing? • And more... • Discussed on Monday here - New rule: • If a wild card domain name owns EITHER an NS RRSet OR a DNAME RRSet • It is NEVER a source of synthesis • Queries return NXDOMAIN • The RRSIG label count treats the records as non-wildcards ed.lewis@neustar.biz

  5. Normal Example $ORIGIN example. @ SOA … NS … … * TXT "this is a wildcard" ... ed.lewis@neustar.biz

  6. NS Example $ORIGIN example. @ SOA … NS … … * NS ... * DS ... ... ed.lewis@neustar.biz

  7. "* NS" • Legal because you can have a zone with an asterisk label in the name • www.*.example. "works" • Synthesis is cancelled by the zone boundary • Regardless of QTYPE (NS, ANY, DS, ....) • Message return code = name error • Became a protocol problem with DNSSEC, as opposed to operational annoyance ed.lewis@neustar.biz

  8. E.x., QNAME, QTYPE • QNAME=a.example. QTYPE=NS • assume no "a.example." in zone • Answer is NXDOMAIN • Even though you "might" have thought it would be an expansion of *.example ed.lewis@neustar.biz

  9. Canceling Synthesis • c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a the "*" label exists AND DOES NOT OWN AN NS RRSET NOR A DNAME RRSET. • Treat a * NS (or * DNAME) as "not there." ed.lewis@neustar.biz

  10. Why NXDOMAIN? • NXDOMAIN or No Error/No Data • Both are negative, both have same user experience • NXDOMAIN will let caches retain this "failure" (NCACHE) • This is why NXDOMAIN won the debate ed.lewis@neustar.biz

  11. What about the DS in the ex.? • DS can not be there without NS • DS and NS - the DS is not synthesized either, NXDOMAIN is also returned ed.lewis@neustar.biz

  12. DNAME Example $ORIGIN example. @ SOA … NS … … * DNAME ... * TXT ... ... ed.lewis@neustar.biz

  13. * DNAME • Problem lays in inconsistency of how queries are made and what happens at a cache • IMHO, possibly at most one person in the world really understands this (and it isn't me) • Treat this just like * NS... ed.lewis@neustar.biz

  14. So what about signing? • RFC TBD (-protocols), section 3.1.3 • "The value of the Labels field MUST NOT count ... the wildcard label (if present). .... For example, ... "*.example.com." has a Labels field value of 2...." ed.lewis@neustar.biz

  15. Change to that text • Maybe not literal - but the "*" is no longer ALWAYS a wildcard label. • We could say the definition is "correct" but the example is then misleading • Either way, this will be documented ed.lewis@neustar.biz

  16. Other changes • Blurb on SRV record • Prompted by confusion over "Name" and domain name in that RFC • This has surfaced recently in the IETF ed.lewis@neustar.biz

  17. Answers? • Anyone have some (more)? ed.lewis@neustar.biz

More Related