Mark Thank you for your detailed answers. They make sense (and I learned quite a bit in the same shot)
Regards -éric -----Original Message----- From: Mark Andrews <[email protected]> Date: Tuesday, 14 April 2020 at 02:15 To: Eric Vyncke <[email protected]> Cc: The IESG <[email protected]>, Tim Wicinski <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-no-response-issue-20: (with COMMENT) > On 9 Apr 2020, at 00:16, Éric Vyncke via Datatracker <[email protected]> wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-dnsop-no-response-issue-20: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. I also like the extensive test > scenarios with 'dig' ;-) > > To be honest, I was about to ballot a DISCUSS as I have some doubts whether the > objective of removing non-compliant servers (end of section 2) is achievable... > Too many non-compliant servers, probably managed by clueless people. But, hey, > we can always try! Lots have been removed over the last couple of years. DNS flag day in Feb 2019 caused lots of vendors to issue fixed. You can see where different vendors have fixed their products and operators have updated. Look around https://ednscomp.isc.org/ > I also wonder why this document is a generic BCP while section 8 and other > parts seem to indicate more like a testing of servers. Balloting NO OBJECTION > but also long hesitation for a DISCUSS. > > Please address the nits found by Carlos during the INTDIR review: > https://mailarchive.ietf.org/arch/msg/int-dir/wfKo4vDmFJwPa1HeDY9wxP2JdEA (at > least one nit is already addressed, thank you) Both of the items listed where addressed though I don’t know why xml2frc left three spaces inside a <t> block as 3 spaces in the resulting .txt file. > Please find below some non-blocking COMMENTs and NITs. An answer will be > appreciated. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > Generic: the objective of this document is a little unclear to me, is it to do > compliance testing/certification specific DNS server software ? or to actual > DNS servers on the Internet. Both, I know some TLD operators are intending to use this to test delegated servers. I’ve been testing different populations of servers for last 4+ years to see trends and yes they are improving. DNS vendors can use the tests as part of their QA process. > -- Section 1 -- > Suggest to also add middle-box dropping EDNS in the sentence "Due to the > inability to distinguish between packet loss and nameservers dropping EDNS" > (see section 4). Added. > -- Section 4 -- > Why limiting the middle boxes to only firewalls and load balancers? There are > many different types of middle-box (NAT, ...) also doing "packet massaging" on > the fly... :-( Yep, CISCO’s “dns fixup” invariable needs to be disabled if it is on in front of a DNS server as all it does is damage and as far as I can tell no good. Transparent DNS Proxies that aren’t. You can’t just redirect port 53 traffic at a recursive DNS server and have it will all work. There are iterative clients and there are TSIG and SIG(0) signed DNS requests at a minimum to deal with. The later the recursive server can’t fake a legitimate response to. Iterative clients can be faked out by recursing even though RD is 0 and setting AA to 1 on the response. NAT’s that don’t do TCP but pass back TC=1 responses. There will always be more way people break DNS. > -- Section 10 -- > The security considerations is rather weak... > > If the intent is to probe Internet servers, then why not adding some text > around 'do it only with prior agreement of the DNS servers operator’ ? Have you every tried to contact a DNS service operator? Whois has been gutted. SOA contact field are bogus. Websites don’t have working contact points when there is a website matching the DNS server. You are lucky if you can reach 10% of them. The requests only match those that are currently being sent by recursive servers or can legitimately be expected to be sent in the future. EDNS options are sent without prior agreement today. Bumping the EDNS version in the request shouldn’t require prior agreement as all EDNS aware servers should be expecting it (the expected behaviour is specified) and for those that aren’t the EDNS version doesn’t matter. New types requests are being sent all the time. New opcodes have occurred twice already so its not like DNS servers vendors shouldn’t be expecting them to happen in the future. NOTIFY messages (a opcode that didn’t exist in RFC 1034/1035) are sent by authoritative to other authoritative servers and there was never any pre-agreement on doing so but it did make handling the responses (or the lack of them) more complicated. UPDATE requests can also potentially be sent without prior agreement (it would actually make sense to update PTR records using UPDATE over TCP rather than pre-populating zones with a TIMEOUT record, currently a I-D, to remove it if not refreshed, thats every machine doing it). I’d like to make it so that the next time any of these sort of events happen, and they will, recursive server operators aren’t fighting broken servers and poorly configured firewalls etc. Same to when stub resolver use more that minimal DNS features to talk to recursive servers. > Also, if the firewall is "protecting" the DNS server (cough cough), then as a > security officer I would prefer to block all unknown opcodes/types at the > firewall (possibly with a reply). And the harm in asking is what? Oh, you don’t have a AAAA record or a TLSA record or a type1001 record. It took 10 to 15 years before AAAA lookups stopped being blocked because it was “unknown” despite the type being defined for over a decade, in the meantime clients that where trying to look up the records ended up waiting several seconds every time they attempted to connect to your website. You where “safe” but you where losing business because your web servers appeared to be slow. You blocked TLSA lookups so the email to you queued for 3 days before bouncing back to the sender as undeliverable. Negative answers are just as important as positive answers to keep things working. Of all the DNS types defined in the last 40 years is there a single one that is truely dangerous? Even ANY isn’t amplifier as long as you have had a three way handshake be it using TCP or DNS COOKIE. Modern DNS server set TC=1 for ANY and that moves the query to TCP for legitimate clients. Some clients default to TCP for ANY queries to avoid the extra transaction. Mark > == NITS == > > -- section 2 -- > Please add an expansion or a reference to "AD flag bit". (and in my non-native > English speaker, it is a pleonasm). > > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
