> On 1 Feb 2019, at 3:32 am, James Stahr <st...@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: ma...@isc.org
