DNS Flag Day, Friday, Feb 1st, 2019

Thu Jan 31 21:19:12 UTC 2019

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 at 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 at isc.org