Re: DNS Flag Day, Friday, Feb 1st, 2019

[Mark Andrews <marka () isc org>]

> On 1 Feb 2019, at 3:32 am, James Stahr <stahr () mailbag com> wrote:
>
> On 2019-01-31 08:15, Mark Andrews wrote:
>
> > We actually have a hard time finding zones where all the servers are
> > broken enough to not work with servers that don’t fallback to plain
> > DNS on timeout.  We can find zones where some of the servers are like
> > that, but there is usually one or more servers that do respond
> > correctly.
> > Of the datasets I’ve looked at that 1 in 10,000 to 1 in 100,000 zones
> > will have problems with updated servers.
>
> I think the advertised testing tool may be flawed as blocking TCP/53 is enough to receive a STOP from the dnsflagday 
> web site.  It's been my (possibly flawed) understanding that TCP/53 is an option for clients but primarily it is a 
> mechanism for the *server* to request the client communicate using TCP/53 instead - this could be due to UDP response 
> size, anti-spoofing controls, etc…

DNS is defined to be both TCP and UDP.  Blocking TCP has no real security benefit and comes from the MYTH that TCP is 
ONLY used for zone transfers.  Way too many times people have blocked TCP then have those same servers return TC=1 
which say USE TCP as the answer is TOO LARGE TO FIT IN UDP.

                        Foot, Gun, Shoot.

If you have a DNSSEC zone then TCP is effectively MANDATORY as clients still need to be able to
get answers from behind a firewall that is enforcing a 512 byte limit.  If you are running a recursive
server TCP is effectively MANDATORY as you have no control over the RRset size.  Lots of referrals REQUIRE TCP as the 
GLUE records are not OPTIONAL in a referral.  Yes, BIND has been setting TC=1 on referrals for MANY years now when it 
is required, it should be setting it on many more. So if you want WORKING DNS you do not block TCP.  Other DNS vendors 
also set TC=1 on some referrals.  This means if you are hosting third party content then TCP is effectively MANDATORY 
as you have no content control.

RFC 1123 said that DNS/TCP is a SHOULD where SHOULD is defined as

         *    "SHOULD"

              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

I’ve yet to see anyone who has TCP blocked actually know all the places in the DNS protocol where doing so will cause 
things to break.  None of them have done the necessary homework to actually exercise the SHOULD.  There are lots of 
lemmings when it comes to DNS practices.  All implementations of DNS are REQUIRED to support DNS/TCP.

The DNS flag day site flags servers without TCP as broken which they *are*.  Whether it should be red or orange is a 
matter for debate.

A referral that in bigger than 512 bytes without involving DNSSEC.

[beetle:~/git/bind9] marka% dig example.net @a.root-servers.net

; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> example.net @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54567
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;example.net.                   IN      A

;; AUTHORITY SECTION:
net.                    172800  IN      NS      a.gtld-servers.net.
net.                    172800  IN      NS      b.gtld-servers.net.
net.                    172800  IN      NS      c.gtld-servers.net.
net.                    172800  IN      NS      d.gtld-servers.net.
net.                    172800  IN      NS      e.gtld-servers.net.
net.                    172800  IN      NS      f.gtld-servers.net.
net.                    172800  IN      NS      g.gtld-servers.net.
net.                    172800  IN      NS      h.gtld-servers.net.
net.                    172800  IN      NS      i.gtld-servers.net.
net.                    172800  IN      NS      j.gtld-servers.net.
net.                    172800  IN      NS      k.gtld-servers.net.
net.                    172800  IN      NS      l.gtld-servers.net.
net.                    172800  IN      NS      m.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.     172800  IN      A       192.5.6.30
b.gtld-servers.net.     172800  IN      A       192.33.14.30
c.gtld-servers.net.     172800  IN      A       192.26.92.30
d.gtld-servers.net.     172800  IN      A       192.31.80.30
e.gtld-servers.net.     172800  IN      A       192.12.94.30
f.gtld-servers.net.     172800  IN      A       192.35.51.30
g.gtld-servers.net.     172800  IN      A       192.42.93.30
h.gtld-servers.net.     172800  IN      A       192.54.112.30
i.gtld-servers.net.     172800  IN      A       192.43.172.30
j.gtld-servers.net.     172800  IN      A       192.48.79.30
k.gtld-servers.net.     172800  IN      A       192.52.178.30
l.gtld-servers.net.     172800  IN      A       192.41.162.30
m.gtld-servers.net.     172800  IN      A       192.55.83.30
a.gtld-servers.net.     172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net.     172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net.     172800  IN      AAAA    2001:503:83eb::30
d.gtld-servers.net.     172800  IN      AAAA    2001:500:856e::30
e.gtld-servers.net.     172800  IN      AAAA    2001:502:1ca1::30
f.gtld-servers.net.     172800  IN      AAAA    2001:503:d414::30
g.gtld-servers.net.     172800  IN      AAAA    2001:503:eea3::30
h.gtld-servers.net.     172800  IN      AAAA    2001:502:8cc::30
i.gtld-servers.net.     172800  IN      AAAA    2001:503:39c1::30
j.gtld-servers.net.     172800  IN      AAAA    2001:502:7094::30
k.gtld-servers.net.     172800  IN      AAAA    2001:503:d2d::30
l.gtld-servers.net.     172800  IN      AAAA    2001:500:d937::30
m.gtld-servers.net.     172800  IN      AAAA    2001:501:b1f9::30

