Re: Is Verizon core network broken? Can someone reach out to Verizon core network team so that they can look into why so many networks are missing?

2021-07-21 Thread Stephane Bortzmeyer
On Wed, Jul 21, 2021 at 11:35:35AM -0400,
 S Umple  wrote 
 a message of 61 lines which said:

> #
>   81.0.0.0/8 is variably subnetted, 2835 subnets, 14 masks
>   121.51.0.0/16 
>   182.254.0.0/16 is variably subnetted, 3 subnets, 2 masks
> 
> 
> route-views.routeviews.org>
>   81.0.0.0/8 is variably subnetted, 3247 subnets, 19 masks
>   121.0.0.0/8 is variably subnetted, 2571 subnets, 18 masks
>   182.254.0.0/16 is variably subnetted, 113 subnets, 5 masks
> 
> Anyone able to validate my findings, and/or take this issue to higher VZ
> support?

Testing with the RIPE Atlas probes show that 121.51.0.13 (which is
pingable) is not reachable at all from AS 701. But it still has
reachability problems from other networks in the world, with many
timeouts (but the problem at 701 is more radical).

At least 121.51.0.0/16 and 121.51.0.0/23 seems to be seen in many
places.


Re: amazon.com multiple SPF records

2021-06-07 Thread Stephane Bortzmeyer
On Sat, Jun 05, 2021 at 07:59:40AM -0400,
 Brad Barnett  wrote 
 a message of 15 lines which said:

> If anyone at Amazon is paying attention, you have duplicate spf1 records
> for amazon.com:

If so, it is now gone. Not one RIPE Atlas probe see this duplication:

% blaeu-resolve -r 100 --ednssize 4096 --type TXT amazon.com
["facebook-domain-verification=d9u57u52gylohx845ogo1axzpywpmq"
"google-site-verification=14wgw2mdnmxchg8plinf7lgqqe0owwhqoq0hkhb7rdq"
"ms=4b600b22799eb2cac0d8ff0a3a3caeca5ee2bf3a"
"pardot326621=b26a7b44d7c73d119ef9dfd1a24d93c77d583ac50ba4ecedd899a9134734403b"
"spf2.0/pra include:spf1.amazon.com include:spf2.amazon.com
include:amazonses.co "v=spf1 include:spf1.amazon.com
include:spf2.amazon.com include:amazonses.com -a
"wrike-verification=mzi3nzm2odo2ndk5mje4njq2mwjmotewmgmxm2mznzjmnwjly2u5zdu4mmvl]
: 95 occurrences
[ (TRUNCATED - EDNS buffer size was 4096 ) ] : 1 occurrences
Test #30676407 done at 2021-06-07T14:31:16Z



Re: RADb

2021-05-10 Thread Stephane Bortzmeyer
On Mon, May 10, 2021 at 09:25:36AM +0200,
 Marco Paesani  wrote 
 a message of 51 lines which said:

> do you have news about the issue on RADb ?

Note that it is discussed on the outages mailing list. No specific
news, just that it is down.


Re: DoD IP Space

2021-04-26 Thread Stephane Bortzmeyer
On Sun, Apr 25, 2021 at 08:29:51AM -0400,
 Jean St-Laurent via NANOG  wrote 
 a message of 38 lines which said:

> Let's see what will slowly appear in shodan.io and shadowserver.org

My favorite (but remember it can be a gigantic honeypot) is the
Ubiquiti router with the name
"HACKED-ROUTER-HELP-SOS-HAD-DUPE-PASSWORD" :-)





Re: Level3 DNS Issues

2020-09-10 Thread Stephane Bortzmeyer
On Thu, Sep 10, 2020 at 01:20:15PM +,
 Ryan O’Shea  wrote 
 a message of 41 lines which said:

> Is anyone experiencing timeouts when querying 209.244.0.3?

No, according to RIPE Atlas probes:

% blaeu-resolve --nameserver 209.244.0.3 --requested 100 --type SOA  .
Nameserver 209.244.0.3
[a.root-servers.net. nstld.verisign-grs.com. 2020090901 1800 900 604800 86400] 
: 88 occurrences 
[TIMEOUT] : 3 occurrences 
[a.root-servers.net. nstld.verisign-grs.com. 2020091000 1800 900 604800 86400] 
: 7 occurrences 
[a.root-servers.net. nstld.verisign-grs.com. 2020090900 1800 900 604800 86400] 
: 2 occurrences 
Test #27122281 done at 2020-09-10T14:04:21Z



Re: BGP route hijack by AS10990

2020-07-30 Thread Stephane Bortzmeyer
On Thu, Jul 30, 2020 at 11:21:04AM +0300,
 Hank Nussbacher  wrote 
 a message of 48 lines which said:

>See:

And:

https://stat.ripe.net/widget/bgp-update-activity#w.starttime=2020-07-16T05%3A00%3A00=2020-07-30T05%3A00%3A00=AS10990


Re: Comcast DNS Assistance?

2020-07-06 Thread Stephane Bortzmeyer
On Sun, Jul 05, 2020 at 09:30:27AM -0400,
 Dave Dechellis  wrote 
 a message of 15 lines which said:

> Last night we made some changes to our DNS-SEC environment at Tufts
> University and all changes seem to have propagated - but we're having
> issues resolving against Comcast's DNS servers.

RIPE Atlas probes on the Comcast AS do not show problems:

% blaeu-resolve --as 7922 --type MX --requested 100 --displayvalidation 
tufts.edu
[ (Authentic Data flag)  5 ppagent-prod-01.uit.tufts.edu. 5 
ppagent-prod-02.uit.tufts.edu. 5 ppagent-prod-03.uit.tufts.edu. 5 
ppagent-prod-04.uit.tufts.edu. 5 ppagent-prod-05.uit.tufts.edu. 5 
ppagent-prod-06.uit.tufts.edu.] : 70 occurrences 
[5 ppagent-prod-01.uit.tufts.edu. 5 ppagent-prod-02.uit.tufts.edu. 5 
ppagent-prod-03.uit.tufts.edu. 5 ppagent-prod-04.uit.tufts.edu. 5 
ppagent-prod-05.uit.tufts.edu. 5 ppagent-prod-06.uit.tufts.edu.] : 28 
occurrences 
[ERROR: SERVFAIL] : 1 occurrences 
Test #26172909 done at 2020-07-06T15:07:12Z

(The one SERVFAIL seems to be on a probe which does not use Comcast resolvers.)





Re: ISC BIND 9 breakage?

2020-03-25 Thread Stephane Bortzmeyer
On Wed, Mar 25, 2020 at 05:18:49PM +,
 Drew Weaver  wrote 
 a message of 97 lines which said:

> Did anyone else on CentOS 6 just have some DNS resolvers totally fall over?

dlv.isc.org signatures just expired.

> # NOTE: The ISC DLV zone is being phased out as of February
> 2017;

And yet some people still use it, it seems.


Re: Rogue objects in routing databases

2020-01-27 Thread Stephane Bortzmeyer
On Sat, Jan 25, 2020 at 12:06:51AM +0100,
Florian Brandstetter  wrote 
 a message of 53 lines which said:

> Examples of affected networks are:
> 
> 193.30.32.0/23
> 45.129.92.0/23
> 45.129.94.0/24

Note that 193.30.32.0/23 has also a ROA (announces by 42198). So,
announces by AS8100 would be RPKI-invalid.

45.129.92.0/23 also has a ROA. Strangely, the prefix stopped being
announced on sunday 26.

45.129.94.0/24 has a ROA and is normally announced.

So, if AS8100 were to use its abnormal route objects , announces would
still be refused by ROA-validating routers.




Re: DoD IP Space

2019-11-04 Thread Stephane Bortzmeyer
On Mon, Nov 04, 2019 at 10:55:47AM +0200,
 Chris Knipe  wrote 
 a message of 35 lines which said:

> We are experiencing a situation with a 3rd party (direct peer),
> wanting to advertise DoD address space to us, and we need to confirm
> whether they are allowed to do so or not.

The US military lacks money and sold parts of 22/8, like the radio
amateurs? :-) Apparently, no part of it ever appeared on the Internet.


Re: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft?

2019-10-11 Thread Stephane Bortzmeyer
On Fri, Oct 11, 2019 at 08:14:00PM +0900,
 Masataka Ohta  wrote 
 a message of 34 lines which said:

> they said they have never transferred the block

> So, RADB entry:
...
>   route:  146.51.0.0/16
>   origin: AS174
...
> is confirmed to be registration fraud.

I nitpick, but "never transferred the block" is not the same thing as
"never authorized Cogent to announce it".


Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

2019-10-07 Thread Stephane Bortzmeyer
On Fri, Oct 04, 2019 at 03:52:26PM -0400,
 Phil Pishioneri  wrote 
 a message of 9 lines which said:

