Difference between revisions of "Projects/NAPTR"
Npmccallum (talk | contribs) |
(add early project template; bump heading levels) |
||
| (4 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| ⚫ | |||
| + | {{project-early}} |
||
| + | |||
| ⚫ | |||
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well. |
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well. |
||
| − | = The URI Record = |
+ | == The URI Record == |
This is basically an equivalent for SRV records but for URIs. An example might be: |
This is basically an equivalent for SRV records but for URIs. An example might be: |
||
| − | <code>< |
+ | <code><pre> |
| − | + | _mskkdcp IN URI 10 1 "https://kdc.example.com/kdc" |
|
| − | </ |
+ | </pre></code> |
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP. |
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP. |
||
| − | = The NAPTR Record = |
+ | == The NAPTR Record == |
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com). |
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com). |
||
| Line 48: | Line 50: | ||
In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged. |
In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged. |
||
| − | = Definitions = |
+ | == Definitions == |
Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is: |
Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is: |
||
| + | # URI record prefix name |
||
# Service name |
# Service name |
||
# Protocol names |
# Protocol names |
||
| Line 57: | Line 60: | ||
# The behavior of the "P" flag (optional) |
# The behavior of the "P" flag (optional) |
||
| − | For the first |
+ | For the first four, I propose: |
| + | # _mskkdcp |
||
# KRB5 |
# KRB5 |
||
# UDP, TCP and MSKKDCP |
# UDP, TCP and MSKKDCP |
||
| − | # UDP or TCP at the client's discretion |
+ | # In the case of the U flag, MSKKDCP. Otherwise, UDP or TCP (at the client's discretion). |
| − | The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this |
+ | The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this. |
Latest revision as of 15:20, 17 March 2015
Background
The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the URI Record type and its relation to NAPTR records, I think NAPTR provides improvements in other areas as well.
The URI Record
This is basically an equivalent for SRV records but for URIs. An example might be:
_mskkdcp IN URI 10 1 "https://kdc.example.com/kdc"
A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP.
The NAPTR Record
The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com).
First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:
example.com IN NAPTR 100 10 "D" "KRB5+MSKKDCP" "" _mskkdcp.example.com.
example.com IN NAPTR 100 20 "S" "KRB5+UDP" "" _kerberos._udp.example.com.
example.com IN NAPTR 100 20 "S" "KRB5+TCP" "" _kerberos._tcp.example.com.
In this example, the client is instructed to try the MS-KKDCP proxy first. If this fails, it can fall back to TCP or UDP. These lookups will be performed in two stages. First, the NAPTR record will be fetched. From this the method is chosen. Second, the chosen method is queried. For MS-KKDCP, a URI record is queried via the "D" flag. For the others, an SRV record is queried from the "S" flag.
For DNS servers which do not support the URI records, NAPTRs can be used to generate URIs themselves via the "U" flag. In this case, no secondary lookup is performed. Secondary queries can be avoided for TCP/UDP as well using the "A" flag. Here are examples of both:
example.com IN NAPTR 100 10 "U" "KRB5+MSKKDCP" "!^.*$!https://kdc.example.com/kdc!" .
example.com IN NAPTR 100 20 "A" "KRB5+UDP" "" kdc.example.com.
example.com IN NAPTR 100 20 "A" "KRB5+TCP" "" kdc.example.com.
If the administrator does not wish to control TCP or UDP, the protocol portion of the field can be ignored. For instance, this case supports either UDP or TCP:
example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.
On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:
example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.
In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.
Definitions
Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:
- URI record prefix name
- Service name
- Protocol names
- The behavior of a service without a protocol
- The behavior of the "P" flag (optional)
For the first four, I propose:
- _mskkdcp
- KRB5
- UDP, TCP and MSKKDCP
- In the case of the U flag, MSKKDCP. Otherwise, UDP or TCP (at the client's discretion).
The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this.
