Quoting from the web site at https://dnsflagday.net/
What is happening?
The current DNS is unnecessarily slow and suffers from inability
to deploy new features. To remediate these problems, vendors of
DNS software and also big public DNS providers are going to
remove certain workarounds on February 1st, 2019.
This change affects only sites which operate software which is
not following published standards. Are you affected?
On that web page, there is a Domain Owner's test. You can enter
a domain name and click 'test' and shortly receive a report of
what was found regarding your domain's DNS servers.
I somehow managed to miss the announcement of this upcoming event,
even though I read this mailing list fairly closely. Perhaps it
was announced somewhere else instead. I think it needs to be
mentioned here if it hasn't already been.
- Brian
I’ve been complaining for YEARS about lack of EDNS compliance.
If you run really old Windows DNS servers you are broken.
If you run a firewall in front of your DNS server you may be broken.
If you are QWEST you are broken.
Mark
huh, from the ‘dns illuminati’ eh"
DNS hosted by gandi.net? resolves to 3 /32’s on 3 adjacent /24’s… in github’s ip space, routed by fastly.com …
I’m sure glad the whois data for that domain is sensible too… 
none of that particularly leaves me feeling like I should go put any data at all into the site.
-chris
Well you can go to https://ednscomp.isc.org and click on "Test Your Servers Here”
which is what https://dnsflagday.net calls behind the scenes. You will just need
to interpret the results as they apply to DNS flag day. If you don’t want to go
there you can go to https://gitlab.isc.org and down load and compile the DNS
compliance tester and then run “genreport -i bind11 -e”. which is the actual test
code being run.
But hey you did do proper acceptance testing when you installed your DNS servers
and firewalls to ensure that they implemented the DNS protocol correctly and they
your firewalls don’t block well formed DNS queries (lots of them do by default).
Mark
Well you can go to https://ednscomp.isc.org and click on "Test Your Servers Here”
which is what https://dnsflagday.net calls behind the scenes. You will just need
to interpret the results as they apply to DNS flag day. If you don’t want to go
there you can go to https://gitlab.isc.org and down load and compile the DNS
compliance tester and then run “genreport -i bind11 -e”. which is the actual test
code being run.
oh excellent, I’ll do this version. thanks.
But hey you did do proper acceptance testing when you installed your DNS servers
and firewalls to ensure that they implemented the DNS protocol correctly and they
your firewalls don’t block well formed DNS queries (lots of them do by default).
I did, yes.
Also as a lot of you use F5 servers here is information about DNS flag day
fixes.
https://support.f5.com/csp/article/K07808381?sf206085287=1
And if you don’t want to go to the web site you can still see the content here
https://github.com/dns-violations/dnsflagday
And if you don’t want to go to the web site you can still see the content here
https://github.com/dns-violations/dnsflagday
I think part of my snark was lost as snark here…
So, we’re asking ‘everyone’ to do ‘something’ on behalf of their domains, their users and the rest of the internet… we can’t seem to do that in a fashion that’s traceable, clearly has ownership and doesn’t look like every halfbaked spam campaign in the world.
Yes I could go digging for the right starting point at ISC or github or … what??
Why wasn’t this pretty clearly owned by ‘ICANN’ or some organization like that?
It’s lovely that github, fastly, gandi and ISC want to help, but… somewhere here some legitimacy could have been injected into the process, right?
“HI, we’re ICANN we do dns thingies, and we’d like to help make you make things better. Please use the website (provided by our partner(s) X, Y, Z to do the following A, B, C things, and get guidance on repair for problems at site FOO, BAR or BAZ. If there are questions please see our FAQ (https://www.icann.org/dnsfixin/faq) or email <support@icann.org>. Thanks for taking the time to make the world better?”
it’s not super hard to do this, it’s also apparently super easy to look like a spam/malware campaign.
And if you don’t want to go to the web site you can still see the content here
https://github.com/dns-violations/dnsflagday
I think part of my snark was lost as snark here...
So, we're asking 'everyone' to do 'something' on behalf of their domains, their users and the rest of the internet... we can't seem to do that in a fashion that's traceable, clearly has ownership and doesn't look like every halfbaked spam campaign in the world.
Yes I could go digging for the right starting point at ISC or github or .. what??
Why wasn't this pretty clearly owned by 'ICANN' or some organization like that?
Well the IETF doesn’t want to be “Protocol Police”. ICANN has enforced this
on gTLD operators as they are contractually obligated to run protocol compliant
servers. Almost all of the ccTLD servers are fixed as well.
https://ednscomp.isc.org/compliance/ts/tld-graphs.html
https://ednscomp.isc.org/compliance/tld-report.html
I’ve argued for years that TLD operators should be doing tests like this on
all delegated domains and delisting them until they have fixed the server after
a initial grace period with multiple warnings. They are in a position to send
warning to operators and owners of delegated zones. They just say “this is not
our job” despite RFC 1033 actually listing removal of delegation as something
that should be done by the parent zone (TLD) if other methods of fixing servers
that don’t follow the specification fail.
No one wanted own this. This is Open Source DNS vendors saying "Enough is Enough”.
We are tired of having to write workarounds for all the broken servers out there
especially as those workarounds impacts on sites that have protocol compliant servers.
None of use could move alone as we would get “But it works with …”. This needed to
be a collective move. The public DNS resolver operators are also on board.
No system works if there are not checks and balances in place. The DNS still doesn’t
have checks and balances in place.
Mark
On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews <marka@isc.org> may have
written:
If you run a firewall in front of your DNS server you may be broken.
If you run a firewall in front of your DNS server and the firewall breaks
EDNS, then your firewall is broken. And has been a long, long time. I put a
firewall in place back in 2004, and EDNS compliance was one of the tests
back then.
* morrowc.lists@gmail.com (Christopher Morrow) [Thu 24 Jan 2019, 06:46 CET]:
So, we're asking 'everyone' to do 'something' on behalf of their domains, their users and the rest of the internet... we can't seem to do that in a fashion that's traceable, clearly has ownership and doesn't look like every halfbaked spam campaign in the world.
Do those link to presentations given at major industry conferences like RIPE and DNS-OARC, with well known industry people getting on stage to talk about it?
What more do you need? More recent additions, mayhaps?
UKNOF? https://www.youtube.com/watch?v=e4KdsexpB7Q
LACNIC? https://www.youtube.com/watch?v=_hCGucH0kRU
SDNOG? https://www.youtube.com/watch?v=UksQZkxOC-Q
Oh wait, you had to scroll down on the main dnsflagday.net page to see those links, which in this day of only the first page of Google results mattering, isn't going to happen, apparently.
-- Niels.
On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews <marka@isc.org> may have
written:
If you run a firewall in front of your DNS server you may be broken.
If you run a firewall in front of your DNS server and the firewall breaks
EDNS, then your firewall is broken. And has been a long, long time. I put a
firewall in place back in 2004, and EDNS compliance was one of the tests
back then.
EDNS usage has changed since them. Back in 2004 there was zero use of EDNS
options in queries. That is no longer true. NSID (RFC 5001) the first option
to make it into main stream code was allocated in 2007 and that saw occasional
use. DNS COOKIE has been in every query named has emitted since BIND 9.11.0 and
in late BIND 9.10 versions. Lots of firewalls still reject it.
We see Juniper firewalls blocking EDNS(1) and NSID by default.
We see Checkpoint firewalls blocking EDNS(1) and EDNS flags by default.
There is a another vendor that blocks EDNS(1).
Juniper and Checkpoint have newer code that doesn’t do this. The old
firewalls are still out there however. You can see them easily when
you are doing bulk testing and mark timeouts in a different colour.
Please go look at the reports on https://ednscomp.isc.org to see how
obvious they are. There were times in the last 4 years where over
50% of the tested servers were dropping EDNS(1) queries. With drop
rates like that you limited the ability of the IETF to use EDNS(1) to
fix issues with EDNS correctly. The RFC 6891 would have included a
version bump except for these stupid firewalls. The clarification of
unknown EDNS option behaviour warranted a version bump.
Blocking any of the extension mechanisms (version, flag or option) isn’t
doing anyone any benefit. If you have a firewall that does it please
FIX IT.
Mark Andrews <marka@isc.org> writes:
I’ve been complaining for YEARS about lack of EDNS compliance.
Didn't help.
bjorn@miraculix:~$ dig +edns=42 +noednsnegotiation @1.1
; <<>> DiG 9.11.5-P1-1-Debian <<>> +edns=42 +noednsnegotiation @1.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40525
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 9060 IN NS d.root-servers.net.
. 9060 IN NS e.root-servers.net.
. 9060 IN NS f.root-servers.net.
. 9060 IN NS g.root-servers.net.
. 9060 IN NS h.root-servers.net.
. 9060 IN NS i.root-servers.net.
. 9060 IN NS j.root-servers.net.
. 9060 IN NS k.root-servers.net.
. 9060 IN NS l.root-servers.net.
. 9060 IN NS m.root-servers.net.
. 9060 IN NS a.root-servers.net.
. 9060 IN NS b.root-servers.net.
. 9060 IN NS c.root-servers.net.
;; Query time: 3 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Jan 24 14:40:00 CET 2019
;; MSG SIZE rcvd: 431
Bjørn
My edge routers block *all* inbound DNS requests -- I was being hit by a
ton of them at one point. Cavaet: I don't run a DNS server that is a
domain zone master -- I use a DNS service for that. I do have a DNS
server inside, but only to handle recursive requests from inside my network.
Outbound DNS requests? Lets them through, and responses too.
you are seriously cracking me up… but.
Mark Andrews <marka@isc.org> writes:
I’ve been complaining for YEARS about lack of EDNS compliance.
Didn't help.
Perfect vs incremental improvement. Please go look at the graphs
on ednscomp.isc.org. You will see the fixes being applied. You
can see firewalls being removed. You can seen IPv6 being deployed
on DNS server farms with broken DNS servers. You can see when name
servers are fixed to remove implementation flaws.
Well does your DNS service properly manage the firewall in front of their
servers? Does the anti DoS scrubbing service they are using also pass the
well formed packets to the DNS server they are advertising?
This was about testing the servers YOU directly or indirectly advertise to
the world. It also applies to any recursive servers. They too need properly
handle EDNS queries in all their forms. The test tool has a recursive mode
for testing them (genreport -R).
Mark
I have domains on several DNS services. Most of the services work
properly according to the ISC tests. Two of the services show failures.
So I called support on the pair. One service says they are deploying
updates before the 1 Feb 19 deadline to all their DNS servers. The
other one (starts with an "A") doesn't know when they will be fully
compliant "but your customers should have no difficulty with getting DNS
answers on your domains."
I had downloaded the tool, so I tested my inside DNS servers just for
grins. Passed with flying colors -- I had used Centos 7 in those
servers, updated on a regularly scheduled basis, so of course it flew
with flying colors. (Or do you prefer colours?)