idnits 2.17.1 draft-eastlake-card-map-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 17 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 163 has weird spacing: '...irlines and o...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1999) is 9053 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ISO 7812' is mentioned on line 419, but not defined == Missing Reference: 'ISO 7816' is mentioned on line 428, but not defined == Unused Reference: 'RFC 1034' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC 2535' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'SET-EIG' is defined on line 529, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 3166' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 7812-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 7816-5' ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' -- Possible downref: Non-RFC (?) normative reference: ref. 'SET-EIG' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Motorola 3 Expires January 2001 July 1999 5 ISO 7812/7816 Numbers and the Domain Name System (DNS) 6 --- --------- ------- --- --- ------ ---- ------ ----- 7 9 Donald E. Eastlake 3rd 11 Status of This Document 13 This draft is intended to be become an Informational RFC. 14 Distribution of this document is unlimited. Comments should be sent 15 to the author. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 There are a variety of servers, web pages, and the like, which 38 holders of ISO 7812 financial transaction identification card (i.e., 39 credit/debit card) numbers and ISO 7816 smart card or related numbers 40 may need to locate on the Internet. For example, some systems assume 41 a smart card holder can contact the issuer of a smart card 42 application for maintenance and update functions and the payment 43 protocols may assume that a card holder can locate the appropriate 44 certification authority to obtain a card holder certificate. This 45 document specifies a method using the DNS as an important element in 46 locating card related facilities on the Internet by mapping ISO 7812 47 and ISO 7816 number systems into domain names within in the 48 card.reg.int domain. 50 Disclaimer 52 The methods proposed herein have not been endorsed by the issuers and 53 registries of ISO 7812 and 7816 numbers. 55 Acknowledgment 57 Suggestions from the following persons, listed in alphabetic order, 58 have been incorporated in this document and are gratefully 59 acknowledged: 61 Doug Beattie, Electronic Commerce Consultants 63 Dave Burdett, Commerce One 65 Brian Carpenter, IBM 67 Robert Elz, University of Melbourne 69 Tony Lewis, VISA International 71 Table of Contents 73 Status of This Document ...................................1 75 Abstract...................................................2 76 Disclaimer ................................................2 77 Acknowledgment ............................................2 79 Table of Contents..........................................3 81 1. Introduction............................................4 82 1.1 ISO 7812 Details ......................................4 83 1.2 ISO 7816 Details ......................................5 84 1.2.1 ISO 7816 '0'-'9' Prefixes ...........................6 85 1.2.2 ISO 7816 'A' Prefixes ...............................6 86 1.2.3 ISO 7816 'D' Prefixes ...............................7 87 1.2.4 ISO 7816 'B', 'C', and 'E' Prefixes .................7 88 1.2.5 ISO 7816 'F' Prefixes ...............................7 90 2. Inverse Number Mapping and Wildcards....................8 92 3. Card Domain Names Specified.............................9 93 3.1 ISO 7812 Card Brand, Issuer, and Acquirer Pointers ....9 94 3.2 ISO 7812 Acquirer Facilities .........................10 95 3.3 ICON Location ........................................10 96 3.4 Similar Proprietary Systems ..........................11 97 3.5 ISO 7816 Application IDs .............................11 98 4. Financial Institutions Not On Line ....................11 99 5. ISO 7812 BIN Ambiguity ................................11 100 6. Security Considerations ...............................12 102 References................................................13 104 Author's Address..........................................14 105 Expiration and File Name .................................14 107 Appendix: Initial ISO 7812 Brand Pointers.................15 109 1. Introduction 111 Financial transaction cards such as credit and debit cards are 112 identified by numbers issued in conjunction with ISO standard 7812 113 [ISO 7812-1] and applications that run on ISO smart cards are 114 identified by numbers issued in conjunction with ISO standard 7816 115 [ISO 7816-5]. In general, the leading digits of such numbers indicate 116 the category and/or issuing institution and the remainder of the 117 number provides further identification. 119 There has been no way, given such a number, to automatically find an 120 Internet site related to the card issuer, the card brand, or other 121 card facilities. Some operations in connections with smart card 122 resident applications, such as resetting certain error conditions on 123 a stored value card, may require contacting the issuer. Other 124 protocols may require that other facilities based on card number be 125 reached over the Internet. 127 A means of automatically mapping such identification numbers into 128 domain names means that as soon as a number is known (due to user 129 smart card insertion, the reading of a magnetic stripe, or user 130 selection from a list of previous entered credit cards, for example), 131 the ability would be present to easily attempt to contact facilities 132 on the Internet for that number. Thus web browsers/wallets could 133 provide "go to issuer", "go to brand", "get a certificate", etc., 134 buttons whenever an IS0 7812/7816 identification number is known. 136 1.1 ISO 7812 Details 138 Under ISO 7812, card numbers are decimal and the first 6 digits are 139 formally known as the Issuer Identification Number or IIN. This six 140 digit prefix is sometimes referred to as the BIN (Bank Identification 141 Number), although it applies to more than banks, and the entire 142 number is sometimes known as the PAN (Primary Account Number), even 143 though these numbers are also used for secondary accounts, Merchant 144 accounts, and other account and identification numbers. Card numbers 145 are frequently issued in connection with "brands" such as VISA, 146 MasterCard, American Express, JCB, Discover, Dinners Club, Air Travel 147 Card, etc. 149 Formally, ISO 7812 identification card numbers are divided as 150 follows: 152 1 2-6 7-> last 153 +-----+-------------------+-----------+-------------+ 154 | MII | issuer identifier | | | 155 +-----+-------------------+ account # | check digit | 156 | issuer identification # | | | 157 +-------------------------+-----------+-------------+ 158 | ISO 7812 identification number | 159 +---------------------------------------------------+ 160 MII = Major Industry Identifier as follows 161 0 - for ISO/TC 68 and other industry assignments 162 1 - airlines 163 2 - airlines and other industry assignments 164 3 - travel and entertainment 165 4/5 - banking/financial 166 6 - merchandizing and banking 167 7 - petroleum 168 8 - telecommunications and other industry assignments 169 9 - for national assignment 171 If the number starts with 9, the next three digits are the numeric 172 country code as defined in [ISO 3166] and the remainder of the number 173 is as defined by that national standards body for that country. 175 Account numbers are variable length up to a maximum of 12 digits so 176 the maximum total length is 19 bytes. 178 The check digit is calculated modulo 10 by the Luhn formula over all 179 the preceding digits as specified in [ISO 7812]. 181 The global registration agency for [ISO 7812] Issuer Identification 182 Numbers is the American Bankers Association (www.aba.com) but 183 application for an IIN must generally be made through a national 184 standards body. 186 1.2 ISO 7816 Details 188 ISO smart cards have applications on them each identified by a 189 hexadecimal Application Identifier (AID) BCD encoded into a maximum 190 of 16 bytes. In the past, most such cards have had a single 191 application but multiapplication cards are expected to be more common 192 in the future. 194 The first hex digit of the AID indicates the type of AID prefix as 195 listed below followed by details on each type. In general, the AID 196 prefix is followed a variable length "Proprietary application 197 identification extension" (PIX) under the control of the issuer 198 identified by the prefix. 200 0-9 An ISO 7812 IIN. 201 A International registration. 202 B-C Reserved for ISO. 203 D National registration. 204 E Reserved for ISO. 205 F Proprietary non-registered 207 1.2.1 ISO 7816 '0'-'9' Prefixes 209 AIDs with a prefix of '0' through '9' use ISO 7812 IINs for the 210 prefix (see section 1.1 above). 212 +-------------------------+--------+----------------------------+ 213 | ISO 7812 | | Proprietary application | 214 | issuer identification # | 'FF' | identifier extension (PIX) | 215 +-------------------------+--------+----------------------------+ 216 | Application identifier (AID), 2-16 bytes | 217 +---------------------------------------------------------------+ 219 [ISO 7816] is designed to be independent of IIN length and specifies 220 that if the IIN length is odd, it should be padded up the next full 221 byte by suffixing a hex 'F' nibble. 223 1.2.2 ISO 7816 'A' Prefixes 225 In AIDs with a prefix of 'A' (i.e., binary 1010), the prefix is 226 followed by 36 bits of Registry provider number as 9 BCD digits. 227 Values in these 9 nibbles that do not corresponding to a decimal 228 digits are reserved for ISO. 230 +---------------------------------------------------------+ 231 | Registered Application | Proprietary application | 232 | provider identifier (RID) | identifier extension (PIX) | 233 | 5 bytes | <= 11 bytes | 234 +---------------------------------------------------------+ 235 | Application identifier (AID), 1-16 bytes | 236 +---------------------------------------------------------+ 238 The registration authority for RIDs is 240 Tele Denmark (www.teledanmark.dk> 241 Attn: ISO/IEC 7816-5 Registration Authority 242 Teglholmsgade 1 243 1790 Copenhagen V 244 Denmark 246 1.2.3 ISO 7816 'D' Prefixes 248 The RID consists of the 4 bit D prefix (binary 1101), the country 249 code in 12 bits as 3 BCD digits coded according to the numeric 250 country codes in [ISO 3166], and 24 additional bits as specified by 251 the national standards body with BCD coding recommended. 253 +---------------------------------------------------------+ 254 | Registered Application | Proprietary application | 255 | provider identifier (RID) | identifier extension (PIX) | 256 | 5 bytes | <= 11 bytes | 257 +---------------------------------------------------------+ 258 | Application identifier (AID), 1-16 bytes | 259 +---------------------------------------------------------+ 261 1.2.4 ISO 7816 'B', 'C', and 'E' Prefixes 263 Prefixes 'B', 'C', and 'E' are reserved for future use by ISO and not 264 further specified. 266 1.2.5 ISO 7816 'F' Prefixes 268 Prefix 'F' indicates a proprietary non-registered AID. Because of 269 this, the same 'F' prefixed AID could be used by different 270 application providers for different applications. 272 +------------------------------------------------------+ 273 | Application Label | 274 +------------------------------------------------------+ 275 | Proprietary application identifier (AID), 1-16 bytes | 276 +------------------------------------------------------+ 278 2. Inverse Number Mapping and Wildcards 280 When numbers are allocated in lexically hierarchical blocks so that a 281 prefix or suffix of digits is a meaningful division, the DNS wildcard 282 feature can be used to provide a convenient delegation and lookup 283 mechanism. This works even when the numbers and prefixes/suffixes 284 are variable length. In this regard, it is important to remember that 285 more specific names override less specific ones for DNS wildcards. 287 Domain names start with the most significant label on the right and 288 go to less significant labels as you go left while in ISO 7812 and 289 7816 numbers the leading or left most digits are the most significant 290 while the trailing or right most digits are less significant. Thus, 291 the digits must be reversed to match the card number and DNS naming 292 systems and the digits must be interspersed with dots to provide 293 hierarchical division into DNS domains. 295 Note that the transformed, reversed number need not be exposed to 296 users but could be generated internally by software in an automatic 297 fashion. 299 For example, currently the American Express card brand is the only 300 one using [ISO 7812] numbers starting with 37. However, this is not 301 a guarantee for all time and it could be that at some point some BIN 302 numbers starting with 37 would be assigned to a different brand. If 303 you are looking up facility "z" for card number 37012345678 (not a 304 valid American Express number), you could do a retrieval with a name 305 like 3.2.1.0.7.3.z.card.reg.int based on the first six digits of the 306 number. A wild card RR with the name *.7.3.z.card.reg.int would match 307 this and would appear in the response with its name expanded to the 308 specific name asked for, but only if there were no more specific 309 name. If there were a 3.2.1.0.7.3.z.card.reg.int specific name, for 310 instance, it would always be chosen in preference to the 311 *.7.3.card.reg.int wildcard in this case because it is a more exact 312 match. Thus more specific values can punch out holes in ranges 313 established by shorter, less specific prefixes. On the other hand, 314 if a retrieval were done for 7.7.7.7.7.3.z.card.reg.int, it would get 315 the more general *.7.3.z.card.reg.int wild card since it does not 316 match the more exact wildcard. (The situation is generally a little 317 more complex than indicted here because additional intermediate 318 length wildcards may be needed. See the Appendix for a more complete 319 example zone.) 321 3. Card Domain Names Specified 323 Subdomains are currently defined within the card.reg.int domain as 324 follows in alphabetic order: 326 acquirer.card.reg.int - ISO 7812 card acquirers 327 aid.card.reg.int - ISO 7816 application identifiers 328 brand.card.reg.int. - ISO 7812 card brands. 329 issuer.card.reg.int. - ISO 7812 card issuers. 331 To find a facility, you need to (1) get the number, (2) reverse the 332 order of these digits, and (3) put a dot between each digit and add 333 the appropriate facility suffix. [ISO 7812] financial transaction 334 card identification numbers generally must be truncated to six digits 335 if revealing the full number in the DNS queries would be a security 336 problem. Generally revealing the entire number in a DNS query is not 337 a problem for [ISO 7816] AIDs. 339 None of the facility pointers obtained via these means need be 340 exclusive and these card related Internet facilities may have other 341 names and URLs that will also work. These facilities are intended to 342 supplement, not necessarily replace, direct communication of domain 343 names and URLs from financial institutions to their customers. 345 3.1 ISO 7812 Card Brand, Issuer, and Acquirer Pointers 347 The card brand and issuer home pages would be located by creating the 348 numeric portion as above and appending ".brand.card.reg.int" or 349 ".issuer.card.reg.int" respectively. A CNAME RR will be stored at 350 that name pointing to the actual domain name for the home page. A 351 CNAME is chosen, rather than having specific "A" RRs pointing to 352 host(s), "MX" RRs pointing to mail servers, etc., to minimize the 353 update load on the card.reg.int sub-domains. Changes in the serving 354 host, mail servers, etc., need only be made under the facility's 355 domain name, which the CNAME points to, rather than also under 356 card.reg.int. 358 For example, the brand for the card 551204..., a MasterCard card, 359 would be found by browsing at 4.0.2.1.5.5.brand.card.reg.int. and the 360 issuer for the card 471922..., a VISA card, would be found by 361 browsing at 2.2.9.1.7.4.issuer.reg.card.int. These domain names can 362 be automatically generated from a card number and need not be exposed 363 to users. 365 The Appendix shows possible initial content of the brand.card.reg.int 366 domain. There are relatively few brands and they are allocated to 367 moderately compact blocks of numbers with relatively few exceptions 368 not belonging to the block brand. So there will probably be under 369 2,000 entries in the brand.card.reg.int subdomain. 371 Since there are only a few tens of thousands of banks and other 372 issuers of significance in the world for financial transaction cards, 373 there should be well under 200,000 entries in the issuer.card.reg.int 374 subdomain. 376 Although at this time very large blocks of numbers are generally 377 allocated to brands (for example almost all card numbers starting 378 with 5 and 4 are MasterCard and Visa cards, respectively), some 379 numbers within these large blocks may be carved out by more specific 380 entries for other brands. 382 3.2 ISO 7812 Acquirer Facilities 384 Generally, merchants are assigned merchant IDs from the space of PANs 385 by their acquirer. Acquirer facilities can be located from such 386 numbers using the .acquirer.card.reg.int suffix. 388 3.3 ICON Location 390 For many of the facilities locatable via card.reg.int, some user 391 interface software will want to be able to display an image or icon. 392 Standard suffixes to the computed domain name of the facility are 393 recommended, as listed below, to make the default location of such 394 icons easier. 396 Suffix to Domain Name Image Size in Pixels 398 /icons/exsmall.gif 32 x 32 or 32 x 20 399 /icons/small.gif 53 x 33 400 /icons/medium.gif 103 x 65 401 /icons/large.gif 180 x 114 402 /icons/exlarge.gif 263 x 166 404 The larger dimension above is horizontal and the smaller is vertical. 405 The extra small version is permitted to be a 32x32 square which is a 406 common desk top operating system icon size. It is recommended that 407 displaying the extra small size be avoided due to lower 408 recognizability is such small images. The color palette of the icons 409 should be limited to colors typically available in an 8 bit or 256 410 color environment. 412 The above file name, size, and color recommendations are similar to 413 those in Book 2 of the SET standards [SET]. 415 3.4 Similar Proprietary Systems 417 Some proprietary systems use numbers schemes similar to [ISO 7812] or 418 [ISO 7816]. For instance, an "Example" stored cash card system might 419 use card IDs that have the same structure and prefixes as [ISO 7812] 420 card numbers. Such schemes are welcome to use the techniques 421 described in this document for inverse look up via DNS but should 422 place the inverse tree under their proprietary domain name. For 423 instance, the hypothetical stored cash card system could use 424 ....card-number.example.com. 426 3.5 ISO 7816 Application IDs 428 Facilities based on [ISO 7816] application identifiers can be found 429 using the 431 suffix. While a subset of such IDs are structured like ISO 7812 432 PANs, nevertheless, they are likely to need different facilities so 433 no reference is made to the parts of the card.reg.int DNS tree 434 allocated for non-smart card use. 436 4. Financial Institutions Not On Line 438 Some numbers are allocated to institutions that do not have a network 439 presence. In some of those cases, a wildcard could provide an 440 appropriate pointer, say to a brand supplied bank lookup page that 441 provides telephone number and address or the like to contact the 442 bank. However, in cases where the next higher level wildcard would 443 provide inappropriate pointers for such institutions, it will be 444 necessary to add entries for such numbers which are CNAMEed to "not- 445 on-line.card.reg.int" which will not exist. Thus an appropriate 446 error message will be generated. 448 5. ISO 7812 BIN Ambiguity 450 For the facilities under card.reg.int using ISO 7812 numbers, the BIN 451 is defined as the first six digits of the account number. In many 452 cases an issuer or certification authority is defined by fewer 453 digits, for example the first four digits. This is no problem as a 454 wild card can be used to match all extensions of this shorter prefix. 455 However, cases where six digits are insufficient need special 456 handling as describe below. Such situations can arise due to 457 subdivision / subdelegation of a BIN for administrative reasons, due 458 to sale of part of a card population, as parts of bank mergers and 459 splits, etc. Additional digits can not be used in the DNS query 460 because they would reveal too much of the card number and thus be a 461 security risk. 463 If multiple institutions have decided to share a BIN, there are 464 several ways the situation can be handled. For the issuer web page 465 either (1) the institutions sharing the BIN can run a common web page 466 with links to their individual pages on it or (2) if they are all the 467 same brand, the brand can run such a multi-issuer referral page at 468 the BIN or, in many cases, at a higher level wildcard or (3) in the 469 event that they are different brands, the card.reg.int maintainer can 470 run a page providing access to the different sub-BIN issuers. A 471 multiple issuer home page could just have names, icons, and links to 472 the separate institutions or more complex indexing or search 473 facilities if it covered many banks. While this problem in not 474 expected to arise for the brand.card.reg.int subdomain, similar 475 solutions apply if it does. 477 6. Security Considerations 479 This document concerns a means to map ISO 7812 financial card and ISO 480 7816 smart card application identification numbers into the Domain 481 Name System (DNS) so that card related facilities on the Internet can 482 be automatically located. The security of the resulting pointers is 483 dependent on the integrity of the card.reg.int maintainer and the 484 security of the DNS, including the use of security extensions [RFC 485 2535]. However, note that when used in connection with many smart 486 card application, certificate issuance, and payment schemes, the 487 security mechanisms of the protocols used after communications is 488 established provide strong protection against spoofing or compromise 489 of sensitive information even if the DNS were subverted. 491 For currently existing types of ISO 7812 financial numbers, care 492 should be taken in making DNS queries that an entire sensitive 493 identification number is NOT used. Since DNS queries are not 494 encrypted, this would expose the card number within the Internet. No 495 more than the initial six digits may be used. (These consideration 496 do not generally apply to numbers based on ISO 7816 application 497 identifiers.) 499 References 501 [ISO 3166] - Codes for the representation of names of countries. 503 [ISO 7812-1] - Identification card - Identification of Issuers. 505 [ISO 7816-5] - Identification card - Integrated circuit(s) cards with 506 contacts - Numbering system and registration procedures of 507 application identifiers 509 Note: The International Standards Organization web site is at 510 . Final ISO standards, such as 3166, 7812, and 511 7816, are not generally available on the Internet and usually must 512 be purchased through national standards bodies. 514 [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 515 November 1987 517 [RFC 1035] - Domain Names - Implementation and Specifications, P. 518 Mockapetris, November 1987. 520 [RFC 2535] - Domain Name System Security Extensions, D. Eastlake, 521 March 1999. 523 [SET] - Secure Electronic Transaction (SET) Specification, Version 524 1.0, May 31, 1997, available from . 525 Book 1: Business Description 526 Book 2: Programmer's Guide 527 Book 3: Formal Protocol Definition 529 [SET-EIG] - External Interface Guide to SET Secure Electronic 530 Transaction, September 24, 1997, available from 531 . 533 Author's Address 535 Donald E. Eastlake 3rd 536 Motorola 537 140 Forest Avenue 538 Hudson, MA 01749 540 Telephone: +1 978-562-2827 (h) 541 +1 508-261-5434 (w) 542 FAX: +1 508-261-4447 (w) 543 EMail: Donald.Eastlake@motorola.com 545 Expiration and File Name 547 This draft expires January 2001. 549 Its file name is draft-eastlake-card-map-08.txt. 551 Appendix: Initial ISO 7812 Brand Pointers 553 This table shows possible initial brand name pointers that might be 554 installed in the brand.card.reg.int domain. 556 Initial Name CNAME 558 *.1.brand.card.reg.int www.air-travel-card.com 559 *.3.brand.card.reg.int unknown-brand.card.reg.int 560 *.0.3.brand.card.reg.int www.dinersclub.com 561 *.6.0.3.brand.card.reg.int www.dinersclub.com 562 *.9.6.0.3.brand.card.reg.int www.jcb.co.jp 563 *.8.0.3.brand.card.reg.int www.dinersclub.com 564 *.8.8.0.3.brand.card.reg.int www.jcb.co.jp 565 *.1.3.brand.card.reg.int www.jcb.co.jp 566 *.3.3.brand.card.reg.int www.americanexpress.com 567 *.3.3.3.brand.card.reg.int www.americanexpress.com 568 *.7.3.3.3.brand.card.reg.int www.jcb.co.jp 569 *.5.3.brand.card.reg.int unknown-brand.card.reg.int 570 *.2.5.3.brand.card.reg.int unknown-brand.card.reg.int 571 *.8.2.5.3.brand.card.reg.int www.jcb.co.jp 572 *.6.3.brand.card.reg.int www.dinersclub.com 573 *.7.3.brand.card.reg.int www.americanexpress.com 574 *.8.3.brand.card.reg.int www.dinersclub.com 575 *.4.brand.card.reg.int www.visa.com 576 *.5.brand.card.reg.int www.mastercard.com 577 *.6.brand.card.reg.int unknown-brand.card.reg.int 578 *.0.6.brand.card.reg.int unknown-brand.card.reg.int 579 *.1.0.6.brand.card.reg.int unknown-brand.card.reg.int 580 *.1.1.0.6.brand.card.reg.int www.novus.com 582 (MasterCard actually only has numbers starting with 51 through 56 but 583 until some other brand with cards issued with ISO 7812 numbers 584 starting with a 5 are entered into the DNS zone, there is no reason 585 to go to any more detail in the wildcard.)