[dnsext] RR review request

[Ted Hardie <[e-mail]>]

Somewhat amusingly, given the ongoing discussion on whether new RRs
are possible/useful/unicorn-friendly, I just published a -00 version
of a request for a new RR:  draft-hardie-rm-rr
(http://tools.ietf.org/html/draft-hardie-rm-rr-00).    Comments are
welcome; Olaf happened upon it a day or so ago, and his review is
below, along with my comments.

Google has filed an IPR declaration for this, which is at:
https://datatracker.ietf.org/ipr/1702/ .

As the document notes, the overall draft structure and some specifics
of this draft are lifted wholesale from the URI RR draft that Olaf and
Patrik published, and I thank them for the work it saved me.

Further in-line.

On Wed, Mar 7, 2012 at 3:21 AM, Olaf Kolkman <[e-mail]> wrote:
>
> Hello Ted,
>
>
> I stumbled upon draft-hardie-rm-rr-00.
>
> Hereby a few comments/questions.
>
> 1.
>
>  "This draft proposes a
>   DNS Resource Record for this purpose, with the assumption that it
>   would be made available on the public side of any split DNS."
>
> This seems to suggest that only the public side of a split DNS is where the RR gets published. It occurs to me that making that distinction is not needed.
> Maybe:
>  "This draft proposes a DNS RR for publishing how a resource on a LRD can be reached."

Fair enough.  I was not intending to say that it would be available
only on the public side of split DNS, so it may be clearer to elide
any mention of split DNS here.

>
> 2.
>
>  "Reachability Method (RM) records can be queried directly, but it is
>   expected that they will commonly be returned as additional data by
>   servers relating information about hosts that are located within a
>   limited reachability domain (e.g. with queries for the A or AAAA
>   record associated with a host within an enterprise network). "
>
>
> That is a unrealistic expectation. In order to add RRs to an additional section servers (both authoritative and recursive) need to have the logic to add these records.
>
> FWIW, and maybe worth mentioning is that in the split DNS case I can imagine that there are no A and AAAA records registered at the external side of a public DNS (which does not exclude that with the empty-answer section in the DNS come RRs in the additional section).
>
> I suggest that you drop the 'additional data' expectation and just count on the additional query loop. Possibly
>

It's a good point that recursive servers would also have to have the
logic.  Obviously you can query for the base record and an RM record
in two queries sent at the same time, which limits the timing hit but
may make for some coordination issues.  wonder if reversing this so
that you query for the RM record and get the address itself in the
additional section would make this more likely.
Any thoughts on that?

>   Reachability Method (RM) records are, in general, to be queried directly although
>   they might be returned as additional data by
>   servers relating information about hosts that are located within a
>   limited reachability domain (e.g. with queries for the A or AAAA
>   record associated with a host within an enterprise network).
>
>
>
> 3.
>  "If the reachability method varies over time, the TTL of the RM RR
>   will need to be managed to match and coordinated with the TTL of the
>   resource to be reached.  If the reachability method varies according
>   to other characteristics, something akin to split DNS must be
>   managed, with the usual conflicts with the DNS's core loose
>   consistency model."
>
> What other characteristics are you thinking off?
>
>
One example would be varying the ingress regionally, based on the
querier's address;
you might do that if the actual resource was actually anycast inside
the enterprise network.


>
>
> 4.
>
>  "The target is a URI, enclosed in double-quote characters ('"').
>   Resolution of the URI is according to the definitions for the Scheme
>   of the URI.  The URI is encoded as one or more <character-string>
>   RFC1035 section 3.3 [RFC1035]"
>
> Are there i18n aspects to how the domain name portion of the URI is to be encoded? (Possibly easily solved by a reference).
>

I think this is covered in the IRI text, but if it is not, please let me know.


>
> 5.
>
>  RM as mnemonic
>
> Although there is no real problem on the wire there might be some confusion when using troubleshooting tools like "dig" where the mnemonic might clash with a CCTLD code.
>
> e.g.
> 'dig MX IN CH RM'    (Not that that is a new problem).
>
> I would suggest a mnemonic that is somewhat longer and has a more limited chance of clashing with a TLD (although with a gazillion new TLDs that chance might increase)... REACHM might not be that popular as a 180kUS$ TLD.
>
All the ones I thought of had the similar issues, though not with
cctlds (adjunct reachability method=ARM etc.).  If this is judged to
be a serious problem, I'll be happy to change it, but I think it's
basically possible to hit the problem elsewhere.  RM at least is not
yet allocated as an ISO 3166 two letter code.


Thanks again for the review,

Ted
>
>
> --Olaf
>
>
> Feel free to forward to any list on which this is discussed.
>
>
>
>
> ________________________________________________________
>
> Olaf M. Kolkman                        NLnet Labs
> http://www.nlnetlabs.nl/
>
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext