Re: China internet issues

[Stephane Bortzmeyer]

On Wed, May 22, 2024 at 08:18:05PM +0530,
 Vinod Ola  wrote 
 a message of 139 lines which said:

> Can anyone please help me to get view of China ISP issues and backbone issues?

There is a chinese network operators group (found from
)
but it seems without any real activity:

https://groups.google.com/g/cnnog

Re: 2600:: No longer pings

[Stephane Bortzmeyer]

On Sun, Apr 07, 2024 at 01:12:21PM +0200,
 Tomáš Holý  wrote 
 a message of 227 lines which said:

> $ for i in `cat list.txt`; do fping -6 $i -t 500 -r 0; done | grep 'is alive'
> 2409:: is alive
> 2a09:: is alive
> 2a11:: is alive
> 2a12:: is alive

All of them are public DNS resolvers, which make sense: having a
simple IP address is a big marketing plus for a DNS resolver.

Re: 2600:: No longer pings

[Stephane Bortzmeyer]

On Sun, Apr 07, 2024 at 09:33:18AM +0530,
 Gaurav Kansal via NANOG  wrote 
 a message of 41 lines which said:

> 2409:: is replying the ICMPv6 request, in case anyone interested

Thank, I did not know this service.

Note that the signatures on the reverse expired in february:

% dig +cd -x 2409::

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> +cd -x 2409::
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61252
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.0.4.2.ip6.arpa. IN 
PTR

;; ANSWER SECTION:
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.0.4.2.ip6.arpa. 360 
IN PTR dns.nic.in.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.0.4.2.ip6.arpa. 360 
IN RRSIG PTR 10 34 360 (
20240229030654 20240130030654 43700 
0.0.0.9.0.4.2.ip6.arpa.
Rga+5mz8UC4nOqWHT4B13aaAC2Oenyp+R3YvklfmfQvC
giyr3I/qbCFZiPqKKdksFIH0LtaP8AOM1h03mvJFaAqD
sDceS3WRlObCkbpDphzW8ccqzGSGF/MXHiBk1LucBtZU
ZEv5YpYTb3j1HhbL4Jj135slTHJ2aMOjWOlAK8rpx1b2
KYWQdZEVK2gE5RbS1m4mhBP4FZsRRMsv7dWdZgcH4zAs
g+vYUvE9x2tjSCul8i/LrzsC3BOU8la02qFarIj35TGV
0XYVoryBSuiDmdtpQPkIXB5Ef0XZK51kRqZGveGdkxnV
S1zQ09bDv7fiuHVvRFUvUdsVOs/xveLM9Q== )

;; Query time: 312 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (UDP)
;; WHEN: Sun Apr 07 10:42:02 CEST 2024
;; MSG SIZE  rcvd: 435

Re: 2600:: No longer pings

[Stephane Bortzmeyer]

On Sat, Apr 06, 2024 at 06:19:57PM +0800,
 Soha Jin  wrote 
 a message of 50 lines which said:

> I don't know what happed to 2600::, but 2a09:: and 2a11:: can be
> used as alternatives. These are addresses of https://dns.sb/ running
> by xTom.

Very good DNS service, buy the way. But, although I undertsand the
point of having test IPv6 addresses which are easy to remember, this
is an opportunity to remind everybody that the pingability of these
addresses is not guaranteed.

Better to use machines which are intended for testing such as the RIPE
Atlas anchors .

Re: Meta outage

[Stephane Bortzmeyer]

On Tue, Mar 05, 2024 at 04:23:42PM +,
 Kain, Becki (.) via NANOG  wrote 
https://metastatus.com/ a message of 210 lines which said:

> Does meta keep a board somewhere to tell the world it’s down?

https://metastatus.com/

Re: Meta outage

[Stephane Bortzmeyer]

On Tue, Mar 05, 2024 at 11:06:11AM -0500,
 Jay Ashworth  wrote 
 a message of 124 lines which said:

> This doesn't sound like it's a network layer problem but I'm curious.

We can see the start page, authentification fails with an error
message. It does not look like a network issue.

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: 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: 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: 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: 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: 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: *.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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: .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: 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: 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 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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.

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: "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: 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: 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: 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 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 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 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

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

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

[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

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

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

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

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

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

[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

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

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

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

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

[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

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

[Stephane Bortzmeyer]

On Mon, Jan 08, 2018 at 11:41:04AM +0100,
 Stephane Bortzmeyer  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&id=JSA10842&actp=RSS

Re: Spectre/Meltdown impact on network devices

[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

[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

[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

[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

[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

[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

[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

[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

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

[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

[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

[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

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

[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

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

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

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

[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

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