Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
(Choosing DNS-operations.) On 3/13/15, 18:21, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: IANAL, but I think this might have legal ramifications. If they are advertising/selling DNS services and what they are delivering is not DNS, then Truth in Advertising and/or Bait-and-Switch statutes, regulations and/or treaty provisions may apply. ... Having worked in the same market - that point won't win any arguments. Whether you are substantively right or not, it won't win any arguments. Why? There is a class of customers that don't take the time to know what compliant DNS is. There is a class of customers with engineering staffs that prefer the vendor be non-standard for their own sake. There is a class of customers that don't care as much about standards but more about whether they can switch to someone else. I've never seen a case of a customer that claimed the service was deficient because it was counter to a standard or RFC. I have seen the reverse, a customer getting mad because a service was brought in line with specifications, I've had to roll back to non-standard behavior. This may be an unfair response because sometimes non-standard behavior is considered a bug and remedied. smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
In message 55077a64.7050...@brokendns.net, Michael Sinatra writes:
On 3/16/15 4:15 PM, P Vixie wrote:
On March 17, 2015 7:42:09 AM GMT+09:00, Michael Sinatra michael@brokendns.
net wrote:
On 03/16/15 07:23, bert hubert wrote:
Separately, I fail to see why we actually need to outlaw ANY queries
when we
can happily TC=1 them.
If the public recursives also support TC=1 on all ANY queries, then
this
works. If not, the issue arises where just-below-the-radar attacks are
using many public recursives, in which case you're not stopping much.
Michael, what attacks do you think we can stop by limiting ANY? Paul
The attack that I have had to grapple with is this:
* Someone sets up a bot to query public recursives (google, opendns,
level3, etc.) for a particular domain whose ANY response is large.
(This _usually_ means DNSSEC-signed.)
* The query from each client,domain,qtype tuple is just barely slow
enough not to trigger rate limiting from the public recursive service.
* The backend of the public recursive service queries my authoritatives
for some of the involved domains. Suppose the response is just under
the usual typical default EDNS0 buffer size of 4096.
* These domains are DNSSEC-signed with NSEC3. Many tools set the TTL of
NSEC3PARAM to 0 when signing zones with NSEC3. The NSEC3PARAM RR is
part of the ANY response.
* The public recursive servers use an implementation that clears all
records from the cache when the TTL of one record expires, so the next
time the recursive server gets an ANY query, it must re-query the
authoritative server.
In this situation, if I set TC=1 for all ANY queries on my authoritative
server, but the public recursives don't, then the victim still gets hit
with a pretty big amplification attack, and my authoritative servers get
hammered with TCP queries. It's annoying for me--not insurmountable,
but annoying, as the thousands of simultaneous TCP connections require
some tuning to manage reasonably. But for the victim? Who knows--I
can't see who the victim is in this case. The more I tune my servers,
the more data gets likely thrown at the victim.
I have seen this in the wild, even where the response is bigger than
4096, so the TC bit should be set all around. Note also that if my
response is bigger than 4096, I'll send an empty response back with TC=1
(I am using BIND-latest). I have seen some recursive implementations (e.g.
unbound) that will dutifully send the victim everything right up to the
next RRset that would push it over 4K and set TC=1 for good measure. So
the victim still gets a ~4000-byte UDP response, even with TC set.
So my point is that if we're going to specify TC=1 for ANY queries, it
has to be mandatory, and all implementations have to handle it the same:
Send an empty NOERROR and set TC=1. If I am the only one setting TC=1,
it won't doing any good for the attack described above, even if my
domains are the ones being used in the attack.
The other option is to allow the authoritative servers to control what
gets set out in response to QTYPE=ANY. But I see devils in the details,
just as with NOTIMP and other proposals.
michael
___
DNSOP mailing list
dn...@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Lets get DNS cookies finalised so that TC=1 isn't needed for repeat
legitimate clients. There is a open question about whether the
error field is needed or not and I'm of the opinion that it isn't
needed.
TC=1 for amplification suppression should be triggered by response
size and whether you are a known repeat client or not rather than
{meta} query type.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
bert hubert mailto:bert.hub...@netherlabs.nl Monday, March 16, 2015 11:23 PM On Mon, Mar 09, 2015 at 04:18:12PM +0100, bert hubert wrote: On Mon, Mar 09, 2015 at 11:08:03AM -, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. (...) Do you think I read 4.3.2 wrong? Or is there another RFC that updates the algorithm? Thanks to some clarification from Dan, I now understand that one can indeed rely on ANY queries to resolvers to either deliver a CNAME or no CNAME, in which case there is no CNAME. i'd like to see those clarifications. if any non-CNAME RRset had existed and been cached, and then replaced by a CNAME, then ANY would not see the CNAME until the last non-CNAME RRset had expired from that cache. which is why, when i want to know if there is a CNAME, i ask if there's a CNAME. i realize that this only matters when the non-CNAME TTL's are one to two weeks long, and weren't trimmed before replacement with the CNAME. however, that situation is common enough that i dispute the phrase quoted above, guaranteed to work by mandatory DNS standards. Separately, I fail to see why we actually need to outlaw ANY queries when we can happily TC=1 them. TC=1'ing them would be a way to prevent them from being used as an amplifying reflector. that is not the use case for this. the updated document makes clear that the iteration complexity in split-authority systems having a lightweight front end, is the situation where ANY is painful. there never was an ANY-related problem for which TC=1 was the solution. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
On Mon, Mar 16, 2015 at 11:53:17PM +0900, Paul Vixie wrote: that is not the use case for this. the updated document makes clear that the iteration complexity in split-authority systems having a lightweight front end, is the situation where ANY is painful. Sorry? We solve implementation hardship by standards action now? Some modern Authoritative servers, such as those used by CDN's, do not have DNS zones. For those servers answering ANY query truthfully is hard work. Thus ignoring ANY queries simplifies the implementation. Is this really all there is to the story? Seriously? I have lots of respect for Olafur, but this does seem to turn a local challenge into a global standards action.. Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
bert hubert mailto:bert.hub...@netherlabs.nl Tuesday, March 17, 2015 12:05 AM Sorry? We solve implementation hardship by standards action now? as with client-subnet, we recognize that people will do what they want, or stop doing what they don't want, especially if they are CDN providers with a lot of revenue and a lot of expense riding on their choices. i don't love this situation but i can tell you that quoting specifications at folks and using words like mandatory isn't the way to change their minds (or their deeds.) noting that there's a more-than-ten-years-old CNAME patch to qmail that just about everybody is supposedly running, i expect the operational impact of phasing out ANY to be ~0. also, a lot of operators foolishly patched their BIND servers to stop answering ANY because they considered it a DDoS risk (which is patently insane but please don't shoot the messenger) and not a single qmail user was heard from on the matter. the internet works by cooperation. often, first mover advantage is sticky. but almost as often, somebody like the mozilla dev team decides that something like ANY is the solution to their API layering problem, and the rest of us rip the bandaids off and study the underlying wound. so it is in this case. now, mozilla has backed off, but the underlying wound remains a visible topic of conversation. to me the use case is, it's an information leak, and i don't want my cache probed, and i can't tell the difference between a cache prober and qmail, so into the same stew pot they both must go. (along with RD=0 on an RA=1 server.) -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
On Thu, Mar 12, 2015 at 4:09 PM, Mark Andrews ma...@isc.org wrote: In message 3d558422-d5da-4434-bded-e752ba353...@flame.org, Michael Graff writes: What problem are we specifically trying to solve here again? A non-problem for most of us. Michael If one really wants to reduce the number of packets required with SMTP processibg just write a RFC that says A and records should be returned in the additional section if no MX records exist at the qname. This is currently permitted so vendors could do this today. For some data; Route 53 does do this for MX, NS, SRV and CNAME. It's never been a problem, and does seem to speed up processing a little. -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
According to their own statement, Cloudflare perceived the problem to be the code-complexity of their DNS implementation -- in particular, they characterized the complexity of their (former) QTYPE=*-handling code as enormous. Their fix was to feign ignorance (RCODE=NOTIMP) of QTYPE=* and thus -- as I and others interpret it -- fall out of compliance of any reasonable reading of RFC 1034/1035. IANAL, but I think this might have legal ramifications. If they are advertising/selling DNS services and what they are delivering is not DNS, then Truth in Advertising and/or Bait-and-Switch statutes, regulations and/or treaty provisions may apply. They could avoid this fate, of course, by rebranding their name-resolution service as something other than DNS (Cloudnameserviceflare?), even though coincidentally it runs on port 53 and in all respects other than QTYPE=* responses looks and quacks a lot like DNS. Of course, IETF is not the FTC, nor is it the WTO. What can we do? There seems to be a diversity of opinion on this: The standards-purists want to render an opinion that Cloudflare's implementation has forsaken standards-compliance, and let those chips fall where they may, legally or otherwise. The accommodationists want to come up with a smarter or cleverer way for Cloudflare (and undoubtedly others to follow) to frustrate QTYPE=* queries in a way that causes as little wreckage as possible. Not sure how they hope to achieve that, if anything beyond return(DNS_RCODE_NOTIMP) qualifies as enormous code-complexity to the Cloudflare folks... Cloudflare justifies their action, in part, by making the questionable claim The original reason for adding the ANY to DNS was to aid in debugging and testing. Whatever other action may or may not be taken by the IETF, since only IETF has the institutional memory to definitively confirm or deny this claim, I think it is worthy of a response. - Kevin -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Randy Bush Sent: Friday, March 13, 2015 6:28 AM To: Michael Graff Cc: dn...@ietf.org; D. J. Bernstein; dns-operati...@dns-oarc.net Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards What problem are we specifically trying to solve here again? not break things that are working randy ___ DNSOP mailing list dn...@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
Packet size is harder to analyze. ANY often pulls some records that aren't used, and if the site isn't configured carefully then ANY can even end up falling back to TCP, costing bytes _and_ packets. On the other hand, there are a huge number of Internet sites that don't have a noticeable volume of unusual records and don't need TCP, and there's a clear traffic win for every skipped query and skipped no-data response. My guess is that with DNSSEC, this will be common, as often times the domain apex is where the email would be sent. For my personal domain, that’s @flame.orghttp://flame.org, and weighs in at 1758 bytes to an ANY query right now. Once this is done, the MX target then needs to be followed of course (or targets in the case of a failure to connect.) In the following, I’m using ESND0. If this isn’t true, we all know anything 512 bytes as a response was a TCP hit. I’m not as scared of TCP hits as others may be, but I do think they should be avoided when practical. ANY comes in as 1769 with or without DNSSEC. Had it asked for the MX directly, it would have gotten 60 bytes without DNSSEC, and 229 with. If there was no MX record, I assume then another query would be issued for the and A records. That’s two more queries, but both of which would be smallish in comparison to the ANY query. The DNSSEC keys nearly always dominate ANY queries at the apex. I’m happy we are discussing issues with ANY queries, and the fairly small number of clients that use them. I would have to see hard numbers collected over a lot of data showing where the ANY query was actually better than following the MX, , A path. Until data is collected from how people set up zones today, I’m not sure I can say one is better than the other, other than as a feeling that it might help reduce queries but I’m not sure it reduces bandwidth. What problem are we specifically trying to solve here again? —Michael ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
In message 3d558422-d5da-4434-bded-e752ba353...@flame.org, Michael Graff writes: What problem are we specifically trying to solve here again? A non-problem for most of us. Michael If one really wants to reduce the number of packets required with SMTP processibg just write a RFC that says A and records should be returned in the additional section if no MX records exist at the qname. This is currently permitted so vendors could do this today. Alternatively change SMTP processing to not fallback to A / on no MX. Set a date several years out my which all sites that accept email need to publish a MX record. This really should have been done years ago. Instead we have null-MX to signal that there isn't a SMTP server. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: Regarding the statement query type ANY 'matches all RR types CURRENTLY IN THE CACHE'. Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior It is sort-of specified in the algorithm in section 4.3.2 which says, 4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. That applies to RD=0 queries. For RD=1, section 5.3.3 says, 1. See if the answer is in local information, and if so return it to the client. This is usually understood to mean what you would get from an RD=0 query. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Northwest Fitzroy, Sole: Southwesterly, backing southeasterly for a time, 4 or 5 increasing 6 to gale 8. Moderate or rough, becoming very rough later in west. Occasional rain, fog patches. Moderate or good, occasionally very poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
Regarding the statement query type ANY 'matches all RR types CURRENTLY IN THE CACHE'. Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior -- Section 3.7.1 says only that a QTYPE of * matches all RR types, whereas Section 5.3.3 (Algorithm) says to return the answer or the data if it's in the cache, but this is ambiguous with respect to QTYPE=* (other than the highly-improbable case that we have RRsets for every possible RR type, how can we know we have the answer/the data in our cache, given that the QTYPE matches all RR types at the node and there might be other RRsets extant which don't happen to be cached at the time? Is an answer really the answer if we can't be sure that it satisfies the matching rule of the QTYPE definition?). People cite the examples of Section 6.2.2 as definitive evidence that QTYPE=* queries can always be satisfied by whatever happens to be laying around in a cache, but they don't seem to notice that those were *non-recursive* queries in the examples, and it's their *non-recursiveness* that gives rise to the lack of rigor in returning a response (as it is whenever a non-recursive query is sent to a DNS entity that doesn't happen to be authoritative for the relevant zone). The required fetching behavior of a caching resolver in response to a *recursive* QTYPE=* query, is basically undefined by RFC 1034. Common practice is to treat QTYPE=* queries as effectively non-recursive, despite RD being set to 1, if *any* relevant RRset exists in the cache. Possibly, this is because the Section 6.2.2 examples were misunderstood. Or, simply because it was easier to code that way. A more modern concern would be that this rigor could be abused for possible DoS attacks. But, at this point in D! NS history, I doubt we can roll back the clock and force everyone to be rigorous in fetching answers for QTYPE=* queries. So the answers are inherently unreliable, and that situation is not likely to change, unless and until someone invents an ALL QTYPE/RR-type/meta-type. - Kevin -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Wouters Sent: Monday, March 09, 2015 10:48 AM To: D. J. Bernstein Cc: dn...@ietf.org; dns-operati...@dns-oarc.net Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards On Mon, 9 Mar 2015, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. And you've been told for two decades that this was wrong? Specifically, query type ANY matches all RR types for that node on that server. Wrong, query type ANY matches all RR types CURRENTLY IN THE CACHE. So the result of qmail's ANY query is completely meaningless and qmail cannot derive any conclusion from the absence of any record from that query. So if the MX or record has expired from the cache but another RRtype with larger TTL (say NS) is still in there, your ANY query will fail to find records. qmail with this feature is broken. Additionally, Tony Finch did a write up of qmail's ANY problems too: https://fanf.livejournal.com/10.html In new software today I would sacrifice these efficiency benefits for the sake of simplicity, but this doesn't mean that I'm going to frivolously inflict retroactive punishment upon administrators who have installed standards-compliant software and done nothing wrong. You have had 10 years to fix it. Luckilly, I believe most distributions shipping qmail add the patch to fix this already. I understand how a sufficiently large site might acquire the impression that it can safely take radical action at its own whim, violating the existing protocol standards Uhm, we pointd out qmail's _bug_ for a decade. I'm quite sure even you do not need to interop with BIND4 anymore. Apparently Firefox recently deployed ANY queries. I haven't looked at the details but I gather that they're related to the well-known annoyances of handling etc. Firefox was browbeaten into reverting this change on the basis of highly questionable claims regarding amplification: It can return enormous result sets, and some authoritative servers have taken to refusing ANY queries because of the frequency with which such queries show up in amplification attacks - I'm concerned about amplification and the perception thereof by security monitors. No, they were also told that ANY queries only return data from the cache, and using ANY queries means you might miss actual A or records. This has nothing to do with ANY queries and amplification. The common theme of CNAME/MX/A and A/ is that there's widepread interest in being able to easily retrieve multiple record types. What I'm saying
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
On Mon, 9 Mar 2015, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. And you've been told for two decades that this was wrong? Specifically, query type ANY matches all RR types for that node on that server. Wrong, query type ANY matches all RR types CURRENTLY IN THE CACHE. So the result of qmail's ANY query is completely meaningless and qmail cannot derive any conclusion from the absence of any record from that query. So if the MX or record has expired from the cache but another RRtype with larger TTL (say NS) is still in there, your ANY query will fail to find records. qmail with this feature is broken. Additionally, Tony Finch did a write up of qmail's ANY problems too: https://fanf.livejournal.com/10.html In new software today I would sacrifice these efficiency benefits for the sake of simplicity, but this doesn't mean that I'm going to frivolously inflict retroactive punishment upon administrators who have installed standards-compliant software and done nothing wrong. You have had 10 years to fix it. Luckilly, I believe most distributions shipping qmail add the patch to fix this already. I understand how a sufficiently large site might acquire the impression that it can safely take radical action at its own whim, violating the existing protocol standards Uhm, we pointd out qmail's _bug_ for a decade. I'm quite sure even you do not need to interop with BIND4 anymore. Apparently Firefox recently deployed ANY queries. I haven't looked at the details but I gather that they're related to the well-known annoyances of handling etc. Firefox was browbeaten into reverting this change on the basis of highly questionable claims regarding amplification: It can return enormous result sets, and some authoritative servers have taken to refusing ANY queries because of the frequency with which such queries show up in amplification attacks - I'm concerned about amplification and the perception thereof by security monitors. No, they were also told that ANY queries only return data from the cache, and using ANY queries means you might miss actual A or records. This has nothing to do with ANY queries and amplification. The common theme of CNAME/MX/A and A/ is that there's widepread interest in being able to easily retrieve multiple record types. What I'm saying is not that query type ANY is the ultimate answer (clearly it can be improved); what I'm saying is that these are protocol issues, and that protocol changes need to be handled by an appropriately chartered IETF working group. I agree there is a use for this. I tried a few years ago to introduce a new EDNS0 option that would allow you to query for a bitmap number of RRsets, but people did not like it. Perhaps the WG is ready for something like this now. Paul ___ DNSOP mailing list dn...@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
bert hubert bert.hub...@netherlabs.nl wrote: On Mon, Mar 09, 2015 at 11:08:03AM -, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. The way I read RFC 1034 4.3.2, this is not true. In step 4 we match whatever we find in the cache, put it in the packet, and move on to step 6. This means the algorithm might terminate returning only an A record or only an record. Or a TXT record for that matter. This reading of 4.3.2 makes 'ANY' queries to resolvers fragile. It might not return what you need. Dan is aware of that, but this particular oddity isn't a problem for qmail. Later in his message he wrote: Of course, there's no guarantee of which RR types for a node are available at a cache, but a client is guaranteed to be able to detect CNAME records from responses to query type ANY (as qmail does), since a CNAME type prohibits all regular RR types. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle: Southeast veering west, severe gale 9 to violent storm 11. Very rough or high, becoming very high for a time. Rain then showers. Moderate or poor, becoming good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards
My 2 cents... It is commonplace, these days, to clearly enumerate MANDATORY TO IMPLEMENT elements of a protocol specification. But, this was not the typical practice at the time RFCs 1034/1035 was written, and I don't think we can apply modern standards-parlance retroactively. RFC 1034/1035 certainly marked some protocol elements as optional or experimental, e.g. - inverse query opcode (optional) - the MG, MINFO, MR and NULL RR types (experimental) - negative-caching via the inclusion of an SOA RR in the Additional Section of the response (optional) yet, none of the QTYPEs defined in the RFCs are so labelled. In the face of such circumstantial evidence, I would say that conformance to RFCs 1034/1035 requires implementation, to some degree, of all QTYPEs defined in those RFCs, That, to me, is a reasonable reading of the document. RCODE=NOTIMP exists, ergo any/all QTYPEs which aren't also RR types[1], are optional to implement is not, IMO, a reasonable reading, but admittedly, the MANDATORY TO IMPLEMENT construct probably came into vogue in the first place, to forestall any such shaky interpretations. Now, having said that, I think it would be standards-conforming for an implementation to always answer with RCODE=REFUSED, always answer with NODATA, or to pick only certain RR types, more-or-less arbitrarily, (e.g. A and ) and only answer with RRs matching those RR types (as a way to minimize the amplification effect), in response to QTYPE=* queries. None of those would be violations of the standard, which in no way usurps local administrative control over what queries get substantive responses, versus those which do not, nor commits an implementation to rigorously tracking down *every* RRset owned by the QNAME of a given QTYPE=* query. But, I have to agree with Dan: NOTIMP in response to QTYPE=* is not standards-conforming. As for his meta-argument that DNSOP cannot make changes to the protocol, I'm still mulling that one over, in light of the charter language. - Kevin [1] The reason for the which aren't also RR types qualification is that RFC 1123, Section 6.1.3.5 states that DNS software MUST support all well-known, class-independent formats [sic]. While 1123 is silent on QTYPEs, _per_se_, at least the set of [QTYPEs that are also well-known, class-independent RR types], as of the date of 1123's publication, fall within mandatory-to-implement, and there is no need to debate over those. -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of David C Lawrence Sent: Monday, March 09, 2015 12:24 PM To: dn...@ietf.org; dns-operati...@dns-oarc.net Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards RFC 1035 explicitly allows for a server to indicate that a kind of query is not implemented. Whether it is a good idea to respond to ANY this way is a separate argument that is worth having. You just won't win on the foundation that it is a violation of the standard. ___ DNSOP mailing list dn...@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
