business in Australia. Remember you are choosing to do business
with Australia when you send the email.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
In message <1496816542.3628250.1001312328.70df4...@webmail.messagingengine.com>
, Scott Christopher writes:
> Mark Andrews wrote:
>
> > but we do have the tech to do this.
>
> I wholeheartedly agree.
>
> > All it takes is a couple of transit providers to
In message
<cal9jlaznrde0gl4nvn93vhv1bobtx0ekgjet8pvxa3mve1g...@mail.gmail.com>,
Christopher Morrow writes:
>
> On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews <ma...@isc.org> wrote:
>
> > Now we could continue discussing how easy it is to hijack addresses
> > of w
In message <2541cadf-4a76-b172-b395-0822f1889...@bryanfields.net>, Bryan Fields
writes:
> On 6/6/17 9:13 PM, Mark Andrews wrote:
> > Getting to that stage requires several companies to simultaneously
> > say "we will no longer accept as valid mechanisms to verify
>
w easy it is to hijack addresses
of we could spend the time addressing the problem. All it takes is
a couple of transit providers to no longer accept word-of-mouth and
the world will transition overnight.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
pedia.org/wiki/CAN-SPAM_Act_of_2003
While this is not US law, the act of harvesting addresses is illegal
under the Australian anti-spam act
https://www.legislation.gov.au/Details/C2016C00614
Mark
> -mel via cell
>
> > On Jun 13, 2017, at 6:58 PM, Mark Andrews <ma...@isc.o
t; We definitely can't sue them as you advise. In fact, individual CANT use
> under CAN-SPAM. Only we network operators can.
>
> Thanks for nothing, Congress.
As someone with stonger local anti-spam legislation that has to put
up with the spam from US sources I have to agree.
Mark
> -mel via
ns to
> >hurt you, and they take no action except to keep hurting you,
> >then one of the ways you can describe the situation is "it isn't
> >scaling well".
> >--- Paul Vixie, on NANOG
> >
> > ---rsk
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
ver for that matter).
> Brocade supports this, but I am not finding this as part of any of the
> RFC's. This is to deliver home ISP service, so it is very important or
> return packets won't go to the client unless the route is manually added as
> a routing protocol is not an option.
initial fragment of
the UDP packet. Only the initial fragment that contains the UDP
header has the ports reported.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
-17
> 18:04:32.391420 IP 115.75.50.106 > umbrellix.net: ip-proto-17
> 18:04:32.391426 IP 115.75.50.106 > umbrellix.net: ip-proto-17
>
> Some stupidity has me wondering... protocol 17? Huh?
>
>
> Is this some attempt to exploit me while at the same time flooding me at
> over 800Mbit/s?
>
>
> Needless to say, I've shut my computer down to avoid going over my data
> allowance.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 24 10:45:56 AEST 2017
;; MSG SIZE rcvd: 150
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
In message
0 1209600 86400
;; Query time: 1142 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 09 12:07:56 AEDT 2017
;; MSG SIZE rcvd: 175
%
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Companies like COMCAST did. They manage the modems over IPv6.
They also supported DS-Lite’s development as a transition mechanism so they
wouldn’t have to run IPv4 to their customers. They wanted to be able to go
IPv6 only. That meant having IPv4 as a service available.
--
Mark Andrews
devices with a 15 year life cycle should be IPv6 capable today. Microsoft
shipped IPv6 capable versions of Windows in 2001. If they could see the
writing on the wall back then *every* other device manufacture should have also
been able to see this.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley,
enterprises using non RFC1918
>> IP space that other entities are assigned by ARIN for internal routing?
>>
>> Just curious as to how wide spread this might be. I just heard of this
>> happening with a large ISP and never really thought about it until now.
>>
>> Robert
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
whois is actually very useful for determining
> the rightful owner and abuse contacts for IP address space... Since RIRs
> are designated by region and, afaik, only RIPE NCC data would be impacted
> by GDPR... well, I'm surprised this isn't being talked about more than the
> domain
am, Ca By wrote:
>
>
>
> On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews wrote:
> If a ASN is announcing 2002::/16 then they are are happy to get the traffic.
> It
> they don’t want it all they have to do is withdraw the prefix. It is not up
> to
> the rest of us
this message or if this
> message has been addressed to you in error, please immediately alert the
> sender by reply e-mail and then delete this message and any attachments. If
> you are not the intended recipient, you are notified that any use,
> dissemination, distribution, copying,
overall laws as well.
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> On 20 Jun 2018, at 4:16 am, Wes George wrote:
>
> On 6/18/18 7:34 PM, Mark Andrews wrote:
>
>> If a ASN is announcing 2002::/16 then they are are happy to get the traffic.
>> It
>> they don’t want it all they have to do is withdraw the prefix. It is n
m both."
>
> That's not diversity. That's just a matter of time before the same backhoe
> catches them both. :)
It depends on how the lines "cross" each other. Two tunnels and you
have physical seperation. Crossing at the same level then you don't.
Mark
--
Mark Andrews, ISC
1 Sey
and 1400 byte packets with DF bit seem to make it just fine.
>
> - Jared
>
> --
> Jared Mauch | pgp key available via finger from ja...@puck.nether.net
> clue++; | http://puck.nether.net/~jared/ My statements are only mine.
--
Mark Andrews, ISC
f I increase to 1478 it may or may not work.
>>>> PMTUD has a lot of trouble working reliability when the destination of
>>>> the PTB is a stateless load-balancer.
>>>
>>> More explanations are available here:
>>> https://blog.cloudflare.com/path-mtu-discovery-in-practice/
>>> --
>>> Don't comment bad code - rewrite it.
>>>- The Elements of Programming Style (Kernighan & Plauger)
>>>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
just so many technical manuals and other advices,
>>>> you are told to "just use a /64' for your point to points.
>>>
>>> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the
>>> exception would be if a router does not support it.
&g
ISP that wants a structured address plan, e.g. to encode
> prefecture, city and part of city in the address, will quickly use up
> bits in the customer id part of the address.
>
>
> /Bellman
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
happen in 5, 10, 100 years? The later is a safer bet.
> (not that I'll be around to collect) But just like IPv4, some decades down
> the road, people will see how stupid our allocation scheme really is, and
> begin a new "classless" era for IPv6. The short of it is, we got here first,
> so we don't have to give a shit about being efficient or frugal.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
ets means that even if other stuff
> shows up and starts asking for a PD, there will be plenty left for them to
> use.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> On 29 Dec 2017, at 4:21 pm, valdis.kletni...@vt.edu wrote:
>
> On Fri, 29 Dec 2017 15:36:51 +1100, Mark Andrews said:
>> PD is designed so that a device (router) can request multiple PD requests
>> upstream. The interior router just needs to make a upstr
what's being announced vs. what's
> actually being used, there's a fantastic amount of waste. But nobody cares
> because there's plenty of space, and "we'll never use it all." (history says
> otherwise.)
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Talk to your lawyers. They should be able to advise you if there is legal
remedy or not and if so what the chances of success are and some estimate of
the costs of pursuing action.
Mark
--
Mark Andrews
> On 27 Dec 2017, at 06:41, Michael Crapse <mich...@wi-fiber.io> wrote:
>
ASSIGNED PA
mnt-by: LOGICWEB-MNT
source: AFRINIC # Filtered
parent: 196.52.0.0 - 196.55.255.255
person: Chad Abizeid
address:LogicWeb Inc.
address:4509 Steeplechase Dr.
address:Easton, PA 18040
address:USA
phone: +1 866 611
ecords to your
recursive servers.
The following provides the 464XLAT translation with the well known NAT64 prefix.
ipv4only.arpa. SOA . . 0 0 0 0 0
ipv4only.arpa. NS .
ipv4only.arpa. 64:ff9b::192.0.0.170
ipv4only.arpa. 64:ff9b::192.0.0.171
ipv4only.arpa. A 192.0.0.170
ipv4only.arpa. A 192
der of
> magnitude. From sparsely allocated ISP blocks for another order of
> magnitude. It slips away faster than you might think.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin her...@dirtside.com b...@herrin.us
> Dirtside Systems ...
DNS64 was only ever a stop gap mechanism with lots of know side
effects.
Mark
> On 21 Dec 2017, at 10:01 am, Ca By <cb.li...@gmail.com> wrote:
>
>
> On Wed, Dec 20, 2017 at 5:54 PM Mark Andrews <ma...@isc.org> wrote:
> As someone who has written a DNS64 implementation - DO
---
> | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
> | http://blog.quux.de | jabber: jensl...@quux.de| --- |
> --------
--
Mark Andrews, ISC
IPv4 assignments into IPv4 pools. This is no
different. You carve up a IPv6 assignments into similar sized pools of /48’s
then set the 6rd DHCPv4 Option to the appropriate values for that IPv4 to IPv6
pool mapping. Add the mapping to the BRs and you are done.
Mark
--
Mark Andrews, ISC
1 Seym
contiguous
addresses.
Automatic assignment in homenet does dense assignment.
> On 21 Dec 2017, at 12:27 pm, William Herrin <b...@herrin.us> wrote:
>
> On Wed, Dec 20, 2017 at 4:57 PM, Mark Andrews <ma...@isc.org> wrote:
> Handing out /48’s to homes was never ever goin
New Year all!
>
>
> James W. Breeden
>
> Managing Partner
>
>
>
> [logo_transparent_background]
>
> Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media
>
> PO Box 1063 | Smithville, TX 78957
>
> Email: ja...@arenalgroup.co<mai
d. We have had some customers power cycle everything in their home
> (CPE, router, xbox) and still no go.
>
> Anyone else running into this? Does Microsoft have a higher level support for
> talking with ISPs at all?
>
>
> Justin Wilson
> j...@mtin.net
>
> www.mtin.
the interfaces just to be safe.
>
>
> Justin Wilson
> j...@mtin.net
>
> www.mtin.net
> www.midwest-ix.com
>
>> On Jan 2, 2018, at 6:06 PM, Chris Adams <c...@cmadams.net> wrote:
>>
>> Once upon a time, Mark Andrews <ma...@isc.org> said:
>>> G
UTC 2018
;; MSG SIZE rcvd: 145
% grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok |
awk '{print $3}' | sort -u
(sauthns1.qwest.net.):
(sauthns2.qwest.net.):
% grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z | grep
edns=ok | awk '{print $3}' | sort -u
(
edns=ok
edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion
do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Which doesn’t work with IPv6 as UDP doesn’t have the field to clamp.
--
Mark Andrews
> On 20 Jan 2018, at 03:35, Radu-Adrian Feurdean
> <na...@radu-adrian.feurdean.net> wrote:
>
>> On Fri, Jan 19, 2018, at 01:14, Jared Mauch wrote:
>> If you’re then doing DSL
, mostly google / youtube / fb /
>> netflix / apple / amazon — but your mix may vary.
>>
>>
>>
>>>
>>>
>>> On 19 January 2018 at 18:38, Andrew Kirch <trel...@trelane.net> wrote:
>>>
>>>> On Fri, Jan 19, 2018 at 4:59
gt;
> From: Michael Crapse <mich...@wi-fiber.io>
> Date: Monday, January 22, 2018 at 5:27 PM
> To: Mark Andrews <ma...@isc.org>
> Cc: Lee Howard <l...@asgard.org>, NANOG list <nanog@nanog.org>
> Subject: Re: Leasing /22
>
> > Customers on ps
t can't be
> registered to any end-user.
>
> Aled
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Whois contact details need to work so you can contact the zone owner when the
DNS is broken for the zone.
Publishing Whois data in the zone does not work for this purpose.
This is not to discount other reasons for having a independent communications
channel.
--
Mark Andrews
> On 21
You have a logic fail. This fails because it STILL depends on the DNS for the
zone working.
--
Mark Andrews
> On 22 Apr 2018, at 07:27, Lyndon Nerenberg <lyn...@orthanc.ca> wrote:
>
>
>> On Apr 21, 2018, at 1:58 PM, b...@theworld.com wrote:
>>
>> T
Parts to 1/8 have be allocated to people for
years now.
1.0.0/24 and 1.2.3/24 have been used for various experiments but the rest
of 1/8 is being allocated for normal use (there may be a couple of more
exceptions).
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
setup
to supply prefixes like that to 10 billion of us.
They are also in a specific range which makes setting filtering
rules easier for everyone else.
Now I would love it if we could support 100 billion routes in the
DFZ but we aren’t anywhere near being able to do that which would
be a requi
, slow
> enough that there will be no issues keeping up, even assuming a "slow"
> hardware refresh cycle.
>
> -M
>
> On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews <ma...@isc.org> wrote:
>>
>>> On 2 Mar 2018, at 9:28 am, Owen DeLong <o...@delong.com&g
are.
--
Mark Andrews
> On 2 Mar 2018, at 22:49, Bjørn Mork <bj...@mork.no> wrote:
>
> Owen DeLong <o...@delong.com> writes:
>
>> I don’t agree that making RFC-1918 limitations a default in any daemon makes
>> any
>> sense whatsoever.
>
> +1
&g
;>> I’m on native IPv6 via Spectrum and have no problems with Windows Updates.
>>> Could this be a tunneling issue?
>>
>> I do run 6-in-4 from my backbone to my house as my FTTH provider does not do
>> IPv6.
>>
>> I can't imagine this to specifically be the is
ly to
work around the lack of passing fragments. This is IP and fragments are part
and parcel of IP whether it is IPv4 or IPv6.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> On 5 Oct 2018, at 4:22 pm, Brandon Martin wrote:
>
> On 10/5/18 1:53 AM, Mark Andrews wrote:
>> If you don’t want fragmented IPv6 UDP responses use
>> server ::/0 { edns-udp-size 1232; };
>> That’s 1280 - IPv6 header - UDP header. Anything bigger than
it was not the first
major OS to have it) just turn on IPv6.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
. DNS
is time critical enough without introducing unnecessary delays.
If you have signed zones then TCP requests are almost certainly being
made to your servers.
EVERYONE TEST YOUR SERVERS FROM OUTSIDE YOUR NETWORK AND FIX THE BROKEN
FIREWALLS THAT ARE FOUND.
--
Mark Andrews, ISC
1 Seymour St
> On 28 Dec 2018, at 2:49 pm, valdis.kletni...@vt.edu wrote:
>
> On Fri, 28 Dec 2018 13:35:04 +1100, Mark Andrews said:
>> There are major operators that still have STUPID firewall settings
>> in front of DNS servers that drop SYN packets with ECE and CWR set
LW6p uZ0=
_25._tcp.mx.pao1.isc.org. 3543 IN TLSA3 0 1
71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0
_25._tcp.mx.ams1.isc.org. 3545 IN TLSA3 0 1
5EF9B10DA21B2711522982EAD699FBABE77FD07FF07AC810608A85DA 66AFE916
;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jan 12 07:09:
86400 IN NS sauthns2.qwest.net.
>>
>> ;; Query time: 66 msec
>> ;; SERVER: 208.44.130.121#53(208.44.130.121)
>> ;; WHEN: Tue Sep 11 06:19:33 UTC 2018
>> ;; MSG SIZE rcvd: 145
>>
>> % grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep e
> 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 f
> 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 hi
Sounds like something that should be reported to the FDA.
--
Mark Andrews
> On 6 Apr 2019, at 10:47, Eric Parsonage wrote:
>
>
> I personally fell foul of this last night. My CPAP machine switched itself
> off. It has an internal cellular modem which it uses to exch
>
> --
> Måns Nilsson primary/secondary/besserwisser/machina
> MN-1334-RIPE SA0XLR+46 705 989668
> Don't worry, nobody really LISTENS to lectures in MOSCOW, either! ...
> FRENCH, HISTORY, ADVANCED CALCULUS, COMPUTER PROGRAMMING, BLACK
> STUDIES, SOCIOBI
> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote:
>
>
>
> On 5/Mar/19 00:25, Mark Andrews wrote:
>
>>
>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if
>> they have installed broken ECMP devices. The simplest way to do that
>> i
> On 6 Mar 2019, at 3:37 pm, Fernando Gont wrote:
>
> On 6/3/19 01:09, Mark Andrews wrote:
>>
>>
>>> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote:
>>>
>>> On 3/3/19 18:04, Mark Andrews wrote:
>>>> There are lots of IDIOTS o
only difference being this
> >was a whole whack of script kiddies acting in concert directed by a
> >not-quite-so-stupid script kiddie, with some "modernz" thrown in for
> >good measure. (Sounds like an NSA operation to me -- and the targets
> >perfectly match those that the NSA would choose -- plus some good old
> >misdirection just for the jollies of it)
> >
> >The second takeaway being that DNSSEC is useless in preventing
> >such an occurrence because the script kiddies can merely turn it off
> >at the same time as they redirect DNS. However, having DNSSEC can
> >protect you from incompetent script-kiddies. It can also give you a
> >false sense of security.
> >
> >Did I miss anything?
> >
> >---
> >The fact that there's a Highway to Hell but only a Stairway to
> >Heaven says a lot about anticipated traffic volume.
> >
> >
>
>
>
>
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
a registry. At this stage
is would be a minor code change to add such policy knobs. DLV is a just a
in-band way of distributing trust anchors.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
s. Why should
the rest of the world have to put up with their inability to purchase
devices that work with RFC compliant data streams.
Mark
> --
> ++ytti
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote:
>
> On 3/3/19 18:04, Mark Andrews wrote:
>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
>> getting
>> back to the TCP servers. There are also IDIOTS that deploy load balancers
>>
> On 6 Mar 2019, at 1:36 pm, Fernando Gont wrote:
>
> On 5/3/19 03:26, Mark Andrews wrote:
>>
>>
>>> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote:
>>>
>>>
>>>
>>> On 5/Mar/19 00:25, Mark Andrews wrote:
>>>
ough, even though the predecessor QUIC does not care
>> about MTU at all... good that it is all in the hands of a company that can
>> fix it themselves ;)
>
> Is it an ideal situation? About as ideal as flying in the cargo bay. But
> my reality is that until my FTTH pro
> On 4 Mar 2019, at 9:33 am, Stephen Satchell wrote:
>
> On 3/3/19 1:04 PM, Mark Andrews wrote:
>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB
>> getting
>> back to the TCP servers.
>
> For those of us who are in the dark, "
> On 28 Feb 2019, at 9:03 am, John R. Levine wrote:
>
> On Thu, 28 Feb 2019, Mark Andrews wrote:
>> Agreed. Additionally it suddenly went from something being done along
>> with a experiment to being “a experiment on can you transition to a new
>> type”. The tr
tunately I can’t prove that this would have been the course of
events because it got aborted.
> R's,
> John
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
select how to redirect the update. This also works with
existing DNS servers
when EPP is not thrown into the mix. It also doesn’t require DNSSEC to be
deployed.
Tools to do this have been shipped with nameservers since UPDATE, TSIG and
SIG(0) were invented.
Mark
--
Mark Andrews, ISC
1 Seymour S
added, or have
> comments on the answers, please do let me know -- the document can
> eventually be revised.
>
> Thanks!
>
> Cheers,
> --
> --
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 74
> On 8 Mar 2019, at 6:30 pm, Fernando Gont wrote:
>
> Hello, Mark,
>
> Thanks for your feedback! Please see in-line
>
> On 8/3/19 04:10, Mark Andrews wrote:
>> "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been
>> deprec
ling like I should go put any data at
> all into the site.
>
> -chris
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
think it needs to be
> mentioned here if it hasn't already been.
> - Brian
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
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:
> Wel
> 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
>
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://
mechanisms (version, flag or option) isn’t
doing anyone any benefit. If you have a firewall that does it please
FIX IT.
> On 24 Jan 2019, at 10:13 pm, Mark Andrews wrote:
>
>
>
>> On 24 Jan 2019, at 9:02 pm, Mike Meredith wrote:
>>
>> On Thu, 24 Jan 2019 11:22:44
> 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
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 hel
> 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.
147.234 ms 151.094 ms 152.088 ms
9 108.170.247.129 (108.170.247.129) 152.073 ms 149.194 ms 149.055 ms
10 108.170.230.137 (108.170.230.137) 149.697 ms 150.042 ms
74.125.252.75 (74.125.252.75) 149.363 ms
11 lax31s01-in-f4.1e100.net (172.217.14.100) 158.438 ms 147.982 ms 149.593
ms
ris
>
> On Thu, Jan 31, 2019 at 2:30 PM Mark Andrews wrote:
> [beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi
> looking up www.google.com
> connecting to www.google.com:443
> SSL connection established using ECDHE-RSA-AES128-GCM-SHA256
> Certificate subject: /
It was 9:29 AM Feb 1 AEST when I reported this so yes it was FRIDAY.
> On 1 Feb 2019, at 3:15 pm, Christopher Morrow wrote:
>
>
>
> On Thu, Jan 31, 2019 at 4:34 PM Mark Andrews wrote:
> George Michaelson forwarded me Google’s notice which said there would be a
> t
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
> 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
--
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
unreasonable to require. The fixed code is out there for both name
servers and firewalls.
Mark
> On 31 Jan 2019, at 2:49 pm, Christopher Morrow
> wrote:
>
>
>
> 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 da
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 o
they are really doing nothing
useful.
Most of the other errors reported are benign as far as DNS flag day is
concerned.
Also apart from the public DNS resolvers people need to install updated
software that has the work arounds removed.
Mark
--
Mark Andrews
> On 31 Jan 2019, at 12:22, Matthew Pet
the development version 9.13 which has had the code for a while
now.
Individual operators of resolvers will make their own decisions about when to
deploy.
--
Mark Andrews
> On 31 Jan 2019, at 12:55, Christopher Morrow wrote:
>
>
>
>> On Wed, Jan 30, 2019 at 5:41 PM Jim P
uch cleaner now and we
the data to show it.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
901 - 1000 of 1128 matches
Mail list logo