> Using Cloud Resources to Dramatically Improve Internet Routing
> UMass Amherst researchers to use cloud-based ‘logically centralized
> control’

Executive summary: it's SDN for BGP. Centralizing Internet routing,
what could go wrong? (As the authors say, "One reason is there is no
single entity that has a big picture of what is going on, no
manager". I wonder who will be Internet's manager.)

Otherwise, an impressive amount of WTF. My favorite: "while
communication by servers ___on the ground___ might take hundreds of
milliseconds, in the cloud the same operation may take only one
millisecond from one machine to another" I thought that universities
were full of serious people, but university of Massachusets may be an
exception?


Re: This DNS over HTTP thing

2019-10-01 Thread Stephane Bortzmeyer
On Tue, Oct 01, 2019 at 12:11:32PM +0200,
 Jeroen Massar  wrote 
 a message of 101 lines which said:

>  - Using a centralized/forced-upon DNS service (be that over DoT/DoH
>  or even plain old Do53

Yes, but people using a public DNS resolver (of a big US corporation)
over UDP is quite an old thing and nobody complained. I really wonder
why there was so little reaction against OpenDNS or Google Public DNS
and suddently a lot of outcry against DoH...

> You might also want to look into this amazing thing called Tor if
> you really want privacy.

I know it, and use it and it is awfully slow. Telling to people who
want privacy that they need to adopt the difficult and costly (in
performance) solutions made for iranian opponents won't help to
improve security.

> Noting that many ISPs are deploying both DoT and DoH next to Do53.

Fact-checking: could you name some? (I do not know even one.)


Re: This DNS over HTTP thing

2019-10-01 Thread Stephane Bortzmeyer
On Tue, Oct 01, 2019 at 10:35:31AM +0200,
 Jeroen Massar  wrote 
 a message of 29 lines which said:

> Correct: for the DoH protocol it is not that goal, there it solely
> is "encryption". But DoT already solves that.

DoT is fine, (and my own public resolver activates it) but, as you
know, it is too easy to block, either explicitely, or as a by-product
of a "only port 443" policy.

Also, most of the complaints (for instance by the lobby who wrote to
the US congress) about DoH apply also to DoT (for instance, like DoH,
it prevents the ISP to modify or even to see the DNS requests and
responses, so the lobbies who don't like DoH won't like DoT either).

> For the implementation though of DoH (what most people have a
> problem with), the sole goal is centralization

This is your personal opinion, not a fact. (Speaking as someone who
deployed a DoH resolver.)

> and moving the information collection from the ISP to single
> entities that are already collection so much data,

That's why we need more DoH resolvers. Install one!

> The point is that the claimed goal (for the deployment) is that it
> gives users 'privacy', but in the end that 'privacy' just moves from
> the ISP that the user pays to an unrelated company that wants to see
> it all...

Security is often moving stuff to a different trusted party (think of
VPNs, for instance).


Re: AWS issues with 172.0.0.0/12

2019-10-01 Thread Stephane Bortzmeyer
On Tue, Oct 01, 2019 at 09:09:38AM +0100,
 Christopher Morrow  wrote 
 a message of 27 lines which said:

> possible that this is various AWS customers making iptables/firewall mistakes?
>   "block that pesky rfc1918 172/12 space!!"

May be, but I used the same target as Mehmet.


Re: This DNS over HTTP thing

2019-10-01 Thread Stephane Bortzmeyer
On Tue, Oct 01, 2019 at 09:55:54AM +0200,
 Jeroen Massar  wrote 
 a message of 26 lines which said:

> > (Because this canary domain contradicts DoH's goals, by allowing
> > the very party you don't trust to remotely disable security.)
> 
> The goal is centralization of DNS

Hmmm, no, read RFC 8484 (section 1).

> While the 'connection to the recursor' is 'encrypted', the recursor
> is still in clear text... one just moves who can see what you are
> doing with this.

As with any cryptographic protocol. Same thing with VPNs, SSH and
whatever: the remote end can see what you do. What's your point?



Re: AWS issues with 172.0.0.0/12

2019-10-01 Thread Stephane Bortzmeyer
On Mon, Sep 30, 2019 at 11:38:25PM -0700,
 Mehmet Akcin  wrote 
 a message of 131 lines which said:

> Here you go

The two RIPE Atlas probes in the AT prefix seem able to reach AWS:

%  blaeu-traceroute --protocol TCP --size=0 --port=80 --first_hop=64 --format 
--prefix 172.0.0.0/12 --requested 10 52.21.66.90
Measurement #22932983 Traceroute 52.21.66.90 from prefix 172.0.0.0/12 uses 2 
probes
2 probes reported
Test #22932983 done at 2019-10-01T07:46:00Z
From:  172.10.12.57018ATT-INTERNET4 - AT Services, Inc., US
Source address:  172.10.12.5
Probe ID:  11203
6452.21.66.9014618AMAZON-AES - Amazon.com, Inc., US[11.43, 
11.158, 10.806]

From:  172.8.16.487018ATT-INTERNET4 - AT Services, Inc., US
Source address:  192.168.1.73
Probe ID:  51354
6452.21.66.9014618AMAZON-AES - Amazon.com, Inc., US[22.301, 
21.612, 21.615]



Re: This DNS over HTTP thing

2019-10-01 Thread Stephane Bortzmeyer
On Tue, Oct 01, 2019 at 08:22:58AM +0100,
 Brandon Butterworth  wrote 
 a message of 37 lines which said:

> Here are some UKNOF presentations on it -

Note that the UK is probably the country in Europe with the biggest
use of lying DNS resolvers for censorship. No wonder that the people
who censor don't like anti-censorship techniques.


Re: This DNS over HTTP thing

2019-10-01 Thread Stephane Bortzmeyer
On Mon, Sep 30, 2019 at 11:56:33PM -0400,
 Brandon Martin  wrote 
 a message of 10 lines which said:

> It's use-application-dns.net.  NXDOMAIN it, and Mozilla (at least)
> will go back to using your local DNS server list as per usual.

Unless, I hope, the user explicitely overrides this. (Because this
canary domain contradicts DoH's goals, by allowing the very party you
don't trust to remotely disable security.)


Re: This DNS over HTTP thing

2019-10-01 Thread Stephane Bortzmeyer
On Mon, Sep 30, 2019 at 11:46:04PM -0400,
 Fred Baker  wrote 
 a message of 28 lines which said:

> > Is there an official name for it I should be searching for?
> 
> The IETF calls it "DoH", pronounced like
> "Dough". https://datatracker.ietf.org/wg/doh/about/

And it is standardized in RFC 8484, which was published one year ago. 

> There are a number of such services from Google, Amazon, and
> others.

And you can build your own quite easily, these days, to avoid being
dependent on a few US corporations.

> One thing that bothers me about the Google implementation is that
> they apparently download the IANA zone and, in effect, operate as an
> informal root server. Not that I am protective of the root per se,
> but the root operators operate by an ethos described in RSSAC001
> (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf.).

This is in line with RFC 7706 "Decreasing Access Time to Root Servers
by Running One on Loopback", and the root zone operators explicitely
authorize zone transfer, partially for this purpose.




Re: 44/8

2019-07-19 Thread Stephane Bortzmeyer
On Thu, Jul 18, 2019 at 11:13:24PM -0400,
 Majdi S. Abbas  wrote 
 a message of 26 lines which said:

>   Amusingly, they still seem to be advertising the covering
> aggregate,

Are you sure? RIPE stat shows it stopped one month ago

Same thing on other looking glasses.


Re: who attacks the weather channel?

2019-04-18 Thread Stephane Bortzmeyer
On Thu, Apr 18, 2019 at 03:16:34PM +,
 Kain, Rebecca (.)  wrote 
 a message of 69 lines which said:

> https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html

May be these people?

https://en.wikipedia.org/wiki/Weather_Underground


A Deep Dive on the Recent Widespread DNS Hijacking Attacks

2019-02-23 Thread Stephane Bortzmeyer
Very good article, very detailed, with a lot of technical precisions,
about the recent domain name hijackings (not using the DNS, just good
old hijackings at registrar or hoster).

https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/


Re: A Zero Spam Mail System [Feedback Request]

2019-02-17 Thread Stephane Bortzmeyer
On Mon, Feb 18, 2019 at 12:28:21PM +0530,
 Viruthagiri Thirumavalavan  wrote 
 a message of 111 lines which said:

> Just gone through all your replies.

And apparently you did not read them and did not take any lesson in
it.

> Literally everyone attacking me here.

In the current thread, NOT ONE reply was an attack. All the replies
were kind and considerate (franly, much more than what you deserved)
and explained why you are wrong. Read them again. Really. It would
help you. This is probably your last chance before everyone definitely
classify you as "useless crank".

> One guy was attacking me for my poor english skills. Excuse me for
> not being poetic in my paper. I studied in my local
> language. English was an alien language to me.

English is not my mother tongue either and I make many mistakes. But I
try to fix them, and do not complain when people who speak better
english correct me. Frankly, as someone who has trouble understanding
people speaking at the IETF meetings, I do not think that english is
your main problem. 

> None of never completed my paper.

Nobody is forced to. There are more interesting papers to read that
anyone have time to do so. We have to decide what to read and what to
ignore. Why should we drop promising papers and read yours, when the
external appearance is that of a guy who does not listen, does not
know what he is talking about, and just complains endlessly how the
world is unfair?


Re: A Zero Spam Mail System [Feedback Request]

2019-02-17 Thread Stephane Bortzmeyer
On Mon, Feb 18, 2019 at 07:33:32AM +0530,
 Viruthagiri Thirumavalavan  wrote 
 a message of 515 lines which said:

> My name is Viruthagiri Thirumavalavan. I'm the guy who proposed SMTP
> over TLS on Port 26

Besides all the excellent remarks that were made here (and I seriously
urge you to read them; really), I want to add:

> It's my 5 years of research. So it's worth more than 50 words.

You have a very strange way of measuring the importance of
something. A lot of people spent 30 years or more on useless and
stupid things. The time past is *not* a good indicator of value.

> My prototype codebase has around 200,000 lines of code. [To be exact:
> 466,965 ++ 254,169 --]

Same thing for source code. Boasting of the number of lines, as if it
measured value of the program, won't make people interested. Really,
this metric was abandoned or at east downplayed more than thirty years
ago.

> Sequoia Capital is one of the well known venture firm in the
> world. They have invested in over 250 companies since 1972,
> including Apple, Google, Oracle, PayPal, Stripe, YouTube, Instagram,
> Yahoo! and WhatsApp.

Come on, most people on this list have a lot of experience with the
wonderful world of Silicon Valley startups. We have seen a lot of
dollars invested in really stupid projects. "One VC gave me money"
proves nothing, except that some people have too much money and too
little sense.


Re: 2019-01-11 ARIN.NET DNSSEC Outage – Post-Mortem (was: Re: ARIN NS down?)

2019-01-14 Thread Stephane Bortzmeyer
On Fri, Jan 11, 2019 at 08:59:10PM +,
 John Curran  wrote 
 a message of 125 lines which said:

> Our monitoring systems reported being green until the signatures
> expired as they presently check that the SOA's match on the internal
> and external nameservers.

For checking of DNSSEC signatures expiration (something which is as
crucial to monitor as the PKIX certificates expiration), I use

and I'm happy with it.


Re: Dnssec still inoperable on the internet ?— was ARIN NS down?

2019-01-11 Thread Stephane Bortzmeyer
On Fri, Jan 11, 2019 at 07:58:25AM -0800,
 Ca By  wrote 
 a message of 488 lines which said:

> No your threats and deploy wisely

Say no to the threats :-)




Re: ARIN NS down?

2019-01-11 Thread Stephane Bortzmeyer
On Fri, Jan 11, 2019 at 07:57:25PM +0530,
 Suresh Ramasubramanian  wrote 
 a message of 56 lines which said:

> couldn't get address for 'ns1.arin.net': not found

DNSSEC issue, they let the signatures expire



Re: CenturyLink

2018-12-28 Thread Stephane Bortzmeyer
On Fri, Dec 28, 2018 at 07:07:42AM +,
 Erik Sundberg  wrote 
 a message of 131 lines which said:

> CenturyLink will be conducting an extensive post-incident
> investigation and root cause analysis to provide follow-up
> information to our customers

Is this problem also responsible for the 911 outage? If so, the
post-mortem analysis is not useful only for CenturyLink customers but
for everyone on the west coast.


Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

2018-09-26 Thread Stephane Bortzmeyer
On Wed, Sep 26, 2018 at 11:28:06AM +0200,
 Jens Link  wrote 
 a message of 14 lines which said:

> quick and dirty:

Indeed. For instance, the delay depends wether the cache it hot or
cold (measuring response time for an authoritative server is easier).


Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

2018-09-26 Thread Stephane Bortzmeyer
On Wed, Sep 26, 2018 at 09:21:21AM +0100,
 Colin Johnston  wrote 
 a message of 16 lines which said:

> also could use ripe atlas

Which embeds clients for ICMP Echo, DNS, NTP, TLS, arbitrary TCP (with
some hacks), and, with serious limitations, HTTP.


Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

2018-09-26 Thread Stephane Bortzmeyer
On Wed, Sep 26, 2018 at 10:59:02AM +0300,
 Michael Bullut  wrote 
 a message of 192 lines which said:

> How would you gauge good DNS performance?

To test {XXX} performance, you use a {XXX} client, where XXX = DNS,
HTTP, SSH, LDAP, etc.



Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

2018-09-26 Thread Stephane Bortzmeyer
On Wed, Sep 26, 2018 at 10:52:07AM +0300,
 Michael Bullut  wrote 
 a message of 162 lines which said:

> Has anyone deployed the aforementioned in your individual networks?
> A quick test suggests it is quite fast compared with Google's
> D.N.S. resolvers:

Well, you don't test a DNS service with ICMP echo, for reasons you
certainly know.

Also, do not compare only public resolvers between themselves, also
compare with a local resolver (always the closest from the clients).


Re: Bogon prefix c0f:f618::/32 announced via Cogent

2018-07-16 Thread Stephane Bortzmeyer
On Sat, Jul 14, 2018 at 08:18:25AM +0800,
 Siyuan Miao  wrote 
 a message of 27 lines which said:

> c0f:f618::/32 originated from AS327814 is announcing via Cogent for several
> weeks.

Apparently withdrawn 2018-07-14 around 16:00:00 UTC. Your mail to NANOG was
effective :-)


Re: broken DNS

2018-06-07 Thread Stephane Bortzmeyer
On Thu, Jun 07, 2018 at 11:31:15AM -0400,
 harbor235  wrote 
 a message of 5 lines which said:

> I was hoping for some DNS wisdom,

Then this is more a dns-operations mailing list issue.

> would a change in a SOA record cause a
> DNSSEC  broken trust chain? incorrect RRSIG?

No. The SOA record is not part of the trust chain (unless of course it
is the record you query).


Re: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours.

2018-04-24 Thread Stephane Bortzmeyer
On Tue, Apr 24, 2018 at 08:35:17PM +0200,
 Fredrik Korsbäck  wrote 
 a message of 28 lines which said:

> Surprised this hasnt "made the news" over at this list yet.

It may be also because NANOG email is handled by Google, who broke its antispam:

: host aspmx.l.google.com[2a00:1450:400c:c08::1a] said:
550-5.7.1 This message does not have authentication information or
fails to
pass 550-5.7.1 authentication checks. To best protect our
users from spam,
the 550-5.7.1 message has been blocked. Please visit
550-5.7.1
https://support.google.com/mail/answer/81126#authentication
for more 550
5.7.1 information. v20-v6si12240130wrb.82 - gsmtp
(in reply to end of DATA
command)



Re: Yet another Quadruple DNS?

2018-04-03 Thread Stephane Bortzmeyer
On Tue, Apr 03, 2018 at 10:54:34AM -0400,
 Rich Kulawiec  wrote 
 a message of 10 lines which said:

> Watch what you wish for: you might get it.  The number of
> attack/abuse vectors (and the severity of their consequences for
> security and privacy) involved in doing auto-update may rival those
> involved in not doing auto-update.

Also, there is the risk of getting updates that will disable some
features, if there is a change in the commercial strategy of the
vendor
.
All these risks are documented in RFC 8240, a highly recommended
reading.


Re: Yet another Quadruple DNS?

2018-04-03 Thread Stephane Bortzmeyer
On Tue, Apr 03, 2018 at 03:01:19AM -0700,
 Brian Kantor  wrote 
 a message of 12 lines which said:

> > That would be a terrible violation of network neutrality. I hope
> > that such ISP will go bankrupt.
> 
> On the contrary: it will enable them to collect more usage
> statistics and from that sell more directed advertising.  They will
> make MORE money off doing so.  And so they will.

Then, I'm going to stop reading NANOG and go to the movie
instead. Because, in the movies, the bad guys lose.



Re: Yet another Quadruple DNS?

2018-04-03 Thread Stephane Bortzmeyer
On Sun, Apr 01, 2018 at 02:03:41PM -0600,
 Paul Ebersman  wrote 
 a message of 38 lines which said:

> And EDNS client subnet mostly works.

It is awful, privacy-wise, complicates the cache a lot and seriously
decreases hit rate in cache (since the key to a cached resource is no
longer type+name but type+name+source_address).

> And yes, running your own resolver is more private. So is running
> your own home linux server instead of antique consumer OSs on
> consumer grade gear and using VPNs. But how many folks can do that?

It is not just an issue of knowledge and skills. Even if you have
both, you may lack time, and prefer a shrink-wrapped solution. The
future is in "boxes" which are both ready-to-use (for the guy who
lacks sysadmin skills, and/or lacks time) and open (for the
tinkerer). The Turris Omnia  is a very
good example.

> This also ignores the shift if every house in the world did its own
> recursion. TLD servers and auth servers all over the world would
> have to massively up their capacity to cope.

With my TLD operator hat, I tend to say it is not a problem, we
already have a lot of extra capacity, to handle dDoS.

> As long as ISPs don't actually disallow running of recursive servers

That would be a terrible violation of network neutrality. I hope that
such ISP will go bankrupt.



Re: Yet another Quadruple DNS?

2018-04-03 Thread Stephane Bortzmeyer
On Sun, Apr 01, 2018 at 09:22:10AM -0700,
 Stephen Satchell  wrote 
 a message of 39 lines which said:

> Recursive lookups take bandwidth and wall time.  The closer you can
> get your recursive DNS server to the core of the internet, the
> faster the lookups.

I think the exact opposite is true: many DNS requests hit the cache,
so the important factor is the latency between the end user and the
cache. So, local resolvers win.

> This is particularly true of mobile and satellite.

Yes, because they have awful latency, it is important to have a local
resolver.

> (I wonder if the Internet Systems Consortium has considered adding a
> cache-hit counter, or even a very coarse heat map (say, four 16-bit counters
> cycled every five minutes), to DNS entries, to figure out the best ones to
> drop?  It would increase the complexity of BIND, but the benefit for a BIND
> server serving a largish customer population could be significant.

Making the largest and richest services even faster and so increase
centralisation? It does not strike me as a good strategy.

> I've not personally measured the number of times a look-up could be
> satisfied from a cache in a production environment;

For instance, at my home:

% cache.stats()
[hit] => 276089296
[delete] => 5
[miss] => 423661208
[insert] => 18850452

> The main reason for *not* implementing recursion exclusively in CPE
> is that a recursive lookup is a complex operation, and I have my
> doubts if BIND or equivalent could be maintained properly in, say, a
> wireless access point (router) -- how would you update a hints
> table?

There is nothing DNS-specific here: routers/CPE with automatic updates
exist for several years (I use the Turris Omnia
). The hints file is the *last* problem:
most IP addresses of the root name servers didn't change for more than
ten years.




Re: Yet another Quadruple DNS?

2018-03-30 Thread Stephane Bortzmeyer
On Fri, Mar 30, 2018 at 03:57:24PM +0100,
 William Waites  wrote 
 a message of 48 lines which said:

> > 77.77.77.77 - Dadeh Gostar Asr Novin P.J.S. Co. (Iran) | 77.77.64/19 |
> > recursion-yes
> 
> Well, that one's a little odd:

I think that, for the government of this country, it is seen as a
feature, not a bug.


Re: Yet another Quadruple DNS?

2018-03-30 Thread Stephane Bortzmeyer
On Fri, Mar 30, 2018 at 06:46:19AM -0800,
 Royce Williams  wrote 
 a message of 19 lines which said:

> Full survey - with owners of the largest bit-boundary-aligned blocks
> that contain them - here:
> 
> https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1

Unlike what you say, 112.112.112.112 works (note for the
humour-impaired: there is a trick):

% dig @112.112.112.112  facebook.com

; <<>> DiG 9.10.3-P4-Debian <<>> @112.112.112.112 facebook.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41543
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;facebook.com.  IN A

;; ANSWER SECTION:
facebook.com.   126 IN A 31.13.74.1

;; Query time: 218 msec
;; SERVER: 112.112.112.112#53(112.112.112.112)
;; WHEN: Fri Mar 30 16:54:12 CEST 2018
;; MSG SIZE  rcvd: 57


Re: Yet another Quadruple DNS?

2018-03-30 Thread Stephane Bortzmeyer
On Thu, Mar 29, 2018 at 08:29:57AM -0700,
 Bill Woodcock  wrote 
 a message of 53 lines which said:

> there are ISPs who are internally capturing 8.8.8.8, and who try to
> do the same with 9.9.9.9.  Which is why it’s so important to do
> cryptographic validation of the server and encryption of the
> transport, as well as DNSSEC validation.

And the good thing is that RFC 8310 has been published one week
ago. I'm waiting for its deployment in Quad9 :-)

https://www.rfc-editor.org/info/rfc8310


Re: Yet another Quadruple DNS?

2018-03-29 Thread Stephane Bortzmeyer
On Thu, Mar 29, 2018 at 09:08:38AM -0500,
 Chris Adams  wrote 
 a message of 12 lines which said:

> I've never really understood this - if you don't trust your ISP's
> DNS, why would you trust them not to transparently intercept any
> well-known third-party DNS?

Technically, tweaking your DNS resolver to lie (and/or to log) is much
easier and faster (and way less expensive) than setting up a
packet interception and rewriting device at line rate.

You're right, it is technically possible to "transparently intercept
any well-known third-party DNS". Two main ways, a routing trick (like
the one used in Turkey against Google Public DNS
)
which is simple, and packet-level interception devices like in China
,
which is not for the ordinary ISP.

That's why public DNS resolvers are not really a solution against
strong adversaries *unless* you authenticate and encrypt the
connection. Quad9 allows that
.

Public DNS resolvers still help against "ordinary" adversaries. (If
your ennemy is the NSA, you have other problems, anyway.)



Re: Yet another Quadruple DNS?

2018-03-29 Thread Stephane Bortzmeyer
On Thu, Mar 29, 2018 at 07:01:59AM -0700,
 Brian Kantor  wrote 
 a message of 20 lines which said:

> I believe that centralized DNS resolvers such as 8.8.8.8 are of
> benefit to those folks who can't run their own recursive resolver
> because of OS, hardware,

Hardware is not a real problem. A Raspberry Pi is more than enough to
run a resolver for a typical home.

> or skill limitations,

That's certainly a more important issue. Even when someone has skills,
he or she may not have the time and inclination to do system
administration at home. The solution is proper packaging of this
DNS function in ready-made boxes such as the Turris Omnia


> and yet do not trust the ones provided by their ISPs.

Unfortunately, the users are often right here :-(



Re: Yet another Quadruple DNS?

2018-03-29 Thread Stephane Bortzmeyer
On Thu, Mar 29, 2018 at 07:33:08AM -0400,
 Matt Hoppes  wrote 
 a message of 7 lines which said:

> We already have 8.8.8.8 and 8.8.4.4.

And 9.9.9.9 and several others public DNS resolvers.

> And any reputable company or ISP should be running their own.

I fully agree.
 
> What purpose would this serve?

In Europe, the most common technique of censorship is through lying
DNS resolvers. So, in order to go to forbidden Web sites (music and
film sharing, for instance), many users switched from the ISP's
resolver (which implements the censorship) to a public resolver. See
my talk at NANOG



Re: Yet another Quadruple DNS?

2018-03-29 Thread Stephane Bortzmeyer
On Thu, Mar 29, 2018 at 12:16:48PM +0100,
 Tony Finch  wrote 
 a message of 15 lines which said:

> Also the very amusing
> 
> https://twitter.com/eastdakota/status/970359846548549632

Less amusing, for a DNS service, the brokenness of reverse service:

% dig -x 1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> -x 1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24536
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa.  IN PTR

;; Query time: 516 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Mar 29 13:37:54 CEST 2018
;; MSG SIZE  rcvd: 49


% dig @ns1.apnic.net. NS 1.1.1.in-addr.arpa

; <<>> DiG 9.10.3-P4-Debian <<>> @ns1.apnic.net. NS 1.1.1.in-addr.arpa
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48493
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;1.1.1.in-addr.arpa.IN NS

;; AUTHORITY SECTION:
1.1.1.in-addr.arpa. 86400 IN NS ns7.cloudflare.com.
1.1.1.in-addr.arpa. 86400 IN NS ns3.cloudflare.com.
1.1.1.in-addr.arpa. 172800 IN NSEC 113.1.1.in-addr.arpa. NS RRSIG NSEC
1.1.1.in-addr.arpa. 172800 IN RRSIG NSEC 5 5 172800 (
20180427150337 20180328140337 2371 
1.in-addr.arpa.
h44NAaTSpn5wvzTtddlUEKJ8+bikdaTDXnxh5M1bisO0
/NibM7iWfwcuaaWPvNeOutMdA0OBxGwbmErattfyXbRI
KWrBWopBkr8+uVo7BgBYBa2SqY7PdUyYIt40PTjwnsrl
lxBgaHMe1yz6qvQh2oljUJL45HkJnVWoHnuTRq8= )

;; Query time: 317 msec
;; SERVER: 2001:dc0:2001:0:4608::25#53(2001:dc0:2001:0:4608::25)
;; WHEN: Thu Mar 29 13:38:05 CEST 2018
;; MSG SIZE  rcvd: 313


% dig @ns7.cloudflare.com -x 1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> @ns7.cloudflare.com -x 1.1.1.1
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 10538
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa.  IN PTR

;; Query time: 7 msec
;; SERVER: 2400:cb00:2049:1::a29f:606#53(2400:cb00:2049:1::a29f:606)
;; WHEN: Thu Mar 29 13:38:25 CEST 2018
;; MSG SIZE  rcvd: 49


% dig @ns3.cloudflare.com -x 1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> @ns3.cloudflare.com -x 1.1.1.1
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 27962
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa.  IN PTR

;; Query time: 6 msec
;; SERVER: 2400:cb00:2049:1::a29f:21#53(2400:cb00:2049:1::a29f:21)
;; WHEN: Thu Mar 29 13:38:33 CEST 2018
;; MSG SIZE  rcvd: 49



Re: Yet another Quadruple DNS?

2018-03-29 Thread Stephane Bortzmeyer
On Wed, Mar 28, 2018 at 11:16:15PM +0300,
 DaKnOb  wrote 
 a message of 25 lines which said:

> Out of 1,000 RIPE Atlas Probes, only 34 report it as unreachable.

It's still a lot for IPv4. And it measures ony filtering, not hijacking
(which seems to exist, some probes get a DNS reply without the AD
bit, for instance).

Because of the heavy use of 1.1.1.1 in documentation, you can expect a
lot of networks to have trouble. Hey, 1.1.1.1 is even used in
Cloudflare's own documentation!




Re: Spectre/Meltdown impact on network devices

2018-01-08 Thread Stephane Bortzmeyer
On Mon, Jan 08, 2018 at 11:41:04AM +0100,
 Stephane Bortzmeyer <bortzme...@nic.fr> wrote 
 a message of 20 lines which said:

> > I'm curious to hear the impact on network devices of this new hardware
> > flaws that everybody talk about. Yes, the Meltdown/Spectre flaws.
> 
> https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180104-cpusidechannel

And for Juniper :

https://kb.juniper.net/InfoCenter/index?page=content=JSA10842=RSS



Re: Spectre/Meltdown impact on network devices

2018-01-08 Thread Stephane Bortzmeyer
On Sun, Jan 07, 2018 at 02:02:24PM -0500,
 Jean | ddostest.me via NANOG  wrote 
 a message of 21 lines which said:

> I'm curious to hear the impact on network devices of this new hardware
> flaws that everybody talk about. Yes, the Meltdown/Spectre flaws.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180104-cpusidechannel

> I understand that one need access but still it could be possible for one
> to social engineer a NOC user, hijack the account with limited access
> and maybe run the "exploit".

There are other ways to tun code on the target machine. JavaScript is
the most obvious one (and there are JavaScript exploits for Meltdown)
but, of course, the typical router does not have a Web browser. So,
the best solution, for the attacker, is probably to exploit a bug in
the BGP parser (as we have seen with attribute 99, BGP parsers have
bugs): with a buffer overflow, you may be able to run code you
choose. Purely theoretical at this stage, I didn't try.


Re: Google DNS intermittent ServFail for Disney subdomain

2017-10-20 Thread Stephane Bortzmeyer
On Fri, Oct 20, 2017 at 03:29:15PM +0200,
 Filip Hruska  wrote 
 a message of 49 lines which said:

> Would be great if makers of home routers would implement full recursive DNS
> resolvers

The good ones do 


Re: Google DNS --- Figuring out which DNS Cluster you are using

2017-08-24 Thread Stephane Bortzmeyer
On Thu, Aug 24, 2017 at 10:53:58AM +1000,
 Mark Andrews  wrote 
 a message of 39 lines which said:

> If Google was being sensible the servers would just return the
> information along with the answer.  They all support EDNS.

I fully agree with you that NSID (RFC 5001) is great and Google should
really deploy it. However:

> e.g. dig +nsid @8.8.8.8

I assume that Google wants also to be debuggable by people who work on
inferior operating systems, and have no dig. Hence this trick. For
instance, L.root-servers.net has both NSID and a special name,
identity.l.root-servers.org (see RFC 7108).



Re: loc.gov

2017-07-09 Thread Stephane Bortzmeyer
On Sat, Jul 08, 2017 at 09:41:29PM -0400,
 Nicholas Oas  wrote 
 a message of 37 lines which said:

> Have isitdownorjustme sites simply superceded the need for such
> lists?

isitdownorjustme-type sites are very limited: one vantage point, and
few (or none) indication of the methodology they use. And there is not
only the Web!

Networks must be tested with more focused tools, from many
places. For exemple RIPE Atlas probes






Re: IP Hijacking For Dummies

2017-06-11 Thread Stephane Bortzmeyer
On Mon, Jun 05, 2017 at 04:46:04PM -0700,
 Ronald F. Guilmette  wrote 
 a message of 85 lines which said:

> Late last night, I put together the following simple annotated listing of
> the routes being announced by AS34991.

Note that they apparently stopped on 7 june.


Re: IP Hijacking For Dummies

2017-06-09 Thread Stephane Bortzmeyer
On Mon, Jun 05, 2017 at 04:46:04PM -0700,
 Ronald F. Guilmette  wrote 
 a message of 85 lines which said:

> I just think that by now, in 2017, we should have a somewhat more
> skilled class of frauds, rogues, criminals and spies on the
> Internet.

"This city deserves a better class of criminal and I'm gonna give it to them."

-- The Joker (in one of the Batman movies)




Re: Question to Google

2017-05-15 Thread Stephane Bortzmeyer
On Mon, May 15, 2017 at 07:55:41AM -0700,
 Damian Menscher  wrote 
 a message of 82 lines which said:

> Can you point to published studies where the root and .com server
> operators analyzed Todd's questions?

For the root, the most comprehensive one is probably SAC 18
 A good summary is




Re: Question to Google

2017-05-15 Thread Stephane Bortzmeyer
On Mon, May 15, 2017 at 09:20:17AM -0400,
 Todd Underwood  wrote 
 a message of 66 lines which said:

> so implications that this is somehow related to Google dragging
> their feet are silly.

Implying that the root name server operators, or Verisign (manager of
the .com name servers) did not test very thoroughly that everything is
fine with their DNS service is just as silly.


Re: Question to Google

2017-05-15 Thread Stephane Bortzmeyer
>   Unfortunately, every time we've looked at the data, the
>   conclusion has been that it would cause unwarranted user
>   impact. IIRC the most recent blocker was a major US ISP whose
>   clients would experience breakage if even just one NS record
>   was dual-stacked.

There are many zones (including your isc.org) that have several name
servers dual-stacked, and they didn't notice a problem. Furthermore,
since the DNS is a tree, resolution of google.com requires a proper
resolution of the root and .com, both having IPv6 name servers.

So, this answer is at least insufficient.


Re: Financial services BGP hijack last week?

2017-05-02 Thread Stephane Bortzmeyer
On Tue, May 02, 2017 at 01:49:04AM -0400,
 valdis.kletni...@vt.edu  wrote 
 a message of 29 lines which said:

> I didn't see any mention of this here.

You should susbcribe to @bgpstream on Twitter, and read BGPmon blog
:-)

https://twitter.com/bgpstream

https://bgpmon.net/bgpstream-and-the-curious-case-of-as12389/ (five
days ago)


Re: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

2017-03-17 Thread Stephane Bortzmeyer
On Fri, Mar 17, 2017 at 12:03:58PM +0300,
 Eygene Ryabinkin  wrote 
 a message of 71 lines which said:

> We (at Kurchatov Insitute) still use 144.206.0.0/16, the legacy
> block, and seeing the breakage rooted at ARIN since this night,
> {{{
> $ dig +trace -t soa 206.144.in-addr.arpa

According to DNSDB, it arrived yesterday, around 1630 UTC.


Re: ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

2017-03-17 Thread Stephane Bortzmeyer
On Fri, Mar 17, 2017 at 12:03:58PM +0300,
 Eygene Ryabinkin  wrote 
 a message of 71 lines which said:

> Seems like the other /16 from 144.in-addr.arpa are affected too
> (at least).

Also in 164.in-addr.arpa, it seems?


Re: Internet Governance Forum DNS

2016-12-09 Thread Stephane Bortzmeyer
On Thu, Dec 08, 2016 at 03:36:03AM -0500,
 Joly MacFie  wrote 
 a message of 13 lines which said:

> "www.intgovforum.org’s server DNS address could not be found."

Welcome to the UN...

Updated Date: 2016-12-08T14:33:28Z

It expired and was renewed yesterday (source: Internet governance
civil society mailing list). But the negative TTL of .org is 24
hours...


Re: Lawsuits for falsyfying DNS responses ?

2016-09-13 Thread Stephane Bortzmeyer
On Tue, Sep 13, 2016 at 07:12:59AM +0200,
 JÁKÓ András  wrote 
 a message of 18 lines which said:

> Blocking for that purpose usually means redirecting in
> practive. You'll redirect to a page that explains why the original
> site is not available.

It has practical consequences for the user: in France, DNS lies in
ISP's resolvers for "terrorist" sites redirect you to a Web site of
the police, which will get your source IP address and the site you
wanted (thanks to the Host: HTTP field). Clear blocking (DNS lie
returning localhost or NXDOMAIN) is a bit better for privacy. (But
less transparent about the censorship.)




Re: Chinese root CA issues rogue/fake certificates

2016-09-01 Thread Stephane Bortzmeyer
On Thu, Sep 01, 2016 at 11:36:57AM +1000,
 Matt Palmer  wrote 
 a message of 45 lines which said:

> I'd be surprised if most business continuity people could even name
> their cert provider,

And they're right because it would be a useless information: without
DANE, *any* CA can issue a certificate for *your* domain, whether you
are a client or not.


Re: number of characters in a domain?

2016-07-23 Thread Stephane Bortzmeyer
On Sat, Jul 23, 2016 at 08:35:57AM -0400,
 Jared Mauch  wrote 
 a message of 12 lines which said:

> I would consult RFC1035 for the label sizes, but the total length
> can include multiple labels up to 255 in length. Check section 2.3.4

On another mailing list, Marc Blanchet noticed the limit in the RFC is
255 octets, not characters, which make a difference if you use IDN :-)


Re: NANOG is five days late?

2016-07-18 Thread Stephane Bortzmeyer
On Mon, Jul 18, 2016 at 08:53:02AM -0500,
 Andy Koch  wrote 
 a message of 15 lines which said:

> The NANOG mailing list has a policy to hold the first post from all
> new subscribers and those who have not posted in a long time (one
> year+).

So, the batch of messages which has just been "liberated" were all by
newcomers?


NANOG is five days late?

2016-07-18 Thread Stephane Bortzmeyer
This message just arrived...

Received: from mail.nanog.org (localhost [127.0.0.1])
by mail.nanog.org (Postfix) with ESMTP id 96AA42D47BB;
Mon, 18 Jul 2016 13:15:14 + (UTC)
X-Original-To: nanog@nanog.org
Delivered-To: nanog@nanog.org
Received: from mail-it0-x245.google.com (mail-it0-x245.google.com
[IPv6:2607:f8b0:4001:c0b::245])
by mail.nanog.org (Postfix) with ESMTPS id 823B72D4651
for ; Wed, 13 Jul 2016 21:37:45 + (UTC)
Received: by mail-it0-x245.google.com with SMTP id f6so105118753ith.3
for ; Wed, 13 Jul 2016 14:37:45 -0700 (PDT)


Re: NIST NTP servers

2016-05-10 Thread Stephane Bortzmeyer
On Tue, May 10, 2016 at 10:52:28AM -0400,
 valdis.kletni...@vt.edu  wrote 
 a message of 37 lines which said:

> Note that they *do* have motivation to keep it working, simply
> because so much of their *own* gear (from gear for individual
> soldiers all the way to strategic bombers and aircraft carriers)
> wants a working GPS signal...

Yes, but they may switch it off for civilian use (by going encrypted,
for instance) at any time, if it is better for *their* operations.




Re: NIST NTP servers

2016-05-10 Thread Stephane Bortzmeyer
On Tue, May 10, 2016 at 06:48:52AM -0400,
 Steven Miano  wrote 
 a message of 41 lines which said:

> Going with an internal GPS/GLONASS/RADIO based S1 allows you to
> restrict incoming traffic and not rely on volunteers or external
> entities (which may undergo maintenance or budget issues).

You mean the GPS network is not managed by an external entity? With
budget issues?

http://www.schriever.af.mil/GPS


Re: www.cisco.com no resolve?

2016-03-19 Thread Stephane Bortzmeyer
On Sat, Mar 19, 2016 at 05:38:03AM +,
 Dmitry Sherman  wrote 
 a message of 13 lines which said:

> dig www.cisco.com @8.8.8.8

Better to test through the authoritative name servers. The problem was
there, as documented in


So, it was not because of the long CNAME chain, unlike what I wrote
previously.



Re: www.cisco.com no resolve?

2016-03-19 Thread Stephane Bortzmeyer
On Fri, Mar 18, 2016 at 10:53:15PM -0700,
 John Kinsella  wrote 
 a message of 49 lines which said:

> Confirmed in Northern California, on all 3 primary NS servers. A
> little Friday night maintenance window, maybe?

Isn't it simply because the alias chain is awfully long (five steps)
and it may fail with resolvers which are hardened against the
"infinite recursion" attack?

% dig A www.cisco.com
...
;; ANSWER SECTION:
www.cisco.com.  3538 IN CNAME www.cisco.com.akadns.net.
www.cisco.com.akadns.net. 238 IN CNAME wwwds.cisco.com.edgekey.net.
wwwds.cisco.com.edgekey.net. 21538 IN CNAME 
wwwds.cisco.com.edgekey.net.globalredir.akadns.net.
wwwds.cisco.com.edgekey.net.globalredir.akadns.net. 3538 IN CNAME 
e144.dscb.akamaiedge.net.
e144.dscb.akamaiedge.net. 20 IN A 104.93.242.137

http://www.ssi.gouv.fr/uploads/2014/12/idns_attack_anssi.pdf


Re: Level3 DNS not resolving for our domains

2015-12-30 Thread Stephane Bortzmeyer
On Wed, Dec 30, 2015 at 11:12:29PM +0100,
 Alarig Le Lay  wrote 
 a message of 35 lines which said:

> Both are in the same AS, perhaps a routing issue?

Indeed. This is a warning in ZoneMaster
 and I observe also that
10-15 % of the RIPE Atlas probes cannot resolve this name (so it is
not just Level 3). The name servers unfortunately do not reply to ICMP
echo so it is hard to debug.





Re: Level3 DNS not resolving for our domains

2015-12-30 Thread Stephane Bortzmeyer
On Wed, Dec 30, 2015 at 03:02:39PM -0600,
 Otto Monnig  wrote 
 a message of 24 lines which said:

> Sorry for not providing domains - I did so intentionally, as I
> believe this is a policy change at L3, rather than a technical
> issue.

And how are we supposed to debug, without even one domain name?

Level 3 public DNS resolvers work fine for me (tested with several
names, both DNSSEC and not DNSSEC).



Re: [CVE-2015-7755] Backdoor in Juniper/ScreenOS

2015-12-21 Thread Stephane Bortzmeyer
On Fri, Dec 18, 2015 at 09:28:11AM +0100,
 Stephane Bortzmeyer <bortzme...@nic.fr> wrote 
 a message of 6 lines which said:

> http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554

The password for the first backdoor (the one regarding telnet/SSH
access) has been published recently:

https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor

Shodan finds 26000 ScreenOS machines reachable from the Internet. It
will be a small botnet :-)


[CVE-2015-7755] Backdoor in Juniper/ScreenOS

2015-12-18 Thread Stephane Bortzmeyer
http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554
https://kb.juniper.net/InfoCenter/index?page=content=JSA10713=SIRT_1=LIST

Should we blame Juniper for letting a git repository open to
"unauthorized code" or should we congratulate them for their frankness
(few corporations would have admitted the problem)?


Re: DNSSEC and ISPs faking DNS responses

2015-12-17 Thread Stephane Bortzmeyer
On Thu, Nov 12, 2015 at 10:27:01PM -0500,
 Jean-Francois Mezei  wrote 
 a message of 66 lines which said:

> The Québec government is wanting to pass a law that will force ISPs
> to block and/or redirect certain sites it doesn't like.  (namely
> sites that offer on-line gambling that compete against its own Loto
> Québec).

You may be interested in this analysis of DNS censorship in some
european countries:

https://labs.ripe.net/Members/stephane_bortzmeyer/dns-censorship-dns-lies-seen-by-atlas-probes/


Re: Bluehost.com

2015-11-25 Thread Stephane Bortzmeyer
On Wed, Nov 25, 2015 at 08:41:55AM -0800,
 JoeSox  wrote 
 a message of 9 lines which said:

> Anyone have the scope on the outage for Bluehost?
> https://twitter.com/search?q=%23bluehostdown=tyah

The two name servers ns1.bluehost.com and ns2.bluehost.com are awfully
slow to respond:

% check-soa -i picturemotion.com
ns1.bluehost.com.
74.220.195.31: OK: 2012092007 (1382 ms)
ns2.bluehost.com.
69.89.16.4: OK: 2012092007 (1388 ms)

As a result, most clients timeout.

May be a DoS against the name servers?

bluehost.com itself is DNS-hosted on a completely different
architecture. So it works fine. But the nginx Web site replies 502
Gateway timeout, probably overloaded by all the clients trying to get
informed.

The Twitter accounts of Bluehost do not distribute any useful
information.


Re: Is there a DNS lookup, traceroute, ping and HTTP GET as a service?

2015-11-18 Thread Stephane Bortzmeyer
On Wed, Nov 18, 2015 at 02:38:28PM -0200,
 Kurt Kraut via NANOG  wrote 
 a message of 45 lines which said:

> About RIPE ATLAS, I already have one of their boxes and it never
> worked.  Simply doesn't appear as online. Their support just barely
> gave me some tips but with no meaningful result.

Like most people, I have a very good experience with RIPE Atlas
probes. If they fail (it never happened to me), there is a very
comprehensive FAQ 
and the nice people on the user mailing list (remember it is a
community service, the RIPE-NCC is not a commercial support team) are
very responsive.



Re: DNSSEC and ISPs faking DNS responses

2015-11-14 Thread Stephane Bortzmeyer
On Sat, Nov 14, 2015 at 01:36:06AM -0500,
 Jean-Francois Mezei  wrote 
 a message of 71 lines which said:

> Loto Québec is supposed to be testing for compliance, and I am not
> sure how they will do that short of having a subscription to every
> ISP that sells services in Québec.

They will simply use RIPE Atlas probes, as we all do to test our
networks from the outside.

Here, Bulgaria, where the mandatory blocking of gambling Web sites is
far from perfect (the right IP address is 5.226.176.16):

% python resolve-name.py --requested=500 --country=BG www.bet365.com 
Measurement #2930308 for www.bet365.com/A uses 94 probes

[] : 1 occurrences 
[193.24.240.122] : 1 occurrences 
[84.54.148.18] : 1 occurrences 
[212.73.128.166] : 1 occurrences 
[212.39.93.34] : 3 occurrences 
[ERROR: SERVFAIL] : 1 occurrences 
[5.226.176.16] : 75 occurrences 
[127.0.0.1] : 4 occurrences 
Test done at 2015-11-14T17:14:20Z

A few lying DNS resolvers but not much. 

> (Maybe they think they only have to test 3 ISPs, (telcos and
> cablecos) and don't realise they have over 100 ISPs to test for
> compliance).

My experience with these sort of organisations is that they don't care
about 100 % compliance. They're only interested in "good enough" (the
three largest ISPs...)



