> On 3 Feb 2019, at 2:01 am, Stephen Satchell wrote:
>
> On 2/1/19 1:23 PM, Mark Andrews wrote:
>> Google has started their rollout.
>
> So has Red Hat (RHEL and Centos). I woke up to a rather large update
> this morning.
RedHat or third party RPM’s you have chosen to run on RedHat? RedHat
On 2/1/19 1:23 PM, Mark Andrews wrote:
> Google has started their rollout.
So has Red Hat (RHEL and Centos). I woke up to a rather large update
this morning.
Google has started their rollout.
https://groups.google.com/forum/#!msg/public-dns-announce/-qaRKDV9InA/tExCFrppAgAJ
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
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 repor
> On 1 Feb 2019, at 3:32 am, James Stahr 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
On 2019-01-31 08: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 *serve
On Thu, Jan 31, 2019 at 10:33 AM James Stahr wrote:
[snip]
> 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
[snip]
Their test too
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
> On Jan 30, 2019, at 17:40 , Jim Popovitch via NANOG wrote:
>
> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote:
>> Any chance this could wait until say the Tuesday
>> *after* the Superbowl, when we aren't cutting an
>> entire religion's worth of potential workers out of
>> the wor
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 t
> On 1 Feb 2019, at 1:21 am, Stephen Satchell wrote:
>
> After reading through the thread, this reminds me of the Y2K flap, that
> turned into a non-event. My checks of authoritative DNS servers for my
> domains show no issues now.
As did I, but if we didn’t try and give lots of notice peopl
> On 31 Jan 2019, at 10:59 pm, Matthew Petach wrote:
>
>
>
> On Thu, Jan 31, 2019, 01:27 Radu-Adrian Feurdean
>
>
> On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote:
> > You do realise that when the day was chosen it was just the date after
> > which new versions of name servers by th
After reading through the thread, this reminds me of the Y2K flap, that
turned into a non-event. My checks of authoritative DNS servers for my
domains show no issues now.
On Thu, Jan 31, 2019 at 6:01 AM Matthew Petach wrote:
> Google, Cloudflare, Quad9 all changing their codebase/response behaviour on a
> Friday before a major sporting and advertising event?
> Not sounding like a really great idea from this side of the table.
If your DNS zone is hosted on Google
On Thu, Jan 31, 2019, 01:27 Radu-Adrian Feurdean <
na...@radu-adrian.feurdean.net wrote:
>
>
> On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote:
> > You do realise that when the day was chosen it was just the date after
> > which new versions of name servers by the original group of Open Source
--
Mark Andrews
> On 31 Jan 2019, at 20:25, Radu-Adrian Feurdean
> wrote:
>
>
>
>> On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote:
>> You do realise that when the day was chosen it was just the date after
>> which new versions of name servers by the original group of Open Source
>>
On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote:
> You do realise that when the day was chosen it was just the date after
> which new versions of name servers by the original group of Open Source
> DNS developers would not have the work arounds incorporated?
I think it's pretty safe to say
Don’t forget the reverse tree as well.
> On 31 Jan 2019, at 5:40 pm, Hank Nussbacher wrote:
>
> On 31/01/2019 07:18, Mark Andrews wrote:
>
> There is some secret, silent block on my postings to NANOG that the admins
> have not yet discovered. In the interim can one of you please proxy to the
The only ones that could potentially make a “breaking change” on the Feb 1 are
Google, Cloudflare and Quad9. They are the public DNS recursive server
operators that have committed to removing work arounds. Google has already
stated publicly that it will be introducing changes gradually and I e
On Wed, Jan 30, 2019 at 9:51 PM Christopher Morrow
wrote:
> you do realize you are proposing to make a breaking change (breaking change to
> a global system) on a friday. delaying until the following monday would not
> have
There are reasons to prefer a Friday over other days as well, but the
i
On Wed, Jan 30, 2019 at 8:10 PM Keith Medcalf wrote:
>
> The best time is usually a Wednesday at Noon or 11:00 in the impacted
> timezone. Of course, if the impact is worldwide then that would probably
> be UT1 :)
that still sounds like: "not friday" right?
>
Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher
>Morrow
>Sent: Wednesday, 30 January, 2019 18:55
>To: Jim Popovitch
>Cc: nanog
>Subject: Re: DNS Flag Day, Friday, Feb 1st, 2019
>
>
>
>On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch
On Wed, Jan 30, 2019 at 6:23 PM Mark Andrews wrote:
> You do realise that when the day was chosen it was just the date after
> which new versions of name servers by the original group of Open Source DNS
>
you do realize you are proposing to make a breaking change (breaking change
to a global sys
You do realise that when the day was chosen it was just the date after which
new versions of name servers by the original group of Open Source DNS
developers would not have the work arounds incorporated?
For ISC that will be BIND 9.14.0 and no that will not be available Feb 1 but
you can use th
On January 31, 2019 1:55:26 AM UTC, Christopher Morrow
wrote:
>On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG
>
>wrote:
>
>> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote:
>> > Any chance this could wait until say the Tuesday
>> > *after* the Superbowl, when we aren't cutting a
This basically affects sites using really old Windows DNS servers (Microsoft
decided to make them only respond once with FORMERR so if that message is lost
they appear to be dead until the timer clears) and those using firewalls that
block EDNS queries. If you use such firewalls they are really
On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG
wrote:
> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote:
> > Any chance this could wait until say the Tuesday
> > *after* the Superbowl, when we aren't cutting an
> > entire religion's worth of potential workers out of
> > the workf
On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote:
> Any chance this could wait until say the Tuesday
> *after* the Superbowl, when we aren't cutting an
> entire religion's worth of potential workers out of
> the workforce available to fix issues in case it
> turns out to be a bigger prob
On Wed, Jan 23, 2019 at 4:12 PM Brian Kantor wrote:
> Quoting from the web site at https://dnsflagday.net/
>
[...]
> 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 pro
On 1/24/19 11:46 AM, Mark Andrews wrote:
>On 25 Jan 2019, at 2:14 am, Stephen Satchell wrote:
>> 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.
> On 25 Jan 2019, at 2:14 am, Stephen Satchell wrote:
>
> On 1/23/19 8:44 PM, Mark Andrews wrote:
>> and they your firewalls don’t block well formed DNS queries (lots of
>> them do by default).
>
> My edge routers block *all* inbound DNS requests -- I was being hit by a
> ton of them at one p
> On 25 Jan 2019, at 12:50 am, Bjørn Mork wrote:
>
> Mark Andrews 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
you are seriously cracking me up... but.
On Thu, Jan 24, 2019 at 6:05 AM Niels Bakker wrote:
> * morrowc.li...@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..
On 1/23/19 8:44 PM, Mark Andrews wrote:
> and they your firewalls don’t block well formed DNS queries (lots of
> them do by default).
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 --
On Wed, Jan 23, 2019 at 5:27 PM Mark Andrews wrote:
> 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
Mark Andrews 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:
;; ->>HEADE
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 ca
> On 24 Jan 2019, at 9:02 pm, Mike Meredith wrote:
>
> On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews 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
* morrowc.li...@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
On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews 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
> On 24 Jan 2019, at 4:45 pm, Christopher Morrow
> wrote:
>
>
>
> On Thu, Jan 24, 2019 at 12:35 AM Mark Andrews wrote:
> 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 los
On Thu, Jan 24, 2019 at 12:35 AM Mark Andrews wrote:
> 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 o
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
> On 24 Jan 2019, at 4:32 pm, Mark Andrews wrote:
>
> Also as a lot of you use F5 servers here is information about DNS flag day
> fixes.
>
> https://support.f5.com/csp/a
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
> On 24 Jan 2019, at 3:51 pm, Christopher Morrow
> wrote:
>
>
>
> On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote:
> Well you can go to https://ed
On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote:
> 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
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
On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote:
> Quoting from the web site at https://dnsflagday.net/
>
>
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 th
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
> On 24 Jan 2019, at 11:10 am, Brian Kantor wrote:
>
> Quoting f
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 worka
49 matches
Mail list logo
