On Wed, 15 May 2019, Paul Hoffman wrote:
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,
See above. If a stub asks a question for its resolver, it should get answers
for that resolver or an NXDOMAIN. The stub should not need to use heuristics to
determine if the answer was actually from the root zone, or from the .arpa zone.
But the content of RESINFO and the record of the to-be-done AUTHINFO
would be the same, namely a JSON blob. Why use two different RRtypes?
The JSON needs to be parsed and looked up for useful key words anyway.
So if you want to assist people re-using the RRdata in the forward and
reverse, you might as well pick one RRtype instead of having two.
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".
Because we cannot force anyone to sign their zones.
You cannot for people to enable DoT or DoH either? I don't understand
your point.
I would prefer a generic "DNSINFO" that can be used in the forward and
the reverse, and can contain resolver and authoritative properties.
Wouldn't that inherently be more complicated than two different RRtypes, each
of which has precise semantics?
I don't think so. It's all JSON anyway.
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.
Agree. There was a suggestion that we instead use
<reversed-address>.in-addr.arpa, and that sounds like a better suggestion.
Wouldn't that have problems when in RFC1918 space? Where AS112 answers
with DNSSEC validated NXDOMAINs? At the very least the stub would need
to be aware of these special cases.....
You never replied why you are not using x-field2 instead of temp-field,
as is IETF lore?
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 ?
Yes, exactly.
It also opens up pandora's box of IDN support.
Good point. We will restrict the names in the name-value pairs to be LDH
characters.
ok.
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.
Yep. This reinforces the proposal for <reversed-address>.in-addr.arpa.
ok.
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?
Agree. Thus, the change to <reversed-address>.in-addr.arpa.
sure, but see above. I think this has issues with RFC1918
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 ?
Agree. Thus, the change to <reversed-address>.in-addr.arpa.
Okay. Although some text should be added here or in the security
considerations about using 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.
The answer is in the body of the document: whatever it wants, as long as the returned
object contains "inventory".
I did not find the answer clear. Pointing me back to the document
doesn't help. Can you quote me the text where it is clear if an
implementer should do 1) or 2) and what the guidance for that is?
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.
The design has no defined way to use an HTTPS request to request a specific
name-value pair. This is to make the URI definition easier.
Wouldn't it make sense that you only describe different ways to get the
same data, and not different ways to get different data? I would prefer
if we keep the protocol the same and independent of the transport
protocol.
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.
It was not about expensive, it was about expressiveness.
I don't understand this. Can you rephrase your answer?
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-" ?
See BCP 178 (RFC 6648).
Okay this is interesting. I never heard of it, but reading it it seems
to be talking about not only the prefix of "x-" but also of the concept
of it, saying:
Creators of new parameters to be used in the context of application
protocols:
1. SHOULD assume that all parameters they create might become
standardized, public, commonly deployed, or usable across
multiple implementations.
2. SHOULD employ meaningful parameter names that they have reason to
believe are currently unused.
3. SHOULD NOT prefix their parameter names with "X-" or similar
constructs.
The "temp-" construct clearly fails 1) and 3)
"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.
What do you mean by "trusted"?
If I read in the JSON, I get a list of keys anyway. Why assume the
keyword "inventory" is telling the truth? From a security point of view
you cannot assume it is. So then I'm actually just not using the
keyword. Since we care about size in the DNS transport case, it is
better left out - it serves no useful purpose.
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.
Proposed text for an alternative that is still liberal would be great.
I agree that would be great :)
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.
DNS replies can be arbitrarily large.
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.
This is normal DNS response handling.
It does assume some minimum kind of support you have to know before
querying for all the supported features :)
Anyway, just a note saying if the reply it too large, normal DNS
processing applies and fallback to TCP is expected.
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.
Agree. This will be handled better in the next draft.
Note I did initially think this was more something to be done at the
DHCP level, where you get a list of DNS servers, so it might as well
send the feature set of each, but after some thinking about this, I
agree this method is much better - it can be deployed by updating only
DNS software.
So I'm in favour of WG adoption of this work :)
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