Re: DNSSEC and ISPs faking DNS responses

2015-11-13 Thread Stephane Bortzmeyer
On Fri, Nov 13, 2015 at 04:27:36AM -0500,
 Jean-Francois Mezei  wrote 
 a message of 34 lines which said:

> I'll have to research how other countries tried to implement similar
> schemes

https://www.afnic.fr/en/about-afnic/news/general-news/6584/show/the-afnic-scientific-council-shares-its-report-on-dns-based-internet-filtering.html


Re: DNSSEC and ISPs faking DNS responses

2015-11-13 Thread Stephane Bortzmeyer
On Fri, Nov 13, 2015 at 09:54:28AM +,
 a.l.m.bu...@lboro.ac.uk  wrote 
 a message of 20 lines which said:

> well, in EU I dont think that would ever fly.

It is done in France, for a long time
.




Re: DNSSEC and ISPs faking DNS responses

2015-11-13 Thread Stephane Bortzmeyer
On Fri, Nov 13, 2015 at 10:24:27AM -0800,
 Mark Milhollan  wrote 
 a message of 30 lines which said:

> Would the masses ever replace their stub with a full resolver?
> Doubtful, unless their OS vendor does it for them.

Fedora already does it, apparently, with the excellent dnssec-trigger.

> Would the various authoritiative operators be happy / agree?

