WAI
Status Update
No update yet.
Comments
ke...@gmail.com
Enviar mis recompesas cuenta de banco
al...@google.com
(I know this is old, but the above (confused/spam) reply bumped it up. I'm new-ish to the project, and answering this concretely is a nice knowledge reinforcement practice.)
https://tools.ietf.org/html/rfc2181#section-5.1
In this case, Public DNS is acting in accord with the RFCs, which state:
In this case, Public DNS is acting in accord with the RFCs, which state:
Some queries will result in the direct answer plus an "additional" section, containing other helpful data. It's valid (per RFC) to omit that additional section. But in the example you gave above, a service with many IP addresses -- all the A type record for the same name -- is a case where it is specifically forbidden to select /some/ of the answers and return only those. If there are so many A records that they can't all fit, they must all be truncated, and the client is expected to retry over TCP.
ri...@gmail.com
I can't find evidence for the claim in your last paragraph about a requirement to do what you're doing. Moreover the citation you linked (RFC 5966 Section 4) clearly reads:
> Stub resolver implementations MAY omit support for TCP when specifically designed for deployment in restricted environments where truncation can never occur or where truncated DNS responses are acceptable.
This strongly implies that such truncated responses would have useful content. Moreover, all historical implementations do truncation on record granularity not entire RRset granularity.
> Stub resolver implementations MAY omit support for TCP when specifically designed for deployment in restricted environments where truncation can never occur or where truncated DNS responses are acceptable.
This strongly implies that such truncated responses would have useful content. Moreover, all historical implementations do truncation on record granularity not entire RRset granularity.
al...@google.com
I don't think that everywhere a libc implementation could be deployed is a "restricted environment where truncation can never occur". Your original report shows usage in cases where truncation can indeed occur.
RFC 2181 defines what truncated means, and it means when the entire RRSet cannot fit, then the entire set should be omitted, and the TC bit specified. Note the "always return all the records in the associated RRSet" section. Either they are all returned or (if they don't fit) none of them are. Your report also shows that truncated responses are not acceptable.
You appear to be arguing for some form of partial response (like mentioned in 2181 section 5.2, as a bad thing, and specifically not the same as "truncated"). But that's not what the spec tells us to do.
Further, section 9 (of 2181) says that a server MAY leave partial answers in the response, but that when a client sees the TC bit, it must ignore that. The spec is clear: partial responses are not included.
RFC 2181 defines what truncated means, and it means when the entire RRSet cannot fit, then the entire set should be omitted, and the TC bit specified. Note the "always return all the records in the associated RRSet" section. Either they are all returned or (if they don't fit) none of them are. Your report also shows that truncated responses are not acceptable.
You appear to be arguing for some form of partial response (like mentioned in 2181 section 5.2, as a bad thing, and specifically not the same as "truncated"). But that's not what the spec tells us to do.
Further, section 9 (of 2181) says that a server MAY leave partial answers in the response, but that when a client sees the TC bit, it must ignore that. The spec is clear: partial responses are not included.
ri...@gmail.com
The text you seem to be referring to about "should be omitted" seems to be this sentence in section 9: "In such cases the entire RRSet that will not fit in the response should be omitted..." That sentence is about extra information, which should not be included incomplete since it can't be marked as incomplete (TC bit is not allowed to be used unless the *answer* was truncated). This is made clear in the rest of the sentence: "and the reply sent as is, with the TC bit clear".
The following paragraph explicitly allows the behavior I've requested: "Where TC is set, the partial RRSet that would not completely fit may be left in the response." - and this is the behavior of every historical implementation prior to yours. Indeed, as you have said, it goes on: "When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies." However, RFC 5966 makes it clear that an implementation that wants to use a truncated response is free to do so.
Refusing to give a truncated (partial) response is not non-conforming, but it does fail to be friendly to and interoperable with clients that want, *and prefer* the truncated response (because they will not use more answers anyway, even if available). It also deviates from all prior practice.
The following paragraph explicitly allows the behavior I've requested: "Where TC is set, the partial RRSet that would not completely fit may be left in the response." - and this is the behavior of every historical implementation prior to yours. Indeed, as you have said, it goes on: "When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies." However, RFC 5966 makes it clear that an implementation that wants to use a truncated response is free to do so.
Refusing to give a truncated (partial) response is not non-conforming, but it does fail to be friendly to and interoperable with clients that want, *and prefer* the truncated response (because they will not use more answers anyway, even if available). It also deviates from all prior practice.
al...@google.com
I've discussed this with the team.
Our current implementation takes the strict interpretation I've laid out above, but we do see room in the spec, mostly from section 9 (https://tools.ietf.org/html/rfc2181#section-9 ), for sending partial replies.
However, at the current time we are not aware of large or wide-spread enough issues which justify the effort to change at this time.
Our current implementation takes the strict interpretation I've laid out above, but we do see room in the spec, mostly from section 9 (
However, at the current time we are not aware of large or wide-spread enough issues which justify the effort to change at this time.
Description
In particular this issue affects musl libc's stub resolver, and causes false negatives for looking up domains with excessive number of round-robin address results. On the musl side, we are not interested in doing fallback queries over tcp for a stub resolver, since it yields very bad performance. A local caching nameserver that does truncation correctly and uses tcp for upstream queries can work around the issue with less of a performance hit, but it's our view that public-dns servers should just return meaningful truncated results.
What steps will reproduce the problem?
1. Send UDP DNS A query for a name with a large number of A records, e.g.
2. Receive and inspect reply.
What is the expected output?
Packet with TC bit set, length near or equal to 512, and many A records in the answer section.
What do you see instead?
Packet with TC bit set, length equal to query packet length, and zero records in answer section.