Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Alarig Le Lay 
On jeu. 10 oct. 22:31:48 2019, Adam Vallee wrote:
> Cogent and Hurricane Electric are not and never have been Tier 1 providers
> they both have Transit provided through other carriers.

Cogent is a Tier 1 provider, they don’t have any transit. Although they
don’t have an IPv6 full-view.

-- 
Alarig
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Adam Vallee 
This is the point I've been trying to make for over 24 hours but it would
seem that my comments are not being approved and sent to the list.

It is apparent by looking at any predominantly IPv6 Network that they have
to have more than one IP Transit provider that provides them with IPv6. I
believe it's as simple as allowing the two companies to generate Revenue
because you must connect either directly to both of them or to two partner
networks that they do buy Transit from.

Cogent and Hurricane Electric are not and never have been Tier 1 providers
they both have Transit provided through other carriers.

This is apparent simply by looking at the number of bgp peers that they
have and doing Traceroutes through their respective lookinglasses you can
tell that they must be purchasing Transit through other providers and last
time I checked networks that peer with each other do not provide free
transatlantic IP Transit nor do they provide Trans Pacific Transit without
charging for it.

Adam


On Thu., Oct. 10, 2019, 8:59 p.m. Viktor Dukhovni, 
wrote:

> On Thu, Oct 10, 2019 at 06:25:41PM -0400, Matthew Pounsett wrote:
>
> > The speculation I've seen is that Cogent refuses to treat HE as a Tier1
> > network in v6 because they don't try to also be one in v4, but that they
> > should because HE's v6 network is much wider reaching and much longer
> > established than Cogent's.  In any case, Cogent's refusal to peer with HE
> > over v6 has been very public and well documented.  It makes Cogent
> > unreachable from a significant portion of the v6 network.
>
> It has perhaps not been as well known as it deserves to be.  Perhaps
> additional publicity here (and any other relevant fora), might nudge
> the parties closer to a resolution.  The non-reachability of the
> IPv6 C root from a significant portion of IPv6 space is not a healthy
> situation.
>
> The error is immediately apparent via DNSViz:
>
> https://dnsviz.net/d/root/dnssec/
>
> --
> Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Viktor Dukhovni 
On Thu, Oct 10, 2019 at 06:25:41PM -0400, Matthew Pounsett wrote:

> The speculation I've seen is that Cogent refuses to treat HE as a Tier1
> network in v6 because they don't try to also be one in v4, but that they
> should because HE's v6 network is much wider reaching and much longer
> established than Cogent's.  In any case, Cogent's refusal to peer with HE
> over v6 has been very public and well documented.  It makes Cogent
> unreachable from a significant portion of the v6 network.

It has perhaps not been as well known as it deserves to be.  Perhaps
additional publicity here (and any other relevant fora), might nudge
the parties closer to a resolution.  The non-reachability of the
IPv6 C root from a significant portion of IPv6 space is not a healthy
situation.

The error is immediately apparent via DNSViz:

https://dnsviz.net/d/root/dnssec/

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Matthew Pounsett 
On Thu, 10 Oct 2019 at 17:26, Jared Mauch  wrote:

> On Thu, Oct 10, 2019 at 01:56:11PM -0700, Randy Bush wrote:
> > >> Neither Cogent or HE buy transit from anybody else
> >
> > i believe this statement to be false
>
> i know of at least 2 transit providers..
>

Both providing v4 transit, not v6, yes?

The speculation I've seen is that Cogent refuses to treat HE as a Tier1
network in v6 because they don't try to also be one in v4, but that they
should because HE's v6 network is much wider reaching and much longer
established than Cogent's.  In any case, Cogent's refusal to peer with HE
over v6 has been very public and well documented.  It makes Cogent
unreachable from a significant portion of the v6 network.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Jared Mauch 
On Thu, Oct 10, 2019 at 01:56:11PM -0700, Randy Bush wrote:
> >> Neither Cogent or HE buy transit from anybody else
> 
> i believe this statement to be false

i know of at least 2 transit providers.. 

- jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Paul Vixie 

as a purely technical matter.

On Thu, Oct 10, 2019 at 4:59 PM Frank Louwers  wrote:

...

Neither Cogent or HE buy transit from anybody else. They only peer
and have customers. They don't buy "fallback" traffic.

that doesn't match the perspective from my server inside cogent.


[cc3.tisf:i386] traceroute6 www.he.net
connect: No route to host