Wearing my TLD operator hat: yes, we agree and we're ready for that.



Re: Chile Status?

2015-09-17 Thread Stephane Bortzmeyer
On Thu, Sep 17, 2015 at 09:58:54AM -0400,
 Jared Mauch  wrote 
 a message of 11 lines which said:

> If someone wants ripe ATLAS credits please send me a request
> off-list with your e-mail address registered for RIPE Atlas.

Even without credits, and an anonymous access, you can see that
several probes are reachable in Chile:

https://atlas.ripe.net/results/maps/network-coverage/

True, some are yellow (disconnected) but click on the yellow dot and
check the date: they were down even before the earthquake.

So, first conclusion: there is apparently no widespread Internet
outage.


Re: Chile Status?

2015-09-17 Thread Stephane Bortzmeyer
On Thu, Sep 17, 2015 at 10:00:46AM -0400,
 Marshall Eubanks  wrote 
 a message of 34 lines which said:

> shows green dots, but if you mouseover you see that the last
> connects are all old (pre-Earthquake).

You're right, I forgot to check that but the 17 RIPE Atlas probes
connected in Chile all answer and can ping NANOG Web site:

% python reachability+retrieve.py -v -r 500 --country CL 50.31.151.73
{'definitions': [{'description': 'Ping 50.31.151.73 from CL', 'af': 4, 
'packets': 3, 'type': 'ping', 'is_oneoff': True, 'target': '50.31.151.73'}], 
'probes': [{'requested': 500, 'type': 'country', 'value': 'CL'}]}
Measurement #2427363 to 50.31.151.73 uses 17 probes
17 probes reported
Test done at 2015-09-17T14:27:10Z
Tests: 51 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), 
average RTT: 182 ms

