Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-no-response-issue-20: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

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 <[e-mail]>
Date: Tuesday, 14 April 2020 at 02:15
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, Tim Wicinski <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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 <[e-mail]> 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
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/dnsop
    
    -- 
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: [phone]              INTERNET: [e-mail]