Testing IPv6 support on th client's machine (Was: NANOG 40 agenda posted

[Stephane Bortzmeyer]

On Wed, May 30, 2007 at 10:55:04AM +1200,
 Nathan Ward <[EMAIL PROTECTED]> wrote 
 a message of 56 lines which said:

> Use Javascript, or flash, or some other fancy thing to do a GET for  
> two files on two different servers as the page loads:
> a) http://ip6test./file
> b) http://ip4test./file
> 
> And then compare the hit-rate for the two.

Very good idea. 

But you should also log the TCP RTT for the two connections because a
common failure is the fact that IPv4 goes straight to the server while
IPv6 goes through a tunnel in Thailand or Brazil.

Re: MEDIA: Ruptured Cable Disrupts Internet Service in 5 Latin American Nations

[Stephane Bortzmeyer]

On Fri, Jun 22, 2007 at 02:26:46AM -0400,
 Barry Shein <[EMAIL PROTECTED]> wrote 
 a message of 22 lines which said:

>  > http://biz.yahoo.com/ap/070621/colombia_internet_disrupted.html?.v=1
...
>  > In a statement, Columbus said repair ships set sail from Mexico and
>  > the company hoped the cable would be fixed on Friday.
>  > 
> 
> Would that be the Nina, the Pinta, and the Santa Maria?

A paragraph was ommitted from the text posted here, it is much clearer
now:

The 6,250 mile Arcos network, owned by Columbus Networks, suffered the
rupture late Wednesday near Nicaragua, the company said.

Re: large organization nameservers sending icmp packets to dns servers.

[Stephane Bortzmeyer]

On Wed, Aug 08, 2007 at 03:20:56PM -0700,
 william(at)elan.net <[EMAIL PROTECTED]> wrote 
 a message of 23 lines which said:

> How is that an "anti DoS" technique when you actually need to return
> an answer via UDP in order to force next request via TCP?

Because there is no amplification: the UDP response packet can be very
small.

Re: [Nanog] Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010]

[Stephane Bortzmeyer]