https://atlas.ripe.net/measurements/2427363/


Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica

2015-08-04 Thread Stephane Bortzmeyer
On Tue, Aug 04, 2015 at 10:03:33AM -0400,
 Jay Ashworth j...@baylink.com wrote 
 a message of 6 lines which said:

 Everyone got BIND updated?

For instance by replacing it with NSD or Unbound?


Re: Speaking of NTP...

2015-07-13 Thread Stephane Bortzmeyer
On Mon, Jul 13, 2015 at 01:17:01PM +,
 Matthew Huff mh...@ox.com wrote 
 a message of 14 lines which said:

 We have 5 NTP server: 2 x stratum 1 rubidium oscillator time servers
 with GPS sync, and 3 servers running NTP 4.2.6p5-3 synced to
 external internet based NTP stratum 1 servers. We monitor our NTP
 environment closely, and over the last 10+ years, normally all of
 our NTP servers are sync'ed within +/- 2 msec. Starting last Friday,
 we started seeing some remote NTP servers with GPS reference
 consistently offset by 10 msec.

I have no idea but I just wanted to remind people that, for a few
months, RIPE Atlas probes have been able to do NTP queries
https://atlas.ripe.net/docs/data_struct/#v4660_ntp so it may be a
cool way to monitor NTP servers from many points.



