TIMEOUT is TIMEOUT. The whole point of flag day is that you can’t tell whether TIMEOUT is broken routing, packet loss or badly configured firewall. The DNS flag day site assumes the latter as does the old resolver code. We are moving to a state where resolvers assume the former. You get a report with Red or Orange. Red reports have things which need to be fixed NOW be it a routing issue or packet loss or a badly configured firewall. Mark
On 1 Feb 2019, at 4:04 am, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 31/Jan/19 18:32, James Stahr wrote:
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...
On a similar note, we tested for all our self-hosted zones OK 2 weeks ago. However, in previous days, the summary result said "NO GOOD, THINGS WILL BE SLOW COME FLAG DAY". The detailed test showed IPv4 tested perfect, but IPv6 probes timed out.
The issue turned out to be an internal IPv6 routing/forwarding issue for our service within Century Link's (Level(3)'s) network. CL finally fixed that issue today and the flag day test tool is happy again.
Some of our partners/customers were concerned our name servers were not ready, based purely on the summary result of the test tool. Perhaps adding some intelligence about whether the issue is the name server or the transport may be helpful.
Mark.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org