On Tue, Apr 22, 2008 at 02:02:21PM +0100,
 [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote 
 a message of 46 lines which said:

> This is where all the algorithmic tinkering of the P2P software
> cannot solve the problem. You need a way to insert non-technical
> information about the network into the decision-making process.

It's strange that noone in this thread mentioned P4P yet. Isn't there
someone involved in P4P at Nanog?

http://www.dcia.info/activities/p4pwg/

IMHO, the biggest issue with P4P is the one mentioned by Alexander
Harrowell. After that users have been s.d up so many times by some
ISPs, will they trust this service?


___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: [NANOG] Introducing latency for testing?

[Stephane Bortzmeyer]

On Fri, May 02, 2008 at 01:12:52PM -0700,
 Mike Lyon <[EMAIL PROTECTED]> wrote 
 a message of 15 lines which said:

> So I want to mimic some latency in a test network for DB replication.
> I am wondering what other's have used for this? Obviously, the best
> way to would be to actually have one box across the US or across the
> globe to actually test against but what if you don't have that? Are
> there any GPL software router solutions that would allow you to tweak
> the latency in between the two test boxes?

I use and like FreeBSD's dummynet:

http://info.iet.unipi.it/~luigi/ip_dummynet/

Highly recommended.

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: .se disappeared?

[Stephane Bortzmeyer]

On Mon, Oct 12, 2009 at 09:38:10PM +0100,
 Ben White  wrote 
 a message of 4 lines which said:

> Does anyone else also see trouble reaching .se domains at the moment?

It fails for me through an Unbound resolver but works with a BIND
one. Certainly a DNSSEC glitch but I did not find which one yet. Or if
the fault is on my side or not.

Re: .se disappeared?

[Stephane Bortzmeyer]

On Tue, Oct 13, 2009 at 12:23:46AM +0200,
 Hauke Lampe  wrote 
 a message of 53 lines which said:

> Even after a cache reload, the SOA record appears still bogus:

Yes, even after a cold reboot, the data did not validate. But, this
time, the problem was purely DNSSEC and was noticed only by people
brave enough to validate. Too much haste in repairing probably.

> Unbound returns SERVFAIL instead. 

Fixed, now.

Re: What DNS Is Not

[Stephane Bortzmeyer]

On Mon, Nov 09, 2009 at 06:15:09PM -0500,
 David Ulevitch  wrote 
 a message of 18 lines which said:

> When the conficker worms phones home to one of the 50,000 potential
> domains names it computes each day, there are a lot of IT folks out
> there that wish their local resolver would simply reject those DNS
> requests so that infected machines in their network fail to phone
> home.

That's an extremely bad idea: many of the domains generated by the
Conficker algorithm are already registered by a legitimate registrant
(in .FR: the national railways, a national TV, etc).

Also, the example is not a good choice since Conficker now mostly uses
P2P:  for those who like assembly
code and awful technical details.

Who has AS 1712?

[Stephane Bortzmeyer]

% whois -h whois.ripe.net AS1712

aut-num:AS1712
as-name:FR-RENATER-ENST
descr:  Ecole Nationale Superieure des Telecommunications,
descr:  Paris, France.
descr:  FR

% whois -h whois.arin.net AS1712 

OrgName:Twilight Communications 
City:   Wallis
StateProv:  TX
Country:US

And, yes, AS 1712 is actually used by both and announced :-(

Re: Who has AS 1712?

[Stephane Bortzmeyer]

On Mon, Nov 23, 2009 at 10:13:58AM -0500,
 Jeffrey Lyon  wrote 
 a message of 42 lines which said:

> Looks like FR-RENATER-ENST is in the wrong:

You mean RIPE-NCC is wrong? Because this AS is used by ENST for many
years and is registered in the RIPE database...

Re: Who has AS 1712?

[Stephane Bortzmeyer]

On Mon, Nov 23, 2009 at 05:29:59PM +0100,
 Benjamin BILLON  wrote 
 a message of 36 lines which said:

> The RENATER I'm peering with is AS2200.

The AS number was allocated (ten years ago, as noticed by Frédéric)
through the LIR Renater to the customer ENST (now Télécom Paris
Tech). It does not mean it is today announced by Renater.

Re: Who has AS 1712?

[Stephane Bortzmeyer]

On Mon, Nov 23, 2009 at 11:06:31AM -0500,
 Larry Blunk  wrote 
 a message of 29 lines which said:

> it appears that AS1708-AS1726 were missed and have subsequently been
> reallocated by ARIN (between Aug 18 and Aug 21, 2009)

Now, interesting question: what can we do to solve the problem? Who
should act?

I am quite surprised that it is possible to have the same AS number in
two different RIRs, to different organizations :-( IP resources
certificates will be difficult to deploy here.

Re: Who has AS 1712?

[Stephane Bortzmeyer]

On Mon, Nov 23, 2009 at 07:42:34PM -0500,
 Durand, Alain  wrote 
 a message of 14 lines which said:

> The whole value of the RIR is to guarantee this uniqueness. This
> problem should not have happened.

Indeed. It is a big blunder from the RIR system. I have reported it to
RIPE-NCC (ticket NCC#2009116087) but not to ARIN (I'm not used to
interact with them, if someone wants to relay the information...)

Re: Who has AS 1712?

[Stephane Bortzmeyer]

On Mon, Nov 23, 2009 at 08:25:33PM -0500,
 Jon Lewis  wrote 
 a message of 44 lines which said:

> Is it too much to ask that the RIRs query each other's whois servers
> for an ASN before assigning that ASN?...

Yes, very good idea. And to check the BGP public routing table also
(belts and suspenders...)

Re: Who has AS 1712?

[Stephane Bortzmeyer]

On Tue, Nov 24, 2009 at 07:54:08PM -0800,
 Joe Abley  wrote 
 a message of 13 lines which said:

> Are you suggesting that I should be able to block the assignment of
> particular ASNs by simply including them in an AS_PATH attribute on
> a route I originate, and making sure that route shows up in
> route-views?

No one suggested a complete, blind and automatic blocking of the
assignment. Just a suggestion to RIRs to check if the AS number they
are ready to assign is used in an AS path somewhere and, if so, to
raise a flag, to assign a physical person on the matter, to
investigate, to check the databases, etc.

This would have catched the AS 1712 issue.

News about the .HT domain

[Stephane Bortzmeyer]

I have no information about the state of the Internet links in Haiti
(everything seems down) but, for the .HT top-level domain, here are a
few news.

.HT has six name servers, four outside of the country. They were not
affected so .HT never had a problem resolving. Main DNS lesson: always
put name servers in very diverse places.

The master was in Port-au-Prince and is unreachable, probably for a
long time. A new (stealth) master has been set up in Australia by
Cocca and the slaves are now reconfigured to use it. Two already do it
and therefore the zone no longer risks expiration (and can even be
modified).

You may find information at .

% check_soa ht
There was no response from ns2.nic.ht
There was no response from ns1.nic.ht
dns.princeton.edu has serial number 2010011198
charles.cdec.polymtl.ca has serial number 2010011198
ht-ns.anycast.pch.net has serial number 2010011615
ns3.nic.fr has serial number 2010011615


signature.asc
Description: Digital signature

Re: 1/8 and 27/8 allocated to APNIC

[Stephane Bortzmeyer]

On Fri, Jan 22, 2010 at 08:54:37AM -0500,
 William Allen Simpson  wrote 
 a message of 20 lines which said:

> I agree that 1/8 was probably about the *last* that should have been
> allocated.  It's particularly frustrating that they made two
> assignments at the same time, but not to adjacent routing blocks

http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/

Re: 1/8 and 27/8 allocated to APNIC

[Stephane Bortzmeyer]

On Fri, Jan 22, 2010 at 10:16:12AM -0500,
 William Allen Simpson  wrote 
 a message of 17 lines which said:

>> http://blog.icann.org/2009/09/selecting-which-8-to-allocate-to-an-rir/
>>
> Because relying on a blog post for policy 

I'm fairly certain that it is because the ICANN staff can post on its
own blog at will while creating a "real" policy and publishing it on
the official Web site requires five years, the (paid) advice of ten
lawyers and the signature of five vice-presidents.

Re: How polluted is 1/8?

[Stephane Bortzmeyer]

On Wed, Feb 03, 2010 at 04:49:00PM +0100,
 Mirjam Kuehne  wrote 
 a message of 15 lines which said:

> After 1/8 was allocated to APNIC last week, the RIPE NCC did some  
> measurements to find out how "polluted" this block really is.
>
> See some surprising results on RIPE Labs:  
> http://labs.ripe.net/content/pollution-18

Not a suprise, unfortunately.

See also http://bgpmon.net/blog/?p=275

Re: History of 4.2.2.2. What's the story?

[Stephane Bortzmeyer]

On Sun, Feb 14, 2010 at 12:43:12PM -0600,
 John Palmer (NANOG Acct)  wrote 
 a message of 42 lines which said:

> A more useful resolver is ASLAN [199.5.157.128] which is an
> inclusive namespace resolver which shows users a complete map of the
> internet,

There are many crooks which sell dummy TLDs. At least, they make an
effort to have more than two name servers for the root. But
199.5.157.128 is better, it does not just add dummy TLDs, it adds every
possible TLD:


% dig @199.5.157.128 A www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O

; <<>> DiG 9.5.1-P3 <<>> @199.5.157.128 A www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53344
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O. IN A

;; ANSWER SECTION:
www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O. 7195 IN A 199.5.157.33

;; AUTHORITY SECTION:
.   87988   IN  NS  b.worldroot.net.
.   87988   IN  NS  a.worldroot.net.

;; Query time: 146 msec
;; SERVER: 199.5.157.128#53(199.5.157.128)
;; WHEN: Sun Feb 14 21:28:54 2010
;; MSG SIZE  rcvd: 125

Re: in-addr.arpa server problems for europe?

[Stephane Bortzmeyer]

On Mon, Feb 15, 2010 at 10:22:17AM +0100,
 Michelle Sullivan  wrote 
 a message of 185 lines which said:

> 213.in-addr.arpa.   86400   IN  NS  NS-PRI.RIPE.NET.
> 213.in-addr.arpa.   86400   IN  NS  NS3.NIC.FR.
> 213.in-addr.arpa.   86400   IN  NS  SUNIC.SUNET.SE.
> 213.in-addr.arpa.   86400   IN  NS  SNS-PB.ISC.ORG.
> 213.in-addr.arpa.   86400   IN  NS  SEC1.APNIC.NET.
> 213.in-addr.arpa.   86400   IN  NS  SEC3.APNIC.NET.
> 213.in-addr.arpa.   86400   IN  NS  TINNIE.ARIN.NET.
> ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms
> 
> ;; connection timed out; no servers could be reached

It is highly improbable that all these name servers are unreachable
from you. Therefore, I suspect that *content* is the issue. RIPE-NCC
zones are signed with DNSSEC. Are you sure you do not have a broken
middlebox which deletes DNSSEC-signed answers?

(I tried from an US/Datotel/Level3 machine and everything works.)

Re: in-addr.arpa server problems for europe?

[Stephane Bortzmeyer]

On Mon, Feb 15, 2010 at 01:40:31PM +0100,
 Michelle Sullivan  wrote 
 a message of 298 lines which said:

> miche...@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR

Bad test: the response is too small to exercice real size
problems. Try adding "+dnssec" to the dig command-line (that's what
BIND does by default).

Re: in-addr.arpa server problems for europe?

[Stephane Bortzmeyer]

On Mon, Feb 15, 2010 at 08:30:43PM +0800,
 Wilkinson, Alex  wrote 
 a message of 14 lines which said:

> Curious, why did you modify 'bufsize' ?

To test response size issues, probably. Broken middleboxes are the
scourge of the Internet.

http://labs.ripe.net/content/preparing-k-root-signed-root-zone

> If you have received this email in error, you are requested to
> contact the sender and delete the email.

Done. I also erased the hard disk and reinstalled the OS.

Re: in-addr.arpa server problems for europe?

[Stephane Bortzmeyer]

On Mon, Feb 15, 2010 at 01:12:55PM +0100,
 Mark Scholten  wrote 
 a message of 36 lines which said:

> Solution: stop using DNSSEC or checking for DNSSEC. 

In 2010, it is a bit backward...

Re: P2P agents for software distribution - saving the WAN from meltdown?!?

[Stephane Bortzmeyer]

On Wed, Jun 18, 2008 at 10:52:38AM -0400,
 Joe Abley <[EMAIL PROTECTED]> wrote 
 a message of 41 lines which said:

> The behaviour I have observed with BitTorrent is that clients are
> handed a relatively short list of potential peers by the tracker,
> and it's quite common for sensible, close, local peers not to be
> included. My assumption has been that the set of potential peers
> passed to the client is assembled randomly.

I did not check seriously so I cannot confirm or deny but do note that
there are several proposals to improve "peer selection" behind random
sorting or crude measurements with ping on a few hosts. A summary of
existing work is on the ALTO Web site
.

ALTO will have a BoF session at the next IETF in Dublin, so we may see
one day a standard protocol for peer selection.

Re: ICANN opens up Pandora's Box of new TLDs

[Stephane Bortzmeyer]

On Thu, Jun 26, 2008 at 11:53:06PM +0200,
 Jeroen Massar <[EMAIL PROTECTED]> wrote 
 a message of 49 lines which said:

> not even thinking of all the nice security issues which come along
> (home, mycomputer and .exe etc anyone ?

This requires serious elaboration. How could you use a domain in
".exe" to actually attack someone? (No handwaving, please, actual
study.)

> Thank you people doing all the ICANN politics for destroying the Internet.

The Internet, until now, resisted to forces much more powerful than
ICANN.

Re: ICANN opens up Pandora's Box of new TLDs

[Stephane Bortzmeyer]

On Thu, Jun 26, 2008 at 10:37:34PM -0500,
 Frank Bulk - iNAME <[EMAIL PROTECTED]> wrote 
 a message of 37 lines which said:

> ...which is why it might be a strategy to blacklist all new TLDs (if
> this proposal gets through) and whitelist just .com, .net, etc.

Interesting. I do not know if this strategy will be implemented or not
but, if it is, it will be a big change in Internet governance. No
longer will the TLDs in the root be decided by ICANN or by its master,
the US government, but they will have to be "vetted" by an informal
group of network operators. A boycott by this group could have
devastating effects for a business.

We already see this in the email world, where a self-appointed cartel
like the MAAWG can decide technical rules and policies, bypassing both
IETF and ICANN. Even if only one half of the big operators enforce
these rules, they will become de facto regulations, since noone can
afford to have his email refused by this half. (To take a recent
example, I configure rDNS on every email server I managed, even if I
find the rule stupid and unfair, because I have no choice.)

It will be an interesting turn back to the european cities of the
Middle Age, with guilds approving (or, more often, disapproving) every
technical or business novelty...

Re: ICANN opens up Pandora's Box of new TLDs

[Stephane Bortzmeyer]

On Fri, Jun 27, 2008 at 01:32:05PM -0700,
 Roger Marquis <[EMAIL PROTECTED]> wrote 
 a message of 22 lines which said:

> Security-aware programmers will now be unable to apply even cursory
> tests for domain name validity.

I am very curious of what tests a "security-aware programmer" can do,
based on the domain name, which will not be possible tomorrow, should
ICANN allow a few more TLDs.

If you test that the TLD exists... it will still work.

If you test that the name matches (com|net|org|[a-z]{2}), then you are
not what I would call a "security-aware programmer". 

> requiring valid domain contacts.

ICANN does require valid contacts. And it requires them to be
published and sold. So, people lie to protect their privacy. In the
world of security, stupid ideas often backfire.

> I have to conclude that ICANN has failed, simply failed, and should be
> returned to the US government.

It never leaved it.

Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)

[Stephane Bortzmeyer]

On Fri, Jun 27, 2008 at 10:24:48AM -0700,
 Scott Francis <[EMAIL PROTECTED]> wrote 
 a message of 32 lines which said:

> what problem is ICANN trying to solve with this
> proposal? What about the current system that's broken, does this new
> system fix? 

ICANN is simply responding to demand. Some people want to create a
TLD. The existence of a TLD is not a problem for the other TLDs. If
the new TLD is stupid or useless (like ".aero" or ".pro"), it will
fail. So what? That's the normal life of projects.

Why ICANN should evaluate the new TLD applications, apart from some
simple technical checks? If something is wanted and causes no harm for
the others, then why in hell ICANN should refuse it?

I did not suspect that the idea of central regulation of business,
with a state-like committee examining business ideas and allowing them
or not, was an idea so popular among Nanog members :-)

Re: the business model, was what problem are we solving? (was Re: ICANN opens

[Stephane Bortzmeyer]

On Sat, Jun 28, 2008 at 06:19:19PM -0400,
 Jean-François Mezei <[EMAIL PROTECTED]> wrote 
 a message of 47 lines which said:

> I think that IANA should have long ago become quite strict with
> domain name registrations. .COM should have been only to companies
> operating worldwide.

Wow, ".fr", like many ccTLDs, spent a lot of time and money in this
Soviet-style regulation a long time ago. We checked business records,
asked customers for more paper, refused applications...

As an obvious result, many people choosed ".com" over ".fr".

In several steps (2000, 2004 and 2006), ".fr" relaxed its rules so,
now, there is no human checking. Most other ccTLDs did the same at
this time or before.

Should ".com" had rules like the one you suggest (how do you check a
business record from a company in Thailand? Or in Tadjikistan?) ".fr"
would have had been in better position against it :-)

Re: Mail Server best practices - was: Pandora's Box of new TLDs

[Stephane Bortzmeyer]

[Wow, operational content!]

On Sat, Jun 28, 2008 at 05:25:16PM -0500,
 Chris Owen <[EMAIL PROTECTED]> wrote 
 a message of 53 lines which said:

> At some point what is the difference between putting the mail into a
> spam folder and sending them to /dev/null?

To me, there is a huge difference. I send no mail to Dave Null,
everything goes into a spam folder. Do I read it? Do I review it from
time to time? Never. It is too huge. So, what's the point besides
bringing money to hard disk manufacturers?

It is because, if someone reports (by telephone, IRC or IRL) that he
sent an email and I did not receive it, I regard as VERY IMPORTANT to
be able to check the spam folder (with a search tool, not by hand) and
go back to him saying "No, we really did not receive it".

In a professional environment, I would not accept the idea of email
disappearing without being able to recover it.

Re: ICANN opens up Pandora's Box of new TLDs

[Stephane Bortzmeyer]

On Sun, Jun 29, 2008 at 02:45:55PM -0700,
 Roger Marquis <[EMAIL PROTECTED]> wrote 
 a message of 31 lines which said:

> The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}' 

If this is a regexp for the current root zone, it is
wrong... (".museum" and the test IDNs, whose punycode encoding
contains digits and hyphens.)

> Aside from the IP issues it effectively precludes anyone from
> defining a hostname that cannot also be someone else's domain
> name. 

Interesting requirment but one which was never written down, I'm
afraid. You certainly cannot expect ICANN to comply with every
requirment that someone at Nanog may imagine every day.

> Will you still think that when someone buys the right to the .nic
> tld and starts harvesting your queries and query related traffic?

Be my guest. The DNS is a tree and the existence of nic.de or nic.com
was never a problem. Why should ".nic" be different?

Re: Mail Server best practices - was: Pandora's Box of new TLDs

['Stephane Bortzmeyer']

On Sun, Jun 29, 2008 at 03:30:15PM -0500,
 Frank Bulk - iNAME <[EMAIL PROTECTED]> wrote 
 a message of 35 lines which said:

> Because if you do anything, even as basic as RBLs, you're not being
> consistent with your stance.

The typical use of RBLs is to reject email at the SMTP level, when it
matches an entry in the RBL. That way, the sender is warned that
something went wrong, email does not disappear silently.

Re: ICANN opens up Pandora's Box of new TLDs

[Stephane Bortzmeyer]

On Mon, Jun 30, 2008 at 06:36:06PM +0100,
 Tony Finch <[EMAIL PROTECTED]> wrote 
 a message of 15 lines which said:

> It makes the "public suffix list" project harder, but so long as the
> list of TLDs changes reasonably slowly, it shouldn't become
> impossible.  http://publicsuffix.org/

Well, this list is a bad workaround for cookies specification problems
and bad programming practices, so I'm not too concerned if it is
perturbed.

Re: updating & checking DNS zone files

[Stephane Bortzmeyer]

On Sat, Jul 05, 2008 at 05:45:26PM -0700,
 Paul Bertain <[EMAIL PROTECTED]> wrote 
 a message of 41 lines which said:

> For incrementing your zone's serial number, I usually include zsu 

Do you work for the Russian army
, which seems to win the Google
race for "ZSU" or is it ?

Re: Federal Government Interest in your patch progress

[Stephane Bortzmeyer]

On Fri, Jul 25, 2008 at 12:36:57PM -0400,
 Steven M. Bellovin <[EMAIL PROTECTED]> wrote 
 a message of 29 lines which said:

> I've been talking to US Gov't folks, too.  They really want DNSSEC (and
> secure BGP...) deployed.

Then, why ".gov" is not signed?

Talk is cheap.

Re: interger to I P address

[Stephane Bortzmeyer]

On Wed, Aug 27, 2008 at 02:27:24PM +0200,
 Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote 
 a message of 14 lines which said:

>> Easiest way.
>
> $ ping 1089055123
> PING 1089055123 (64.233.169.147): 56 data bytes

It relies on an undocumented feature (it is not in RFC 791, nor in
getaddrinfo() manual) :-)