Re: REMINDER: LEAP SECOND

2015-06-22 Thread Stephane Bortzmeyer
On Mon, Jun 22, 2015 at 01:15:41PM +0100,
 Tony Finch d...@dotat.at wrote 
 a message of 15 lines which said:

 The problems are that UTC is unpredictable,

That's because the earth rotation is unpredictable. Any time based on
this buggy planet's movements will be unpredictable. Let's patch it
now!



Re: REMINDER: LEAP SECOND

2015-06-22 Thread Stephane Bortzmeyer
On Mon, Jun 22, 2015 at 12:38:28PM +,
 Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote 
 a message of 17 lines which said:

 So we need a new center of the universe and switch to stardate and
 thus solve the 32bit UNIX time problem for real this time?

Or simply use TAI which is the obvious time reference for Internet
devices. Using UTC in routers is madness. Routers and Internet servers
should use TAI internally and use UTC only when communicating with
humans (the inferior life form which crawls on the Earth surface and
cares about things like whether the sun is high at noon, for outside
picnics).




Re: AS4788 Telecom Malaysia major route leak?

2015-06-12 Thread Stephane Bortzmeyer
On Fri, Jun 12, 2015 at 11:09:34AM +0200,
 Tore Anderson t...@fud.no wrote 
 a message of 10 lines which said:

 I see tons of bogus routes show up with AS4788 in the path, and at
 least AS3549 is acceping them.
 
 E.g. for the RIPE NCC (193.0.0.0/21):
 
 [BGP/170] 00:20:29, MED 1000, localpref 150
   AS path: 3549 4788 12859  I, validation-state: valid

