Re: [DNSOP] New draft, seeking comments: draft-sah-resolver-information

[Paul Wouters <[e-mail]>]

On Tue, 30 Apr 2019, Paul Hoffman wrote:

> Also note that this is explicitly only for resolvers; we might later do a second protocol for authoritative servers who want to give information about themselves (such as if they do DoT, if that moves forward in DPRIVE). The reason for the split is that a resolver that doesn't know the protocol here might pass the query on to the authoritative servers for the root or .arpa, and the response to the stub would then be ambiguous.

I don't understand why you create a specific RRtype with "information to
be filled in by other documents", yet feel the need to have one for
resolvers, maybe another one for authoritative servers, and kind of
combine "resolvers that could offer signed responses in their
forward zone" together with "random unknown resolvers that cannot
offer signed responses about their capabilities".

I would prefer a generic "DNSINFO" that can be used in the forward and
the reverse, and can contain resolver and authoritative properties.




    if the resolver can be configured
    to also be authoritative for some zones, it can use that
    configuration to actually be authoritative for "resolver-info.arpa".

This is misleading. No one but AS112 or the arpa. TLD nameservers could be
really answer "authoritative".  Others would just pretend to be and lie.
And really, you would want google to put this info into in a forward zone
"dns.google.com" and not limit RESINFO (or DNSINFO) to the reverse zone.

    For example, if the stub knows that it
    wants information whose name is "temp-field2", it would send the
    query temp-field2.resolver-info.arpa/IN/RESINFO.

I can see why you might want this, to allow for smaller return answers
when the stub only cares about one of many pieces of resolver infomation
that might be available, but it oddly puts DNS naming constrains in that
information ? It also opens up pandora's box of IDN support.

    Any query for the RESINFO RRtype that is not in resolver-info.arpa/IN
    or a subdomain of resolver-info.arpa/IN is meaningless and MUST
    result in a NODATA or NXDOMAIN response.

Do you expect this policing to be enforced in code? I think that's
naive. Anyone who is not implementing this will treat is as a generic
record and just relay it back. So it is bound to be violated. I wouldn't
bother trying to police this. Also, I think there are valid use cases
for RESINFO in the forward, eg if I have dns.nohats.ca on my owned IP
as the resolver, so I can give you DNSSEC authenticatied answers.

 	3.  Retrieving Resolver Information by Well-Known URI

You offer a non-DNS method that can deliver (channel) authenticated
answers, but you don't allow DNSSEC (data origin) authenticated answers?

    A resolver that uses this protocol to publish its information SHOULD,
    if possible, have a TLS certificate whose subject identifiers are any
    IP address that the resolver is available on

Again lifting TLS over DNSSEC ?


    If the request was over DNS using a subdomain under resolver-
    info.arpa, the resolver SHOULD return an object that contains a name-
    value pair with that name if the resolver has that information.  If
    the resolver does not have information for that name, it MUST NOT
    returen the name in the object.

So what should it return? The options are 1) nothing or 2) all and the
document should clearly specify which of the two is allowed and which is
prefered.

    If the request was over HTTPS, the resolver SHOULD return an object
    with all known name-value pairs for which it has information.

It is a little unclear whether this is part of the "a specific name was
requested" case. And if the rules above for DNS/subdomains apply here. I
think the authors are implying that HTTPS is so expensive in overhead
and has no packet size issues, you might as well always return
everything. If so, just state that more clearly.

    All names in the returned object MUST be defined in the IANA registry
    or begin with the substring "temp-".

IETF tradition is to use a x- or X- prefix for this kind of thing. Why
now use "temp-" ?

       "inventory": [ "inventory", "temp-field1", "temp-field2" ]

I'm not sure how useful "inventory" is. It cannot be trusted anyway, so
I think if I would write code for this, I would just completely gnore it
anyway.


    The specification that is required for registration can be either an
    Internet-Draft or an RFC.

I'm a little uneasy with this. If the draft is moving forward and we do
an Early Code Point, that is fine. If it is a batshit crazy draft that
will never get RFC status, it should not. You can see the Expert will
handle with this, but sadly this text is followed by:

    The reviewer for this registry is
    instructed to generally be liberal in what they accept into the
    registry: as long as the specification that comes with the
    registration request is reasonably understandable, the registration
    should be accepted.

Also, for those who would like to use DNS queries, size does matter.

What to do if the inventory is too large for a DNS reply. What are the
rules for choosing which content to include or not? Or are you expecting
a truncated response and a TCP retry? There should be text about this.

 	6.  Security Considerations

It does not talk about putting this information in the forward zone
of a named resolver (eg dns.nohats.ca) that can use DNSSEC to protect
this information.


Paul
ps: NITS: when announcing drafts for people to read, including a URL is helpful :)