> On 11 Apr 2022, at 17:57, Mark Andrews <[email protected]> wrote: > > I don’t see why APL (RFC 3123) can’t be used for CRC give you need to > construct an > owner name anyway and have well known label to seperate the components of the > name. > I see no reason to re-invent the wheel here. > > ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 > > would be > > ftp.foo.com._21._crc.bar.com APL 1:195.13.35.0/24 1:91.220.43.0/24
Additionally text is a really bad way to transmit IP address and prefixes in the DNS. DNS RRsets are resource constrained (maximum < 64k). DNS caches are resource constrained. 10-16 octets of text for an IPv4/24 vs 7 octets for APL. An IPv4/8 is 9-11 vs 5 octets. The :: improves this a little bit for IPv6 but in general you will be dealing with /48’s or longer xxxx:xxxx:xxxx::/48 (19 octets) vs 10 for APL. >> On 5 Apr 2022, at 20:52, Eugène Adell <[email protected]> wrote: >> >> Hello, >> >> I've been working on two new RRTypes described by a Draft, and as >> suggested by our magnificent, incredibly brilliant and handsome AD >> Warren "ACE" Kumari, I am posting here this idea and the material I >> have written so far (the draft itself, and RFC 6895 components). >> >> Briefly, one RRType (CRC : Client Roaming Control) contains a >> whitelist of networks allowing a company employees to connect to a >> specific application. The second RRType (CRS : Client Roaming Support) >> is on the application side and informs what kind of restrictions are >> applied (by saying if CRC is mandatory, optional or ignored). >> This is not expected to be deployed broadly and everywhere as it is >> designed to secure Business-To-Business applications. >> >> The material (text XML2RFC draft + RFC 6895 components) written is >> both incorporated below to this email and attached, for practical >> reasons. >> >> >> Regards >> E.A. >> >> >> >> >> >> Internet Engineering Task Force E. Adell >> Internet-Draft 5 April 2022 >> Intended status: Informational >> Expires: 7 October 2022 >> >> >> Client Roaming Control >> draft-adell-client-roaming-00 >> >> Abstract >> >> This document specifies the Client Roaming Control (CRC) DNS Resource >> Record allowing an organization to better control the access to >> third-party applications over Internet. The applications >> implementing an authorization mechanism to honor the CRC, publish on >> their side the Client Roaming Support (CRS) Resource Record to inform >> of this support. >> >> Status of This Memo >> >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current Internet- >> Drafts is at https://datatracker.ietf.org/drafts/current/. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> This Internet-Draft will expire on 7 October 2022. >> >> Copyright Notice >> >> Copyright (c) 2022 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents (https://trustee.ietf.org/ >> license-info) in effect on the date of publication of this document. >> Please review these documents carefully, as they describe your rights >> and restrictions with respect to this document. Code Components >> extracted from this document must include Revised BSD License text as >> described in Section 4.e of the Trust Legal Provisions and are >> provided without warranty as described in the Revised BSD License. >> >> >> >> Adell Expires 7 October 2022 [Page 1] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 >> 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 >> 3. The CRC Resource Record . . . . . . . . . . . . . . . . . . . 4 >> 3.1. RR name field . . . . . . . . . . . . . . . . . . . . . . 4 >> 3.2. CRC RDATA Wire Format . . . . . . . . . . . . . . . . . . 4 >> 3.3. CRC Presentation Format . . . . . . . . . . . . . . . . . 4 >> 4. The CRS Resource Record . . . . . . . . . . . . . . . . . . . 5 >> 4.1. CRS RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 >> 4.2. CRS Presentation Format . . . . . . . . . . . . . . . . . 5 >> 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 >> 5.1. Restricted Application . . . . . . . . . . . . . . . . . 6 >> 5.2. Controlled Application . . . . . . . . . . . . . . . . . 7 >> 5.3. Opened Application . . . . . . . . . . . . . . . . . . . 8 >> 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 >> 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 >> 7.1. DNS misconfiguration . . . . . . . . . . . . . . . . . . 9 >> 7.2. DNS Security . . . . . . . . . . . . . . . . . . . . . . 10 >> 7.3. Application Security . . . . . . . . . . . . . . . . . . 10 >> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 >> 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 >> 8.2. Informative References . . . . . . . . . . . . . . . . . 11 >> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 >> >> 1. Introduction >> >> Illegitimate access to professional restricted applications over >> Internet is a permanent threat for organizations and their staff. >> Different methods can be used to impersonate a user access, and in >> some cases an organization also wants to better prevent its own staff >> to access a third-party application from a network which is not under >> its control. On the contrary, an organization maybe wants to allow >> roaming then its users can access from different known places. >> >> The Client Roaming Control (CRC) DNS Resource Record (RR) acts as a >> White-List and informs a compatible application from which networks >> its users are allowed to connect, be it a limited list of networks or >> broadly without any restriction. >> >> >> >> >> >> >> >> >> >> >> >> >> Adell Expires 7 October 2022 [Page 2] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> At the application level, the identification of the user's >> organization domain can be based on an information carried during the >> authentication process, or a lookup on an information already known >> by the application. In both cases this information lets the >> application relate the user to its organization unequivocally. >> Finally, the corresponding user's domain DNS will be requested with >> the application's FQDN and port, and the application will know >> whether an authorization is expected or not. Some examples will be >> given in this document. >> >> The applications implementing this authorization control let the >> client organizations know this feature is available by using the >> Client Roaming Support (CRS) RR. The data associated with this >> record indicates if the client's organization expected support of the >> CRC is mandatory, optional, or ignored. This information stored in >> the CRS can be confirmed at the application level by a redundant >> data. The way the application handles the authorization mechanism, >> by consulting the associated CRS record or not, is left to the >> implementor. >> >> Although this mechanism is designed for improving the security >> between different organizations, there is no objection to use it for >> a same organization playing both roles of client and application , as >> an alternative or additional layer to a solution already in place, >> such as a firewall for example. >> >> 2. Conventions Used in This Document >> >> This specification uses definitions from Domain Name System >> [RFC1035], and readers unfamiliar with it can also check DNS >> Terminology [RFC8499]. The syntax specification uses the Augmented >> Backus-Naur Form (ABNF) notation as specified in [RFC5234], with some >> expressions being defined in "Uniform Resource Identifier (URI): >> Generic Syntax" [RFC3986] and "IP Version 6 Addressing Architecture" >> [RFC4291]. >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in BCP >> 14 [RFC2119] [RFC8174] when, and only when, they appear in all >> capitals, as shown here. >> >> >> >> >> >> >> >> >> >> >> Adell Expires 7 October 2022 [Page 3] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> 3. The CRC Resource Record >> >> The CRC RR purpose is to provide a list of IP ranges authorized to >> use a particular application. Each RR contains a list of either IPv4 >> or IPv6 network address ranges. These ranges MUST follow the CIDR >> notation. A single CRC RR MAY contain ranges for different IP >> versions, but in the case of many ranges this can be difficult to >> read or maintain, so dedicating a record to each IP version or not is >> left to the administrator. Multiple RRs MAY be defined for a given >> IP version. >> >> 3.1. RR name field >> >> The CRC RR name field is composed of the third-party application >> domain, its port, followed by the fully qualified name inherent in >> this zone. These three components are separated by the underscore >> character. >> >> 3.2. CRC RDATA Wire Format >> >> The CRC RDATA wire format is encoded as follows: >> >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> / CRC / >> / / >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> >> The CRC field contains a list of either IPv4 or IPv6 ranges separated >> by the comma character. >> >> 3.3. CRC Presentation Format >> >> The presentation format of the CRC record is: >> >> CRC (ip4netlist [,ip6netlist]) / ([ip4netlist,] ip6netlist) >> >> ip4netlist = ip4net *(,ip4net) >> >> ip4net = IPv4address "/" ip4range >> >> ip4range = DIGIT / "1" DIGIT / "2" DIGIT / "3" DIGIT %x30-32 >> >> ip6netlist = ip6net *(,ip6net) >> >> ip6net = (ipv6-address "/" prefix-length) >> >> >> >> >> >> >> Adell Expires 7 October 2022 [Page 4] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> 4. The CRS Resource Record >> >> The CRS RR indicates which control is done on the client >> organizations, and thus which ones are authorized. A requirement >> field is used for this purpose, it has one of the following values >> meaning when the checking is performed : >> >> * "N" : Never, all organizations are authorized >> >> * "A" : Always, only organizations with a CRC are authorized >> >> * "O" : Optional, any organization CRC is honored, other >> organizations are authorized >> >> In addition to this value, an optional list of ports can be given. >> Indeed, multiple applications can be hosted on different ports under >> the same domain name, and an equivalent support was described for the >> CRC RR. In case of different requirement values, it is RECOMMENDED >> to have one dedicated RR for each although one single RR with all the >> information is supported. One particular port MUST NOT appear in >> more than one RR. When no port is mentioned, only one RR MAY be >> declared and its requirement value covers all applications for this >> domain name. >> >> In the absence of such record, no roaming control is to be expected >> by the client, any of its CRC RRs will be ignored. It is equivalent >> to a CRS requirement value indicating no control is performed. >> >> 4.1. CRS RDATA Wire Format >> >> The CRS RDATA wire format is encoded as follows: >> >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> / CRS / >> / / >> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ >> >> The CRS field contains a list of requirements followed by their >> respective optional ports. >> >> 4.2. CRS Presentation Format >> >> The presentation format of the CRS record is: >> >> CRS (single-rule / multiple-rules) >> >> single-rule = "R=" ("N" / "A" / "O") *(,port) >> >> >> >> >> Adell Expires 7 October 2022 [Page 5] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> multiple-rules = unit-rule 1*2(;unit-rule) >> >> unit-rule = "R=" ("N" / "A" / "O") 1*(,port) >> >> port = [1-9] *([DIGIT]) >> >> 5. Examples >> >> The following examples show some typical uses expected from this >> documentation. Particularly, the intended behaviors for different >> CRC and CRS values are explained, while the user identification is >> done directly through carried data or a deduction process. >> >> 5.1. Restricted Application >> >> In this example, an application is only opened to organizations >> publishing their respective allowed networks. The requirement value >> of the CRS record equals "A", and any organization with an empty or >> missing CRC for this application will be denied access. >> >> The ftp.foo.com domain is dedicated to hosting an FTP application, >> which extracts the client's domain from the username used during the >> authentication process. This information is then used for requesting >> the client CRC record and finally comparing its content with the >> client's IP. The client organization bar.com allows its users from >> its own network 195.13.35.0/24 and from a cloud service located at >> 91.220.43.0/24. A second organization baz.com has no CRC record and >> its users are rejected. >> >> Application FQDN : ftp.foo.com >> Application CRS record : CRS R=A,21 >> >> Client FQDN : bar.com >> Client organization CRC record : CRC >> ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 >> >> Client FQDN : baz.com >> No client organization CRC record >> >> >> >> >> >> >> >> >> >> >> >> >> >> Adell Expires 7 October 2022 [Page 6] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> Client DNS Client FTP Server FTP >> >> FTP USER [email protected] >> -----------------------------> >> ... >> FTP PASS ******** >> -----------------------------> >> Query : CRC ftp.foo.com_21_bar.com >> <------------------------------------ >> Answer : CRC ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24 >> ------------------------------------> >> FTP 230 >> <------------------------------ >> >> >> FTP USER [email protected] >> -----------------------------> >> ... >> FTP PASS ******** >> -----------------------------> >> Query : CRC ftp.foo.com_21_baz.com >> <------------------------------------ >> Answer : No such name (3) >> ------------------------------------> >> FTP 430 >> <------------------------------ >> >> 5.2. Controlled Application >> >> The foo.com domain hosts a Web application on port 443 using client >> certificates for authenticating its users. The application extracts >> the client domains from the certificates, which are used to retrieve >> their CRC records. Users from the bar.com organization are allowed >> only if they connect from an authorized network listed in the CRC >> record, while users from baz.com are always granted access since this >> one has no CRC declared. >> >> Application FQDN : foo.com >> Application CRS record : CRS R=A,443 >> >> Client FQDN : bar.com >> Client organization CRC record : CRC >> ftp.foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 >> >> Client FQDN : baz.com >> No client organization CRC record >> >> >> >> >> >> Adell Expires 7 October 2022 [Page 7] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> Client DNS Client browser Web application >> >> >> ..... >> Client certificate [email protected] >> -----------------------------------> >> Query : CRC foo.com_443_bar.com >> <------------------------------------------ >> Answer : CRC foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24 >> ------------------------------------------> >> ..... >> 200 OK >> <----------------------------------- >> >> >> ..... >> Client certificate [email protected] >> -----------------------------------> >> Query : CRC foo.com_443_baz.com >> <------------------------------------------ >> Answer : No such name (3) >> ------------------------------------------> >> ..... >> 200 OK >> <----------------------------------- >> >> 5.3. Opened Application >> >> A company is testing the CRC and CRS behaviors before opening a new >> service to its customers. Its first test described below consists in >> configuring both sides to be completely opened, likely before >> hardening the CRS, then the CRC, and testing again. >> >> The application.foo.com domain hosts a Web application on port 443 >> where users are logged in by sending a numerical identifier and a >> password. The application uses a dictionary data type to identify >> the user's domain. The client.foo.com domain is temporarily using 2 >> CRC records indicating a free access from anywhere. >> >> Application FQDN : application.foo.com >> Application CRS record : CRS R=N,443 >> >> Client FQDN : client.foo.com >> Client organization CRC records : CRC >> application.foo.com_443_foo.com,0.0.0.0/24; CRC >> application.foo.com_443_foo.com,fe80::/10 >> >> >> >> >> >> Adell Expires 7 October 2022 [Page 8] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> Client DNS Client browser Web application >> >> >> ..... >> HTTP POST 123456/****** >> -----------------------------------> >> 200 OK >> <----------------------------------- >> >> 6. IANA Considerations >> >> According to Guidelines for Writing an IANA Considerations Section in >> RFCs [RFC8126] it is asked to IANA to add into the Resource Record >> (RR) TYPEs registry located at https://www.iana.org/assignments/dns- >> parameters/dns-parameters.xhtml#dns-parameters-4 the two entries CRC >> and CRS. >> >> +------+-------+------------------------+-----------+ >> | TYPE | Value | Description | Reference | >> +------+-------+------------------------+-----------+ >> | CRC | TBD1 | Client Roaming Control | this RFC | >> +------+-------+------------------------+-----------+ >> | CRS | TBD2 | Client Roaming Support | this RFC | >> +------+-------+------------------------+-----------+ >> >> Table 1 >> >> 7. Security Considerations >> >> This section is meant to inform developers and users of the security >> implications of the CRC/CRS mechanism described by this document. >> While the CRS RR mostly plays an informative role, the CRC RR >> delivers important data which requires attention from the developers >> and administrators. Some particular points are discussed here. >> >> 7.1. DNS misconfiguration >> >> Any DNS CRS misconfiguration such as multiple records with different >> requirement values but with the same port value can get a client >> confused. In this case the client does not know without testing the >> actual configuration, if its organization is protected against >> roaming, and contacting the application administrator to fix the >> situation is a possibility. >> >> While CRC misconfigurations are more or less leading to serious >> security problems, administrators need to pay attention when dealing >> with multiple networks or records. Particularly, multiple records >> for the same network range or overlapping networks should be avoided. >> >> >> >> Adell Expires 7 October 2022 [Page 9] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> 7.2. DNS Security >> >> Client and application administrators need to pay as much attention >> as they usually do when dealing with DNS management. As the CRC >> records are supposed to be requested during an application >> authentication process, reflection attacks could be built to target a >> client organization, even one not hosting any CRC record at all. >> In a general manner, administrators may consider an adequate TTL >> setting to not overload client organizations, enable TCP as the >> preferred transport, or rely on DNSSEC to warrant data authenticity >> and integrity. >> >> 7.3. Application Security >> >> The following points are of concern to developers: >> >> Encryption: >> Whenever possible, the application protocol should be encrypted to >> prevent eavesdropping and man-in-the-middle attacks. It is a >> critical point for applications maintaining a user session with >> anything like a token or cookie, as it can lead to session hijacking >> as discussed below. >> >> Timing attack: >> All authentication systems need to be careful to not deliver any >> information derived from the computing time to a denied user, even >> the ones involving multiple factors or steps like the one described >> in this document. In particular, the order in which these steps are >> executed and their respective implementations, need to defeat >> statistical hypotheses. >> >> Intermediate systems: >> Some applications are not directly Internet facing and cannot access >> to the real client's IP address without involving a mechanism to >> forward this IP at the application layer. For example with HTTP, the >> common practice based on the non-standard X-Forwarded-For header, or >> its alternative standard Forwarded [RFC7239], are playing this role. >> Such practice requires a correct sanitizing of user data to avoid >> false injected IPs. >> >> Session hijacking: >> A well-known attack called Session Hijacking is not meant to be >> defeated by this document alone. Application developers must ensure >> that any receveid session token, such as an HTTP Cookie, belongs to >> the same IP address than the one which started this session. >> >> 8. References >> >> >> >> >> Adell Expires 7 October 2022 [Page 10] >> >> Internet-Draft Client Roaming Control April 2022 >> >> >> 8.1. Normative References >> >> [RFC1035] Mockapetris, P., "Domain names - implementation and >> specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, >> November 1987, <https://www.rfc-editor.org/info/rfc1035>. >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, >> DOI 10.17487/RFC2119, March 1997, >> <https://www.rfc-editor.org/info/rfc2119>. >> >> [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform >> Resource Identifier (URI): Generic Syntax", STD 66, >> RFC 3986, DOI 10.17487/RFC3986, January 2005, >> <https://www.rfc-editor.org/info/rfc3986>. >> >> [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing >> Architecture", RFC 4291, DOI 10.17487/RFC4291, February >> 2006, <https://www.rfc-editor.org/info/rfc4291>. >> >> [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax >> Specifications: ABNF", STD 68, RFC 5234, >> DOI 10.17487/RFC5234, January 2008, >> <https://www.rfc-editor.org/info/rfc5234>. >> >> [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC >> 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, >> May 2017, <https://www.rfc-editor.org/info/rfc8174>. >> >> 8.2. Informative References >> >> [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", >> RFC 7239, DOI 10.17487/RFC7239, June 2014, >> <https://www.rfc-editor.org/info/rfc7239>. >> >> [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS >> Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, >> January 2019, <https://www.rfc-editor.org/info/rfc8499>. >> >> Author's Address >> >> Eugene Adell >> Email: [email protected] >> >> >> >> >> >> >> >> >> Adell Expires 7 October 2022 [Page 11] >> >> >> RFC 6895 : >> A. Submission Date:2002/04/05 >> B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE >> B.2 Kind of RR: [X] Data RR [ ] Meta-RR >> C. Contact Information for submitter : >> Name: Eugene Adell Email Address: [email protected] >> International telephone number: +33699056914 >> Other contact handles: >> D. Motivation for the new RRTYPE application. >> Introduce a couple of RR types working together in order to better >> secure remote access to partner applications >> E. Description of the proposed RR type. >> CRC contains a limited list of authorized networks for a particular >> application >> F. What existing RRTYPE or RRTYPEs come closest to filling that need >> and why are they unsatisfactory? >> TXT RRTYPE allows the storage of any text data but in practice is >> usually associated with more or less fixed name or data which is not >> what is needed here. A dedicated RRTYPE is easier to identify and >> manage by a security team other than the usual DNS operator team. >> G. What mnemonic is requested for the new RRTYPE (optional)? >> CRC >> H. Does the requested RRTYPE make use of any existing IANA registry or >> require the creation of a new IANA subregistry in DNS Parameters? >> It uses the existing Resource Record (RR) TYPEs registry >> I. Does the proposal require/expect any changes in DNS >> servers/resolvers that prevent the new type from being processed as an >> unknown RRTYPE (see [RFC3597])? >> No >> J. Comments: >> None >> >> >> A. Submission Date:2002/04/05 >> B.1 Submission Type: [X] New RRTYPE [ ] Modification to RRTYPE >> B.2 Kind of RR: [X] Data RR [ ] Meta-RR >> C. Contact Information for submitter : >> Name: Eugene Adell Email Address: [email protected] >> International telephone number: +33699056914 >> Other contact handles: >> D. Motivation for the new RRTYPE application. >> Introduce a couple of RR types working together in order to better >> secure remote access to partner applications >> E. Description of the proposed RR type. >> CRS contains a requirement value and a list of ports indicating >> what kind of authorization check is done during the application >> authentication process >> F. What existing RRTYPE or RRTYPEs come closest to filling that need >> and why are they unsatisfactory? >> TXT RRTYPE allows the storage of any text data but in practice is >> usually associated with more or less fixed name or data which is not >> what is needed here. A dedicated RRTYPE is easier to identify and >> manage by a security team other than the usual DNS operator team. >> G. What mnemonic is requested for the new RRTYPE (optional)? >> CRS >> H. Does the requested RRTYPE make use of any existing IANA registry or >> require the creation of a new IANA subregistry in DNS Parameters? >> It uses the existing Resource Record (RR) TYPEs registry >> I. Does the proposal require/expect any changes in DNS >> servers/resolvers that prevent the new type from being processed as an >> unknown RRTYPE (see [RFC3597])? >> No >> J. Comments: >> None >> <draft-adell-client-roaming-00.txt><RFC 6895 >> material.txt>_______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