Unlike most BGP leaks, they kept the proper origin, so validation by ROA was
useless :-(


Re: AS4788 Telecom Malaysia major route leak?

2015-06-12 Thread Stephane Bortzmeyer
On Fri, Jun 12, 2015 at 09:58:55AM -0500,
 Charles van Niman char...@phukish.com wrote 
 a message of 25 lines which said:

 Does anyone at Level3 care to comment here about this event,

https://twitter.com/Level3/status/609353696787496960


Re: macomnet weird dns record

2015-04-14 Thread Stephane Bortzmeyer
On Tue, Apr 14, 2015 at 02:26:48PM +0100,
 Colin Johnston col...@gt86car.org.uk wrote 
 a message of 19 lines which said:

 Best practice says avoid such info in records as does not aid debug
 since mix of dec and hex

No. Pure imagination on your side. There is no such best
practice. And it's not hex or dec, it is letters and digits.



Re: macomnet weird dns record

2015-04-14 Thread Stephane Bortzmeyer
On Tue, Apr 14, 2015 at 04:09:42PM +0300,
 Nikolay Shopik sho...@inblock.ru wrote 
 a message of 10 lines which said:

 How its weird? All these chars allowed in DNS records.

And they probably encode the netmask, which may be useful.


Re: Google public DNS - getting SERVFAIL for any domains delegated to GoDaddy NSs

2014-12-07 Thread Stephane Bortzmeyer
On Sun, Dec 07, 2014 at 12:01:40PM -0500,
 Erik Levinson erik.levin...@uberflip.com wrote 
 a message of 25 lines which said:

 I'm getting SERVFAIL when trying to resolve any record in any domain
 whose NSs are 
 pdns01.domaincontrol.com/pdns02.domaincontrol.com/pdns05.domaincontrol.com/pdns06.domaincontrol.com
 (GoDaddy premium DNS), only when using Google's 8.8.8.8 / 8.8.4.4
 resolvers, from multiple locations/networks.

Since Google Public DNS validates, and Go Daddy supports DNSSEC, it
would be useful to test with dig +cd (Checking Disabled) to determine
if it is a DNSSEC problem or not.

 You can look at targetly.co as one example (should be just an A
 record to 184.168.221.38 but getting SERVFAIL when querying
 8.8.8.8).

Works for me

% dig @8.8.8.8 a targetly.co 

;  DiG 9.8.4-rpz2+rl005.12-P1  @8.8.8.8 a targetly.co
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 4056
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;targetly.co.   IN A

;; ANSWER SECTION:
targetly.co.242 IN A 184.168.221.38

;; Query time: 67 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Dec  7 18:07:58 2014
;; MSG SIZE  rcvd: 56



Re: How to track DNS resolution sources

2014-12-03 Thread Stephane Bortzmeyer
On Wed, Dec 03, 2014 at 05:22:58PM +0100,
 Notify Me notify.s...@gmail.com wrote 
 a message of 13 lines which said:

 I hope I'm wording this correctly.

Not really :-)

 I had a incident at a client site where a DNS record was being
 spoofed.

