[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
DNS Flag Day, Friday, Feb 1st, 2019
> On 1 Feb 2019, at 3:32 am, James Stahr <stahr at 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â?¦
- References:
- DNS Flag Day, Friday, Feb 1st, 2019
- From: Brian at ampr.org (Brian Kantor)
- DNS Flag Day, Friday, Feb 1st, 2019
- From: mpetach at netflight.com (Matthew Petach)
- DNS Flag Day, Friday, Feb 1st, 2019
- From: jimpop at domainmail.org (Jim Popovitch)
- DNS Flag Day, Friday, Feb 1st, 2019
- From: morrowc.lists at gmail.com (Christopher Morrow)
- DNS Flag Day, Friday, Feb 1st, 2019
- From: marka at isc.org (Mark Andrews)
- DNS Flag Day, Friday, Feb 1st, 2019
- From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean)
- DNS Flag Day, Friday, Feb 1st, 2019
- From: mpetach at netflight.com (Matthew Petach)
- DNS Flag Day, Friday, Feb 1st, 2019
- From: marka at isc.org (Mark Andrews)
- DNS Flag Day, Friday, Feb 1st, 2019
- From: stahr at mailbag.com (James Stahr)