;; Query time: 375 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Fri Feb 01 07:54:44 AEDT 2019
;; MSG SIZE  rcvd: 833

[beetle:~/git/bind9] marka% 

> So is the tool right in saying that TCP/53 is a absolute requirement of ENDS0 support for "DNS Flag Day"?  If so, do 
> we expect a dramatic increases in TCP/53 requests over UDP/53 queries?  Or is the tool flawed in its' claim that the 
> DNS Flag Day changes *require* TCP/53 in order to resolve ones domain?  Based upon my reading, the big concern is a 
> edns=timeout result (from the ISC tool) not a edns512tcp=timeout.
>
>
> While I applaud the effort, the message and delivery could have been better. My first read on DNS Flag Day was that 
> this was going to be the day new software versions were to be released which deprecated EDNS0 fallback measures so 
> the adoption would be a gradual process by updating the latest versions of several DNS servers, only to find out that 
> many resolvers used by end users use will be upgrading on Feb 1rst.  Now, it sounds like the rollout schedule is on 
> their timetable and could happen over the next several weeks and months.  So really not a Flag "Day" now is it? I 
> guess that's also why the date being on a Friday also isn't really a concern...
>
> Finally, why has no one stepped up to setup an updated resolver prior to Feb 1rst for actual testing? Or are there 
> instructions on how one could setup their own resolver setup prior to Feb 1rst?  No offense, but I'm not jumping to a 
> brand new train of code just to enforce DNS Flag Day but I might choose enforce now under *existing* code bases 
> rather than waiting for everyone else using Cloudflare/Google/OpenDNS as resolver may see me after Feb 1rst?   If 
> anyone has such instructions, post them - or put them on dnsflagday.net for anyone else wanting to adopt/test.  Just 
> some thoughts…

From the DNS flag day site:

DNS resolver operators

On or around Feb 1st, 2019, major open source resolver vendors will release updates that will stop accommodating 
non-standard responses. This change will affect authoritative servers which do not comply either with the original DNS 
standard from 1987 (RFC1035) or the newer EDNS standards from 1999 (RFC2671 and RFC6891). Major public DNS resolver 
operators listed below are also removing accommodations so this change will also impact Internet users and providers 
who use these public DNS services.

Sites hosted on incompatible authoritative servers may become unreachable through updated resolvers. The web form above 
diagnostic tool may be helpful while investigating problems with a particular domain. Domains which repeatedly fail the 
test above have problems with either their DNS software or their firewall configuration and cannot be fixed by DNS 
resolver operators.

The following versions of DNS resolvers will not accommodate EDNS non-compliant responses:

        • BIND 9.13.3 (development) and 9.14.0 (production)
        • Knot Resolver has already implemented stricter EDNS handling in all current versions
        • PowerDNS Recursor 4.2.0
        • Unbound 1.9.0

Now BIND 9.13.3 became public on 2018-09-19 and the Knot Resolver are already public. You can lookup PowerDNS and 
Unbound to see if they are public.

> -- 
> -James

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka () isc org