Edward Lewis <edward.le...@icann.org> wrote:
> I've shuffled my feet before (the "Again" in the subject) to express my
> dislike of the HINFO technique.
I have implemented (and deployed into production) the pick-one option
not the HINFO option.
> Notably missing is - what if the QNAME does not exist ("Role of
> Wildcards in the DNS" section 2.2)? (An open question...)
You should either get a negative response or a wildcard-synthesized
positive answer. And for refuse-any the positive answer will be
substituted by HINFO or pick-one - the negative answer remains negative.
> If the server chooses to answer with "just some record" (the first
> option), how would a querier know that this means ANY is not honored?
> Personally, I don't think that a protocol should have a state in which the
> situation is ambiguous. (There are many examples of protocols that do and
> many examples of ambiguity, but that doesn't make it a good thing.) I
> can't quantify why this approach seems to lacking something
> (architecturally).
There are three kinds of clients we care about: real software (such as
qmail) making legitimate (but misguided) queries; manual debugging
queries; and abusive queries.
Clients making legit queries don't (can't) care whether ANY is answered in
full or not, because they have to deal with partial ANY responses because
caches can expire different RRsets at different times. So a partial answer
will work OK even if the software has to make follow-up queries to fill in
the missing RRsets.
Humans doing manual debugging should have enough clue to be able to work
it out. A synthesized HINFO helps to provide the clue, but if the server
can't synthesize, the human will have to enjoy a slightly more challenging
learning experience.
Abusive queries frequently get relayed by otherwise-legitimate recursive
servers or proxies. You want to minimise the abuse traffic, so you have to
avoid making these co-opted intermediaries retry, so you have to give them
a positive answer. Anything will do, but a small answer minimises the
traffic both at the authority server and at the relays and/or caches that
are being more directly attacked.
> Perhaps, if you mean "no" say "no."
That isn't an option because it breaks things.
> If the server chooses to answer with a synthesized HINFO and has to sign
> it for DNSSEC, there's a line being crossed. The server answering has to
> have the zone's key to make the signature. DNSSEC was not designed for
> that although it is easily demonstrated that on-line signing can be done.
> The reason I raise this is, what about interoperability?
Online synthesis falls into the same bucket as all the existing CDN DNS
shenanigans. Domain owners either buy in to one implementation for all
their name servers, or they abstain from clever tricks. There is no
interoperability. Shrug. Not much point complaining about proprietary
extensions.
> I agree this is an server operator thing, not a zone admin thing. The
> data in the DNS is managed by a zone admin, not the server operator.
That is not right - it can be either depending on which option you choose.
The pick-one option can be a server operator thing. For example, my
authoritative servers for cam.ac.uk provide minimal ANY responses, but
most of my secondaries do not. (And my servers also do minimal ANY
responses for signed zones which we secondary in the traditional manner,
such as srcf.net and ic.ac.uk.)
However the synthetic HINFO option assumes (and requires that) the server
operator is also acting as zone admin and keyholder etc.
> I do know of another operator that has turned off ANY queries. They did
> it by sending nothing back. The name exists, the authoritative server
> sends back RCODE=refused.
That is not a good idea because it leads to retry amplification and it
will probably upset qmail.
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode
German Bight, Humber: Southwest 5 to 7, veering west 4 or 5. Moderate or
rough, becoming slight or moderate. Showers. Good.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