[cc3.tisf:i386] traceroute -q1 www.he.net
traceroute to he.net (216.218.186.2), 64 hops max, 40 byte packets
1  136.161.101.1 (136.161.101.1)  0.411 ms
2  te0-0-0-34.rcr22.iad03.atlas.cogentco.com (38.104.58.89)  0.862 ms
3  be3524.ccr42.dca01.atlas.cogentco.com (154.54.46.193)  1.940 ms
4  be2658.ccr22.iad02.atlas.cogentco.com (154.54.47.138)  2.572 ms
5  telia.iad02.atlas.cogentco.com (154.54.12.62)  2.964 ms
6  ash-bb3-link.telia.net (80.91.248.156)  2.664 ms
7  las-b24-link.telia.net (62.115.121.220)  59.839 ms
8  hurricane-ic-350467-las-b24.c.telia.net (62.115.181.194)  59.751 ms
9  100ge16-1.core1.pao1.he.net (184.105.81.101)  67.101 ms
10  100ge14-1.core3.fmt1.he.net (72.52.92.66)  84.628 ms
11  *
^C


whatever HE is doing to make themselves available through Telia for 
IPv4, they are not also doing to make themselves available for IPv6.


--
P Vixie

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Randy Bush 
>> Neither Cogent or HE buy transit from anybody else

i believe this statement to be false

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Adam Vallee 
On Thu, Oct 10, 2019 at 10:40 AM David Conrad  wrote:

> Adam,
>
> I’d recommend reading "A Proposed Governance Model for the DNS Root
> Server System” (
> https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf)
>
> Regards,
> -drc
>
I think you are only helping my point, in that it says the following in
that document:
...
7.RSOs must operate with integrity and an ethos demonstrating a commitment
to the common good of the Internet.
...
11.RSOs must be neutral and impartial.

Cogent is not activating in a commitment to the common good of the
internet, and they are not neutral nor impartial.

More to my point, I believe that it is fundamental that the DNS system
stays a distributed system, and that the root-servers be maintained and
operated "to the common good of the internet". It is bad enough that the G
and H servers are only operated at a few locations, we generally rely on D,
E, F, and L root servers in Canada, because none of the other operators
will allow Canadian based ISPs or IXPs to host them. (this is an issue.)

And now we have this push to DoH and DoT which is the biggest false flag
that I have ever witnessed, and its only real intent is to put more power
in the hands of a few already powerful organizations, that will use the
data mined from their users to build advertising profiles. DoH and DoT have
only become a thing since GDPR. Why is no one saying anything?

Anyway, I hope you can see where I am coming from.
Adam Vallee
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Warren Kumari 
On Thu, Oct 10, 2019 at 4:59 PM Frank Louwers  wrote:
>
> Hi Warren,
>
> The lack of peering with a network doesn't prevent my accessing them,
> it just means that my packets take a sub-optimal[0] route.
> The above doesn't look like that at all, it looks like $something else
> (like dropped fragments), which is completely different to not
> peering[1].
>
>
> I feel like I haven't had my morning coffee, and am missing something
> wildly obvious here -- please, what it is?
> W
> [0]: Well, sub-optimal in terms of number of AS's, not necessarily in
> terms of congestion, latency, reliability, geography, etc.
>
>
> You don't peer with HE, but you buy transit from a company that does peer 
> with HE.
>
> Neither Cogent or HE buy transit from anybody else. They only peer and have 
> customers. They don't buy "fallback" traffic.

Oh... yes. As I said, I *felt* like I was missing something
obvious. That was it and now I feel like an idiot :-P

Thanks,
W