How do you know? What steps did you use to assert this? Answers to
these questions would help to understand your problem.

 How does one track down the IP address that's returning the false
 records ?

If it's real DNS spoofing (which I doubt), the source IP address of
the poisoner is forged, so it would not help.

The main tool to use is dig. Let's assume the name that bothers you is
foobar.example.com. Query your local resolver:

dig A foobar.example.com

Query an external resolver, here Google Public DNS:

dig @8.8.4.4 A foobar.example.com

Query the authoritative name servers of example.com. First, to find them:

dig NS example.com

Second, query them (replace the server name by the real one):

dig @a.iana-servers.net. A foobar.example.com


Re: How to track DNS resolution sources

2014-12-03 Thread Stephane Bortzmeyer
On Wed, Dec 03, 2014 at 11:32:08AM -0500,
 TR Shaw ts...@oitc.com wrote 
 a message of 20 lines which said:

 On the command line:
 
 host spoofed.host.name.com

Excuse me but it is useless. It tests only the local resolver (which
may be unpoisoned). It provides no details that could help to debug
the problem (such as the TTL).




BGP hijacking to steal bitcoins

2014-08-08 Thread Stephane Bortzmeyer
Good report (although I do not understand why they hide the name of
the offending ISP since anyone can see it in RouteViews, or in its own
BGP traffic). It's ordinary BGP hijacking but the goal is new:
stealing bitcoins since the connections inside the mining pool are not
authenticated.

http://www.secureworks.com/cyber-threat-intelligence/threats/bgp-hijacking-for-cryptocurrency-profit/

Here is an example in RouteViews@LINX, for (among others) the OVH
prefix 142.4.195.0/24 (bitcoin pool Hashfaster). This route was
withdrawn at 18:35:08.

TIME: 03/23/14 18:32:38 
   
TYPE: BGP4MP/MESSAGE/Update 
   
FROM: 195.66.224.21 AS6939  
   
TO: 195.66.225.222 AS6447   
   
ORIGIN: IGP 
   
ASPATH: 6939 21548 34272 2093 2871 3721 
   
NEXT_HOP: 195.66.224.21 
   
ANNOUNCE
   
  192.99.20.0/24
   
  198.27.75.0/24
   
  192.241.211.0/24  
   
  192.99.18.0/24
   
  146.185.179.0/24  
   
  162.243.89.0/24   
   
  54.197.251.0/24   
   
  46.229.169.0/24   
   
  107.170.244.0/24  
   
  108.61.49.0/24
   
  54.214.242.0/24   
   
  107.170.227.0/24  
   
  54.194.173.0/24   
   
  50.117.92.0/24
   
  95.85.61.0/24 
   
  54.84.236.0/24
   
  54.213.177.0/24   
   
  162.243.142.0/24  
   
  162.243.226.0/24  
   
  142.4.195.0/24
   
  107.170.47.0/24 
  54.194.173.0/24   
   
  50.117.92.0/24
   
  95.85.61.0/24 
   
  54.84.236.0/24
   
  54.213.177.0/24   
   
  162.243.142.0/24  
   
  162.243.226.0/24  
   
  142.4.195.0/24
   
  107.170.47.0/24   
   




Re: BGP Session

2014-07-16 Thread Stephane Bortzmeyer
I love the From: field :-)



Re: RIPE Atlas data parsing

2014-05-27 Thread Stephane Bortzmeyer
On Tue, May 27, 2014 at 12:28:30PM -0700,
 Ca By cb.li...@gmail.com wrote 
 a message of 9 lines which said:

 Is there dummy tool for summarizing this JSON data and possibly
 visualizing it?

On Atlas Web site, there is the Seismograph (an interactive tool). I
don't use it myself.

There are many sample programs on:

https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib

See for instance reachability+retrieve.py

There is now a new library to help parsing, called Sagan:

https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-latest-results-api-and-parsing-library

(I used it only a little)

You may also look at the tutorial:

https://ripe67.ripe.net/presentations/153-ripe-atlas-udm-api-1.pdf



Re: All of .mil tld is down

2014-05-20 Thread Stephane Bortzmeyer
On Tue, May 20, 2014 at 02:35:49PM -0400,
 Brian Henson marin...@gmail.com wrote 
 a message of 107 lines which said:

 Looks like it has been corrected now

Not from everywhere. From two different networks in France, I get:

%  check-soa -i nipr.mil
CON1.nipr.mil.
199.252.157.234: ERROR: Timeout
CON2.nipr.mil.
199.252.162.234: ERROR: Timeout
EUR1.nipr.mil.
199.252.154.234: ERROR: Timeout
EUR2.nipr.mil.
199.252.143.234: OK: 2014051904 (256 ms)
PAC1.nipr.mil.
199.252.180.234: ERROR: Timeout
PAC2.nipr.mil.
199.252.155.234: ERROR: Timeout

%  check-soa -i mil 
CON1.NIPR.mil.
199.252.157.234: ERROR: Timeout
CON2.NIPR.mil.
199.252.162.234: ERROR: Timeout
EUR1.NIPR.mil.
199.252.154.234: ERROR: Timeout
EUR2.NIPR.mil.
199.252.143.234: OK: 2014051904 (265 ms)
PAC1.NIPR.mil.
199.252.180.234: ERROR: Timeout
PAC2.NIPR.mil.
199.252.155.234: ERROR: Timeout



Re: Anternet

2014-04-07 Thread Stephane Bortzmeyer
On Sat, Apr 05, 2014 at 12:44:05AM -0500,
 Larry Sheldon larryshel...@cox.net wrote 
 a message of 9 lines which said:

 http://kottke.org/14/04/the-anternet

But what is the equivalent of 3-way handshake? And of ECN (ants
carrying back messages I still bring food but it won't last)? And
the security implications (what prevent bad ants to disrupt the
mechanism: ants did not invent random ISNs)? Is there a source quench
mechanism or did the ants deprecate it long before RFC 6633? And what
is the size of the initial window?  Should we cancel all patents
related to TCP because there is prior ant art? Many questions
unanswered.



  1   2   3   >