Re: Netblock reassigned from Chile to US ISP...

[Stephane Bortzmeyer]

On Fri, Dec 12, 2008 at 01:13:59PM -0600,
 Frank Bulk  wrote 
 a message of 52 lines which said:

> Is there an easy way to get past history on an IP block?  Most sites
> will show you aspects of that *now*

http://www.renesys.com/blog/2008/11/for-sale-clean-lightly-used-ip.shtml

(That's just an idea, not a real service.)

Re: Gmail down?

[Stephane Bortzmeyer]

Indeed, down for me too, from France:

% telnet mail.google.com http
Trying 72.14.221.19...
Connected to googlemail.l.google.com.
Escape character is '^]'.
GET / HTTP/1.0
Host: mail.google.com


[Nothing]

Re: Why is www.google.cat resolving?

[Stephane Bortzmeyer]

On Tue, May 05, 2009 at 12:22:58AM -0700,
 Tim Tuppence  wrote 
 a message of 14 lines which said:

> I am seeing that www.google.cat resolves from three different networks.

New trend on NANOG? Complaining when things work and not when they
fail? 

Re: Why is www.google.cat resolving?

[Stephane Bortzmeyer]

On Tue, May 05, 2009 at 09:41:41AM +0200,
 Chris Meidinger  wrote 
 a message of 17 lines which said:

> I think the real question here is why does schroedingers.cat not
> resolve,

That's because ".cat" has IDN and therefore it should be
schrödingers.cat

Re: Anomalies with AS13214 ?

[Stephane Bortzmeyer]

On Tue, Jul 28, 2009 at 11:50:02AM +0100,
 Russell Heilling  wrote 
 a message of 75 lines which said:

> No. monitors: 1

That's why it's good to use BGP alarm systems with a peer threshold. I
recommend BGPmon  (today, I run it with a peer
thershold of 1 because the problem is rare enough but I can raise it
if necessary).

AFAIK, Cyclops does not have this functionality.

Re: Anomalies with AS13214 ?

[Stephane Bortzmeyer]

On Tue, Jul 28, 2009 at 11:50:02AM +0100,
 Russell Heilling  wrote 
 a message of 75 lines which said:

> I guess ROBTEX didn't implement ingress filters after the last
> episode...

It *seems* (I do not know them in detail) that Robtex
, AS 48285, is dedicated to measurements, not
to IP transit. If so, it makes sense for them to accept everything.

If I'm right, it means Cyclops was wrong to have a monitor in an AS
which is not a "real" operator.

Re: Anomalies with AS13214 ?

[Stephane Bortzmeyer]

On Tue, Jul 28, 2009 at 11:50:02AM +0100,
 Russell Heilling  wrote 
 a message of 75 lines which said:

> I guess ROBTEX didn't implement ingress filters after the last
> episode...

I simply asked them and they told me that DCP (AS 13214) is simply
their transit provider so they cannot put a max-prefixes or list the
prefixes announced in an ACL.

Re: Anomalies with AS13214 ?

[Stephane Bortzmeyer]

On Tue, Jul 28, 2009 at 09:45:28AM -0400,
 Sharlon R. Carty  wrote 
 a message of 57 lines which said:

> Isn't this the second time that AS13214 seemed to have made a
> "unintentional misconfig"?

Yes 

Re: DoD IP Space

[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: RADb

[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: amazon.com multiple SPF records

[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: 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?

[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: An update on the AfriNIC situation

[Stephane Bortzmeyer]

On Fri, Aug 27, 2021 at 10:38:01PM +0200,
 Mark Tinka  wrote 
 a message of 13 lines which said:

> Oddly, I recommended to a friend (one who promotes competitors do the wrong
> thing, hehe) that sending CI routes to /dev/null would be ideal.

Trollish idea of the day: since it is an IPv4-specific problem, stop
routing IPv4 completely. Since IPv6 addresses are not scarce and have
no monetary value, the problems of hoarders/thieves would disappear
(and it would make life simpler for network professionals).

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[Stephane Bortzmeyer]

On Mon, Oct 10, 2022 at 05:58:45PM +0300,
 Edvinas Kairys  wrote 
 a message of 35 lines which said:

> But theoretically every filtered /24 could be routed via smaller
> prefix /23 /22 /21 or etc.

I don't think this is true, even in theory, specially for legacy
prefixes. There is probably somewhere a Geoff Huston survey on /24
without a covering route.

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[Stephane Bortzmeyer]

On Mon, Oct 10, 2022 at 05:20:33PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 10 lines which said:

> > But theoretically every filtered /24 could be routed via smaller
> > prefix /23 /22 /21 or etc.
> 
> I don't think this is true, even in theory, specially for legacy
> prefixes.

I even find an example on my employer's network :-)

192.93.0.0/24

Re: DNS resolution for hhs.gov

[Stephane Bortzmeyer]

On Tue, Apr 11, 2023 at 12:16:36PM -0400,
 Robert Story  wrote 
 a message of 22 lines which said:

> DNSVis.net is a good place to check nameserver issues..

DNSViZ.net. Yes, great service.

Re: *.au RRSIG Expired

[Stephane Bortzmeyer]

On Sun, Sep 17, 2023 at 05:52:35PM -0700,
 Matt Corallo  wrote 
 a message of 16 lines which said:

> I believe same for name.au where `name` has a DS record. Same for net.au./DS, 
> etc.

Seems fixed now. Here is the last error seen by DNSviz:
https://dnsviz.net/d/com.au/ZQedzg/dnssec/ After that, it is OK again.

Re: Discord contacts

[Stephane Bortzmeyer]

On Fri, Sep 29, 2023 at 12:33:57PM +,
 Drew Weaver  wrote 
 a message of 172 lines which said:

> Any contacts from Discord here? Just started seeing cloudflare blocking 
> 250,000 IP addresses.

There is an unsubstiantated rumor (based on the fact that, from the
same IP address, it works with one browser but not the other) that
Cloudflare detects somehow programs that run a vulnerable version of
libwebp and block them (may be there are dangerous images sent on
Discord). As I said, no evidence, just a rumor, but a funny one.

Re: swedish dns zone enumerator

[Stephane Bortzmeyer]

On Thu, Nov 02, 2023 at 04:09:24PM +1100,
 Mark Andrews  wrote 
 a message of 90 lines which said:

> I also see QNAME minimisation in action as the QTYPE is NS.  This
> could just be a open recursive servers using QNAME minimisation.
> With QNAME minimisation working correctly all parent zones should
> see is NS queries with the occasional DNSKEY and DS query.  Both
> BIND and Knot use NS queries for QNAME minimisation.

I disagree. NS queries were used in the first RFC about QNAME
minimisation (which was experimental) but the current one (which is on
the standards track) now recommends A or  queries
, specially section 2.1.

> Other query types and/or prefixes do not work as they have
> undesirable side effects.

Rather the contrary, some broken firewalls in front of authoritative
name servers were crashing when using NS queries. Hence the choice of
address queries. (Also, it improves privacy since it makes more
difficult to see you are doing QNAME minimisation.)

> I would not like anyone to take seeing mostly NS queries as any
> evidence of bad practice.

We agree here.

Re: Interesting Ali Express web server behavior...

[Stephane Bortzmeyer]

On Sat, Dec 09, 2023 at 09:55:31PM -0800,
 Owen DeLong via NANOG  wrote 
 a message of 1136 lines which said:

> But why would AliExpress be redirecting to DDN space? Is this
> legitimate? Ali hoping to get away with squatting, or something
> else?

No idea. The IP address does not reply to HTTP requests, anyway. A
practical joke?

Note that this redirection takes places only when there is no
User-Agent field. If you say 'User-Agent: Mozilla', you get a proper
redirection, in my case to https://fr.aliexpress.com/.

Re: Shared cache servers on an island's IXP

[Stephane Bortzmeyer]

On Thu, Jan 18, 2024 at 12:53:19PM +0100,
 Jérôme Nicolle  wrote 
 a message of 36 lines which said:

> - Low redundancy of old cables (2)
> - Total service loss when both cables are down because of congestion on
> satelite backups

A problem which is not often mentioned is that most (all?) "local
caches" (CDN, DNS resolvers, etc) do not have an "offline mode" (or
"disconnected-from-master mode"). During an outage, they continue to
work for some time then break suddenly, in a not-friendly way, serving
various error messages instead of old data and/or useful
messages. (For instance, the DNS resolver may not be able to serve
stale answers.)

The time during which they can continue to work when they are
disconnected from their master is typically undocumented (except for
the DNS), and discovered only when there is a long outage.

Making the Internet work better with sometimes-broken connectivity is
still an area of research.

Re: Mail to Microsoft being falsely marked as spam/bulk

[Stephane Bortzmeyer]

On Sat, Jan 20, 2024 at 10:07:39PM +1100,
 Christopher Hawker  wrote 
 a message of 132 lines which said:

> If there is anyone from Microsoft around that can look into mail issues,
> could you please reach out to me off-list? Or if anyone has any
> ideas/suggestions as to how to resolve this, I'd be thankful to hear from
> you.

In my experience with self-hosting, reporting it to Microsoft with
 works sometimes. (Patience and calm
required.)

Re: Mail to Microsoft being falsely marked as spam/bulk

[Stephane Bortzmeyer]

On Sun, Jan 21, 2024 at 12:18:21PM +0100,
 Bjoern Franke via NANOG  wrote 
 a message of 25 lines which said:

> I had the same issue in which they were unable (or unwillig) to resolve it,
> and wouldn't have "the liberty to discuss the source of the block". Creating
> a new ticket some weeks later and they solved it without discussion.

Yes. Or just sending new stuff in the old ticket. (Apparently, you get
a different guy each time, keep trying until you find one who is
willing to act.)

Re: DNS hijack?

[Stephane Bortzmeyer]

On Thu, Nov 11, 2021 at 01:28:07PM -0800,
 Jeff Shultz  wrote 
 a message of 105 lines which said:

> I hit my registrar, DirectNic, and found I'm good through 2023. They
> pulled up DNS checker and found that a bunch of DNS servers were
> showing 208.91.197.132 as the IP for the domain. It's actually in
> 64.130.197.x .
> 
> I'm wondering if I was the only one?

No, you're not. Half of the RIPE Atlas probes see the wrong address:

% blaeu-resolve -r 100 --type A 2dpnr.org
[64.130.197.11] : 59 occurrences
[208.91.197.132] : 41 occurrences
Test #33310635 done at 2021-11-11T21:38:30Z

Re: DNS hijack?

[Stephane Bortzmeyer]

On Thu, Nov 11, 2021 at 01:36:58PM -0800,
 Jeff Shultz  wrote 
 a message of 122 lines which said:

> Never mind, looks like an expired domain issue. Someone didn't remind
> someone else.

To avoid such a problem:

* some registries allow for multi-year registration,
* some registrars allow for multi-year registration, and/or automatic
  renewal, so you no longer have to think of it,
* automatic entries in your agenda software is nice, too :-)
* automatic monitoring of expiration (through whois or, better, RDAP,
  later is an example of a Nagios/Icinga/whatever plugin using RDAP).

% /usr/local/lib/nagios/plugins/check_expire -H 2dpnr.org
2dpnr.org OK: expires in 497 days, 13:36:22.602780.

Re: DNS hijack?

[Stephane Bortzmeyer]

On Thu, Nov 11, 2021 at 09:44:04PM +,
 Richard  wrote 
 a message of 37 lines which said:

> The second of these is returning the 208.nnn IPnumber for your
> a-record:
> 
>dig @VOYAGER.VISER.NET 2dpnr.org
> 
>2dpnr.org. 300 IN A 208.91.197.132

It depends on where you are (from my resolver, I get
64.130.197.11). This is because the name voyager.viser.net is not
stable yet. Depending on your resolver, it points to 64.130.200.16 -
which seems to give correct answers - or to 208.91.197.132 - which
replies even for nonexisting domain names.

Lesson: don't use a name as an argument to dig's @

Re: DNS hijack?

[Stephane Bortzmeyer]

On Fri, Nov 12, 2021 at 03:13:57PM -0800,
 William Herrin  wrote 
 a message of 24 lines which said:

> To my mind, though, Netsol's server should not be responding with
> authoritative answers to random domains that aren't assigned to it.
> That it does makes me think it's a good candidate for black-holing in
> the routing system.

To my mind, I simply don't understand why some people continue to use
Network Solutions, with the track record they have.

Re: .bv ccTLD

[Stephane Bortzmeyer]

On Sat, Dec 04, 2021 at 10:20:16AM -0500,
 Jay Ashworth  wrote 
 a message of 121 lines which said:

> Oh dear. They actually gave them .SS?

It's an european reference. For the local people, this 2-letters code
probably means nothing special, it is not their history.

(I assume that the there is a discussion with the local government
before assigning them a code.)

Re: Anyone else seeing DNSSEC failures from EU Commission ? (european-union.europa.eu)

[Stephane Bortzmeyer]

On Wed, Dec 08, 2021 at 01:27:23PM +,
 Laura Smith via NANOG  wrote 
 a message of 18 lines which said:

> Bit of a long stretch given the US audience, but I'm seeing lots of things 
> like this at the moment:

Indeed, they botched DNSSEC


Seen by RIPE Atlas probes:

% blaeu-resolve  --requested 100 --type A european-union.europa.eu
[ERROR: SERVFAIL] : 48 occurrences
...
Test #34367829 done at 2021-12-08T13:37:31Z

Re: Authoritative Resources for Public DNS Pinging

[Stephane Bortzmeyer]

On Tue, Feb 08, 2022 at 11:56:44AM -0600,
 Mike Hammett  wrote 
 a message of 140 lines which said:

> Are there any authoritative resources from said organizations saying
> you shouldn't use their servers for your persistent ping
> destinations?

Why not using RIPE Anchors, which are made to be pinged (reasonably)?

Re: Authoritative Resources for Public DNS Pinging

[Stephane Bortzmeyer]

On Wed, Feb 09, 2022 at 09:08:04AM +0200,
 Mark Tinka  wrote 
 a message of 25 lines which said:

> It's terrible behaviour, but unless we offer a more "official"
> alternative, it won't end.

Let me repeat that there is a service which is officially intended to
be pinged/queried/etc, the RIPE Anchors. 

Re: Authoritative Resources for Public DNS Pinging

[Stephane Bortzmeyer]

On Wed, Feb 09, 2022 at 09:37:02AM +0200,
 Mark Tinka  wrote 
 a message of 18 lines which said:

> > Let me repeat that there is a service which is officially intended to
> > be pinged/queried/etc, the RIPE Anchors.
> 
> Yeah, but how do we get out there in a manner that Jane can easily find and
> use, like she does 8.8.8.8?

I don't think that John (who is probably no more clueful than Jane)
knows about Google Public DNS either.

The only problem is the less friendly IP address (although this will
be less and less a problem with IPv6, since 2001:4860:4860:: is
not really friendly). This can be partially mitigated with nice domain
names, that an access or service provider can set up.

Re: Russia to disconnect from global Internet

[Stephane Bortzmeyer]

On Sun, Mar 06, 2022 at 11:49:54PM +0100,
 Bill Woodcock  wrote 
 a message of 62 lines which said:

> This applies exclusively to Russian federal government networks, not
> ISPs or telecom operators.  It’s just trying to get them to document
> and harmonize their practices isn perfectly reasonable ways,

And I assume that not *one* domain under .gov has name servers in
foreign TLDs and not *one* Web site using .gov loads resources (fonts,
stylesheets, code, etc) from a non-US service.

And yet noone says that the USA are disconnecting from the Internet.

Re: cf is down?

[Stephane Bortzmeyer]

https://www.cloudflarestatus.com/


Identified - The issue has been identified and a fix is being implemented.
Jun 21, 06:57 UTC
Investigating - Cloudflare is investigating wide-spread issues with our 
services and/or network.



Users may experience errors or timeouts reaching Cloudflare’s network or 
services.



We will update this status page to clarify the scope of impact as we continue 
the investigation.



The next update should be expected within 15 minutes.
Jun 21, 06:43 UTC

Re: cf is down?

[Stephane Bortzmeyer]

On Tue, Jun 21, 2022 at 12:20:42AM -0700,
 Eric Kuhnke  wrote 
 a message of 204 lines which said:

> Massive spike in consumer facing services reported as broken by
> downdetector, almost all are likely cf customers. See downdetector
> homepage.

It seems back into service, now.

https://www.cloudflarestatus.com/

 Monitoring - A fix has been implemented and we are monitoring the results.
Jun 21, 07:20 UTC

Re: ns1-proddns.glbdns.o365filtering.com unreachable?

[Stephane Bortzmeyer]

On Wed, Jul 06, 2022 at 11:37:40AM +0200,
 Bjoern Franke via NANOG  wrote 
 a message of 10 lines which said:

> .mail.protection.outlook.com seems to throw servfails.

The authoritative name servers for this domain do not handle EDNS
(which was specified only 23 years ago) so the resolvers that do not
fallback on EDNS (probably the majority) return a SERVFAIL.

Seen with RIPE Atlas probes:

% blaeu-resolve -r 500 --type NS mail.protection.outlook.com
[ns1-proddns.glbdns.o365filtering.com. ns2-proddns.glbdns.o365filtering.com.] : 
319 occurrences 
[ERROR: SERVFAIL] : 138 occurrences 
[] : 1 occurrences 
Test #4155 done at 2022-07-06T09:24:50Z

Re: ns1-proddns.glbdns.o365filtering.com unreachable?

[Stephane Bortzmeyer]

On Wed, Jul 06, 2022 at 12:15:31PM +0200,
 Peter van Dijk  wrote 
 a message of 28 lines which said:

> So, in short, they have a DNS responding problem; their bad handling
> of EDNS makes that worse, because now a resolver needs to get two
> queries (one with EDNS, then one without) through to them before
> resolving something

Thanks, you're right and I was wrong.

It seems it now works again.

Note these authoritative name servers have other problems. For
instance, when receiving NS queries, they put the answer in the Answer
section but not for SOA requests.

Re: IERS ponders reverse leapsecond...

[Stephane Bortzmeyer]

On Wed, Aug 03, 2022 at 11:09:25AM -0400,
 Jay Ashworth  wrote 
 a message of 32 lines which said:

> General press loses its *mind*:

Indeed, they seem not to know what they write about. "atomic time –
the universal way time is measured on Earth – may have to change" They
don't even know the difference between TAI and UTC.

Re: Rogue objects in routing databases

[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: ISC BIND 9 breakage?

[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: Comcast DNS Assistance?

[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: BGP route hijack by AS10990

[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&w.endtime=2020-07-30T05%3A00%3A00&w.resource=AS10990

Re: Level3 DNS Issues

[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: CenturyLink

[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: ARIN NS down?

[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: Dnssec still inoperable on the internet ?— was ARIN NS down?

[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: 2019-01-11 ARIN.NET DNSSEC Outage – Post-Mortem (was: Re: ARIN NS down?)

[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: A Zero Spam Mail System [Feedback Request]

[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: A Zero Spam Mail System [Feedback Request]

[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?

A Deep Dive on the Recent Widespread DNS Hijacking Attacks

[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: who attacks the weather channel?

[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

Re: 44/8

[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: This DNS over HTTP thing

[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: This DNS over HTTP thing

[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

[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: AWS issues with 172.0.0.0/12

[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&T 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&T 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&T 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

[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

[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

[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: This DNS over HTTP thing

[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: "Using Cloud Resources to Dramatically Improve Internet Routing"

[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: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft?

[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: DoD IP Space

[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.