>
> Now if Cogent refuses to peer with HE (or the other way around), and they 
> both don't buy traffic from anybody else, they can't reach each other...
>
> Frank
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Viktor Dukhovni 
> On Oct 10, 2019, at 1:08 PM, Viktor Dukhovni  wrote:
> 
> Like Warren, I am quite surprised to learn that the IPv6 backbone
> has such gaps in 2019.  We're expected to *prefer* IPv6, but in
> reality one is a masochist to do so, (my server prefers V4). :-(

It seems this was already a surprise 7 years ago now:

  
https://www.agwa.name/blog/post/working_around_the_he_cogent_ipv6_peering_dispute

-- 
Viktor.


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Viktor Dukhovni 
On Wed, Oct 09, 2019 at 10:51:06PM -0400, Viktor Dukhovni wrote:

> I still see no answers from C or F from NYC via a Hurrican Electric
> GRE tunnel, since my ISP (Verizon FiOS) still does not provide
> native IPv6. :-(

Ray Bellis reached out asking me test a fix for F root's IPv6
reachability, and indeed (at least for me and also DNSViz) it is
better now.  Many thanks to Ray for the prompt resolution!

This leaves just "C"'s IPv6 address not reachable from HE's networks.
Like Warren, I am quite surprised to learn that the IPv6 backbone
has such gaps in 2019.  We're expected to *prefer* IPv6, but in
reality one is a masochist to do so, (my server prefers V4). :-(

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Stephane Bortzmeyer 
On Thu, Oct 10, 2019 at 04:39:19PM +0200,
 Warren Kumari  wrote 
 a message of 64 lines which said:

> The lack of peering with a network doesn't prevent my accessing them,

This is true for the IPv4 Internet, where there is always another
route, but the IPv6 Internet is not so well connected, and can be
partitioned.


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Frank Louwers 
Hi Warren,

> The lack of peering with a network doesn't prevent my accessing them,
> it just means that my packets take a sub-optimal[0] route.
> The above doesn't look like that at all, it looks like $something else
> (like dropped fragments), which is completely different to not
> peering[1].
> 
> 
> I feel like I haven't had my morning coffee, and am missing something
> wildly obvious here -- please, what it is?
> W
> [0]: Well, sub-optimal in terms of number of AS's, not necessarily in
> terms of congestion, latency, reliability, geography, etc.

You don't peer with HE, but you buy transit from a company that does peer with 
HE.

Neither Cogent or HE buy transit from anybody else. They only peer and have 
customers. They don't buy "fallback" traffic.

Now if Cogent refuses to peer with HE (or the other way around), and they both 
don't buy traffic from anybody else, they can't reach each other...

Frank

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread David Conrad 
Adam,

On Oct 10, 2019, at 8:28 AM, Adam Vallee  wrote:
> In my opinion, a new C root operator should be chosen based on the fact that 
> Cogent is not fulfilling its duty to operate their root servers for the 
> benefit of the internet as a whole.
> 
> It seems to me that they are operating the root for the benefit of their 
> customers only. And the fact that they do block access from HE.net 
>  over IPv6 should be grounds for their agreement to be torn 
> up,

What agreement?

> the responsibility should be assigned to a group of ISPs.
> 

> And don't get me started on G root, or H root.

I’d recommend reading "A Proposed Governance Model for the DNS Root Server 
System” (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf)

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Warren Kumari 
On Thu, Oct 10, 2019 at 5:12 AM Matthew Pounsett  wrote:
>
>
>
> On Wed, 9 Oct 2019 at 22:57, Viktor Dukhovni  wrote:
>>
>> On Wed, Oct 09, 2019 at 05:41:43PM -0400, Viktor Dukhovni wrote:
>>
>> > No, even small responses receive no answers from the IPv6 addresses
>> > of the C and F roots.  Both of the below time out even though I'm
>> > not setting the "DO" bit:
>> >
>> > $ dig -6 +norecur -t soa arpa. @2001:500:2f::f
>> > $ dig -6 +norecur -t soa arpa. @2001:500:2::c
>> >
>> > Looks like an outage from my vantage point.
>
>
> I can't speak to the reachability of F from that vantage point, but Cogent 
> has famously refused to peer over v6 with HE, which is why they're 
> unreachable from OARC (and therefore DNSViz) and lots of other places on the 
> Internet.
>

I must admit I'm feeling really stupid here, but I feel like I'm
missing something. Yes, Cogent might not peer with HE over v6, but I'm
trying to understand the failure mode -- I also (not famously at all!)
don't peer with Cogent over both v4 **and** v6 -- and yet, I can still
send and receive packets to them. I also don't peer with "E-Gate
Communications Inc., CA", which announces 67.215.196.35
(ns1.conundrum.com), and yet I can resolve conundrum.com.

The lack of peering with a network doesn't prevent my accessing them,
it just means that my packets take a sub-optimal[0] route.
The above doesn't look like that at all, it looks like $something else
(like dropped fragments), which is completely different to not
peering[1].


I feel like I haven't had my morning coffee, and am missing something
wildly obvious here -- please, what it is?
W
[0]: Well, sub-optimal in terms of number of AS's, not necessarily in
terms of congestion, latency, reliability, geography, etc.
[1]: I guess you could make the argument that if the peering existed,
packets are less likely to take tunnels / paths with small MTU /
broken pMTUD, etc, but that's a different argument...


> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases

2019-10-10 Thread Rob Seastrom 

Thanks everyone for the useful feedback and filling in the gaps for me.

We’ve now gone full circle since the easiest solution is to destroy and 
re-create a few VMs and a Raspberry Pi with the latest and greatest release and 
pkgsrc/apt (Viktor - I checked and latest Raspbian gets me Unbound 1.9.x)…  and 
conveniently they’re all defined in Ansible and I’ve done this multiple times 
before so it’s a quick and easy lunchtime endeavor.

cheers,

-r


> On Oct 9, 2019, at 3:49 PM, Dave Lawrence  wrote:
> 
> Viktor Dukhovni writes:
>> Yes, the expected behaviour when you explicitly request a CNAME
>> record is that (modulo DNAMEs in some parent zone) the qname is
>> resolved without further indirection, returning a CNAME if present
>> there, NXDOMAIN if the qname does not exist, or else NODATA.
> 
> Spot on.  I'd briefly considered the possibility that this was an
> amusing underspecified edge-case involving language about restarting
> the query when a CNAME is encountered, but even in 1980s RFC-speak,
> RFC 1034 section 3.6.2 was pretty clear on this:
> 
>"When a name server fails to find a desired RR in the resource set
>associated with the domain name, it checks to see if the resource
>set consists of a CNAME record with a matching class."
> 
> So, looking up qtype CNAME finds the desired RR and the subordinate
> clause is not triggered.  But just to make it crystal clear, it goes
> on to say, regarding an example of a USC-ISIC.ARPA alias pointing to
> C.ISI.EDU with an address record:
> 
>"Both of these RRs would be returned in the response to the 
>type A query, while a type CNAME or * [ANY] query should return
>just the CNAME."
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Ray Bellis 




On 10/10/2019 04:51, Viktor Dukhovni wrote:


 $ traceroute6 f.root-servers.net.
  1  tunnel545690.tunnel.tserv4.nyc4.ipv6.he.net  8.442 ms  6.772 ms  7.252 
ms
  2  ve422.core1.nyc4.he.net  4.641 ms  3.155 ms  5.392 ms
  3  100ge16-1.core1.ash1.he.net  10.781 ms  21.786 ms  8.046 ms
  4  100ge10-2.core1.lax1.he.net  65.768 ms  63.279 ms  62.687 ms
  5  * * *
  6  * * *
  7  * * *
  8  * * *
  9  * *^C


Thanks for the report - we'll look into this.

Ray Bellis
Director of DNS Operations, ISC.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

2019-10-10 Thread Adam Vallee 
In my opinion, a new C root operator should be chosen based on the fact
that Cogent is not fulfilling its duty to operate their root servers for
the benefit of the internet as a whole.

It seems to me that they are operating the root for the benefit of their
customers only. And the fact that they do block access from HE.net over
IPv6 should be grounds for their agreement to be torn up, the
responsibility should be assigned to a group of ISPs.

And don't get me started on G root, or H root.

Adam Vallee

On Wed., Oct. 9, 2019, 11:10 p.m. Matthew Pounsett, 
wrote:

>
>
> On Wed, 9 Oct 2019 at 22:57, Viktor Dukhovni 
> wrote:
>
>> On Wed, Oct 09, 2019 at 05:41:43PM -0400, Viktor Dukhovni wrote:
>>
>> > No, even small responses receive no answers from the IPv6 addresses
>> > of the C and F roots.  Both of the below time out even though I'm
>> > not setting the "DO" bit:
>> >
>> > $ dig -6 +norecur -t soa arpa. @2001:500:2f::f
>> > $ dig -6 +norecur -t soa arpa. @2001:500:2::c
>> >
>> > Looks like an outage from my vantage point.
>>
>
> I can't speak to the reachability of F from that vantage point, but Cogent
> has famously refused to peer over v6 with HE, which is why they're
> unreachable from OARC (and therefore DNSViz) and lots of other places on
> the Internet.
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS over TCP query uptick with iOS 13?

2019-10-10 Thread Xavier Beaudouin 
Hello,


>> I work for a Luxembourg company that provide Wifi in the street of
>> luxembourg cities (and some other places too).
>> 
>> I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used.
>> 
>> I don't have any graphs about its usage but yes our dnsdist is more and more
>> used.
> 
> This might very well also be traffic from Android 9, as that has probing of 
> DoT
> turned on by default. It would be interesting to compare the growth of DNS 
> over
> TLS with the statistics of Android OS version distribution..

Well maybe, but unfortunatly I have no idea how to check the Android version 
users have (well not directly)

I'll ask people there... if there is somewhat statistics on the captive portals.

Xavier
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS over TCP query uptick with iOS 13?

2019-10-10 Thread Alexander Mayrhofer 
Hello Xavier,

> I work for a Luxembourg company that provide Wifi in the street of
> luxembourg cities (and some other places too).
> 
> I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used.
> 
> I don't have any graphs about its usage but yes our dnsdist is more and more
> used.

This might very well also be traffic from Android 9, as that has probing of DoT 
turned on by default. It would be interesting to compare the growth of DNS over 
TLS with the statistics of Android OS version distribution..

Best,
Alex


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations