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

2019-10-20 Thread Paul Vixie
On Thursday, 17 October 2019 13:44:07 UTC Adam Vallee wrote:
> So what your admitting here, with your interesting choice of Words, is that
> Cogent is NOT in fact a Tier 1 provider. In the traditional definition of a
> "FreeNet" where a Tier 1 provider peers with all other Tier 1 providers in
> a shared cost model.

please don't put words in my mouth; they may not fit.

> That's good to know, because in fact our experience is that their service
> doesn't compare to Telia, HE, and GTT, and I was finally able to convince
> our NA Team to dump Cogent at Contract Renewal. Their routes are longer and
> have higher latency.

your business, your rules.

> And we now announce the C-Root ASN and IP prefixes to our internal network,
> in effect running our own C-Root.

your network, your rules.

> ...
> 
> Thank you for sharing.

to wit:

> On Wed., Oct. 16, 2019, 10:27 a.m. Paul Vixie,  wrote:
> > a late followup.
> > 
> > Rubens Kuhl wrote on 2019-10-12 13:50:
> > > ...
> > > 
> > > If someone from Cogent is reading, that's their opportunity to step
> > > up and provide at least a partial feed to OARC.
> > 
> > i'm part of the cogent c-root team, and i was a co-founder of dns-oarc.
> > we have hosted elements of the dns-oarc project at cogent before, and we
> > are working with the dns-oarc engineering team to make our
> > ipv6-addressed c-root server visible to their measurement systems.
> > 
> > > Unless they want to do the better thing which is to end this peering
> > > war and stop messing IPv6 Internet...
> > 
> > when i succeeded dave rand as cto of abovenet in Y2K or so, we had a
> > completely open peering policy -- we even peered with customers, if they
> > wanted a second BGP connection so they didn't have to pay by bit-volume
> > when exchange traffic with our other customers. this made business sense
> > to the company and its employees and investors and customers.
> > 
> > hurricane and cogent are also businesses, each having employees and
> > investors and customers. they are each doing what makes sense to them.
> > this is not a "peering war" by any stretch of the vocabulary. cogent
> > does not have a completely open peering policy, and while hurricane has
> > transit for its ipv4 network, it lacks transit for its ipv6 network.
> > 
> > their networks, their rules.
> > 
> > --
> > P Vixie

-- 
Paul


___
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-18 Thread Alarig Le Lay
On jeu. 17 oct. 09:44:07 2019, Adam Vallee wrote:
> I would suggest to everyone who has access to Telia or GTT, to try them
> out, and then you can possibly save money by dumping Cogentco. (That's if
> any of you are also part of your Network Architecture Teams.)

I have Cogent (and Telia and GTT) and don’t have any issue with them.

-- 
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-17 Thread Adam Vallee
So what your admitting here, with your interesting choice of Words, is that
Cogent is NOT in fact a Tier 1 provider. In the traditional definition of a
"FreeNet" where a Tier 1 provider peers with all other Tier 1 providers in
a shared cost model.

That's good to know, because in fact our experience is that their service
doesn't compare to Telia, HE, and GTT, and I was finally able to convince
our NA Team to dump Cogent at Contract Renewal. Their routes are longer and
have higher latency.
And we now announce the C-Root ASN and IP prefixes to our internal network,
in effect running our own C-Root.

And we pay less for our bandwidth from Telia than we're paying Cogentco.

I would suggest to everyone who has access to Telia or GTT, to try them
out, and then you can possibly save money by dumping Cogentco. (That's if
any of you are also part of your Network Architecture Teams.)

Thank you for sharing.

Adam Vallee

On Wed., Oct. 16, 2019, 10:27 a.m. Paul Vixie,  wrote:

> a late followup.
>
> Rubens Kuhl wrote on 2019-10-12 13:50:
> > ...
> >
> > If someone from Cogent is reading, that's their opportunity to step
> > up and provide at least a partial feed to OARC.
>
> i'm part of the cogent c-root team, and i was a co-founder of dns-oarc.
> we have hosted elements of the dns-oarc project at cogent before, and we
> are working with the dns-oarc engineering team to make our
> ipv6-addressed c-root server visible to their measurement systems.
>
> > Unless they want to do the better thing which is to end this peering
> > war and stop messing IPv6 Internet...
>
> when i succeeded dave rand as cto of abovenet in Y2K or so, we had a
> completely open peering policy -- we even peered with customers, if they
> wanted a second BGP connection so they didn't have to pay by bit-volume
> when exchange traffic with our other customers. this made business sense
> to the company and its employees and investors and customers.
>
> hurricane and cogent are also businesses, each having employees and
> investors and customers. they are each doing what makes sense to them.
> this is not a "peering war" by any stretch of the vocabulary. cogent
> does not have a completely open peering policy, and while hurricane has
> transit for its ipv4 network, it lacks transit for its ipv6 network.
>
> their networks, their rules.
>
> --
> P Vixie
>
> ___
> 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-16 Thread Jared Mauch



> On Oct 16, 2019, at 7:41 AM, Paul Vixie  wrote:
> 
> hurricane and cogent are also businesses, each having employees and investors 
> and customers. they are each doing what makes sense to them. this is not a 
> "peering war" by any stretch of the vocabulary. cogent does not have a 
> completely open peering policy, and while hurricane has transit for its ipv4 
> network, it lacks transit for its ipv6 network.

I'm unaware of any network that discriminates based on AFI for transit so this 
fails to pass the laugh test. 

> their networks, their rules.

I get this mantra, it applies in many cases but as per the above, it's poor 
behavior that harms us all. 
___
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-16 Thread Paul Vixie

a late followup.

Rubens Kuhl wrote on 2019-10-12 13:50:

...

If someone from Cogent is reading, that's their opportunity to step 
up and provide at least a partial feed to OARC.


i'm part of the cogent c-root team, and i was a co-founder of dns-oarc. 
we have hosted elements of the dns-oarc project at cogent before, and we 
are working with the dns-oarc engineering team to make our 
ipv6-addressed c-root server visible to their measurement systems.


Unless they want to do the better thing which is to end this peering 
war and stop messing IPv6 Internet...


when i succeeded dave rand as cto of abovenet in Y2K or so, we had a
completely open peering policy -- we even peered with customers, if they 
wanted a second BGP connection so they didn't have to pay by bit-volume 
when exchange traffic with our other customers. this made business sense 
to the company and its employees and investors and customers.


hurricane and cogent are also businesses, each having employees and 
investors and customers. they are each doing what makes sense to them. 
this is not a "peering war" by any stretch of the vocabulary. cogent 
does not have a completely open peering policy, and while hurricane has 
transit for its ipv4 network, it lacks transit for its ipv6 network.


their networks, their rules.

--
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-12 Thread Rubens Kuhl



> On 12 Oct 2019, at 10:03, Keith Mitchell  wrote:
> 
> On 10/11/19 6:30 PM, Shumon Huque wrote:
> 
>> It might be much more important for diagnostic and measurement services
>> like DNSviz though. At the moment, if you run IPv6 DNS servers on
>> networks that are singly connected to Cogent, it will probably
>> incorrectly flag those servers as unavailable. For such services,
>> perhaps it would be better if they were not single-homed to either
>> Cogent or HE.
> 
>> (To be clear, I'm happy that DNSviz is housed at OARC. So, I guess I
>> might be suggesting that the community might consider how to fund a
>> second ISP connection for OARC).
> 
> Thank You :-) That would be most welcome if anyone is prepared to step
> up (and/or open to other potential solutions) ? FWIW, we are at HE's
> Fremont2 facility, and peer at SFMIX.


If someone from Cogent is reading, that's their opportunity to step up and 
provide at least a partial feed to OARC. 
Unless they want to do the better thing which is to end this peering war and 
stop messing IPv6 Internet... 



Rubens


___
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-12 Thread Keith Mitchell
On 10/11/19 6:30 PM, Shumon Huque wrote:

> It might be much more important for diagnostic and measurement services
> like DNSviz though. At the moment, if you run IPv6 DNS servers on
> networks that are singly connected to Cogent, it will probably
> incorrectly flag those servers as unavailable. For such services,
> perhaps it would be better if they were not single-homed to either
> Cogent or HE.

> (To be clear, I'm happy that DNSviz is housed at OARC. So, I guess I
> might be suggesting that the community might consider how to fund a
> second ISP connection for OARC).

Thank You :-) That would be most welcome if anyone is prepared to step
up (and/or open to other potential solutions) ? FWIW, we are at HE's
Fremont2 facility, and peer at SFMIX.

Keith
___
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-11 Thread Shumon Huque
On Fri, Oct 11, 2019 at 4:12 PM Warren Kumari  wrote:

> On Fri, Oct 11, 2019 at 9:00 PM Joe Abley  wrote:
>
>>
>> What some people are seeing in this thread as a problem is actually a
>> nice demonstration that the system as a whole is immune to damage due to
>> partial-table peering disagreements.
>
>
> Indeed.
> W
>

I certainly agree that the Cogent-HE IPv6 peering dispute poses no
reliability or availability problems for the DNS root service.

But what impact might it have on individual services, organizations, and
other smaller entities? Since the Internet is still IPv4 omni-present, and
only partially IPv6, it probably doesn't matter at all to most.

It might be much more important for diagnostic and measurement services
like DNSviz though. At the moment, if you run IPv6 DNS servers on networks
that are singly connected to Cogent, it will probably incorrectly flag
those servers as unavailable. For such services, perhaps it would be better
if they were not single-homed to either Cogent or HE.

(To be clear, I'm happy that DNSviz is housed at OARC. So, I guess I might
be suggesting that the community might consider how to fund a second ISP
connection for OARC).

-- 
Shumon Huque
___
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-11 Thread Warren Kumari
On Fri, Oct 11, 2019 at 9:00 PM Joe Abley  wrote:

> On 11 Oct 2019, at 14:21, Paul Vixie  wrote:
>
> > in the earlier days of DNS-OARC (where dnsviz migrated to recently),
> there was a server at cogent, which was not reachable over IPv6 from users
> are hurricane. i don't remember anybody blaming hurricane for this, which
> is why it seems odd to blame cogent today when DNS-OARC is hosted at
> hurricane. hurricane has transit for their IPv4 network but not for their
> IPv6 network. cogent's peering policy isn't fully "open." it's hard for me
> to see that either of them is "in the wrong."
>
> For me, too. People need to put their pitchforks away.
>
> The root server system as a whole accomplishes this kind of redundancy in
> connectivity by having multiple root servers that are each
> differently-connected to the Internet. Many of those individual root
> servers are further distributed across multiple connectivity providers
> using anycast. C is one that is not, but since it's an active goal of the
> system as a whole to be diverse it's hard to see that as a problem. I
> guarantee that there are attack scenarios where having all the anycast
> nodes (and hence the attack traffic) in one AS is going to be an advantage
> for measurement, or mitigation, or something.
>
> There is a ridiculous amount of diversity in this system precisely so that
> nobody has to lose any hair when one (or even many) specific components are
> not reachable.
>
> What some people are seeing in this thread as a problem is actually a nice
> demonstration that the system as a whole is immune to damage due to
> partial-table peering disagreements.


Indeed.
W



>
> Joe
>
>
> ___
> 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-11 Thread Viktor Dukhovni
> On Oct 11, 2019, at 2:21 PM, Paul Vixie  wrote:
> 
> i think there are 13 names each having an A and an . so, 26 candidate 
> addresses. most resolvers will try them all and home in on the one with the 
> lowest RTT. if one of the 13 it tries via IPv6 doesn't answer, it won't 
> affect operations. in fact, one or more are unreachable from random places 
> almost always, and the system is designed with that in mind. (for example, 
> the use of UDP means unreliability is in-scope.)

Fair enough, and I don't have much "standing" in this case,
my server prefers IPv4, and I have a slave copy of both the
root and arpa zones...

I still feel (on behalf of others) that the situation is
unfortunate, though of course by no means dire.

There are likely more noticeable consequences for some users
than C-root unreachability, where the work-around isn't just
an occasional rare short lookup delay.

-- 
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-11 Thread Paul Vixie




Viktor Dukhovni wrote on 2019-10-10 17:51:

...

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.


i think there are 13 names each having an A and an . so, 26 
candidate addresses. most resolvers will try them all and home in on the 
one with the lowest RTT. if one of the 13 it tries via IPv6 doesn't 
answer, it won't affect operations. in fact, one or more are unreachable 
from random places almost always, and the system is designed with that 
in mind. (for example, the use of UDP means unreliability is in-scope.)



The error is immediately apparent via DNSViz:

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


in the earlier days of DNS-OARC (where dnsviz migrated to recently), 
there was a server at cogent, which was not reachable over IPv6 from 
users are hurricane. i don't remember anybody blaming hurricane for 
this, which is why it seems odd to blame cogent today when DNS-OARC is 
hosted at hurricane. hurricane has transit for their IPv4 network but 
not for their IPv6 network. cogent's peering policy isn't fully "open." 
it's hard for me to see that either of them is "in the wrong."


--
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-11 Thread A. Schulze



Arsen STASIC:


* Viktor Dukhovni  [2019-10-10 20:51 (-0400)]:

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/


RIPE Atlas DNSMON measurement doesn't indicate this:
https://atlas.ripe.net/dnsmon/group/root?dnsmon.session.color_range_pls=0-66-66-99-100=true=server-probes=root=undefined=156816=1570752000=true=both=false=2001:500:2::c



that link show "everything is green" because no server is below 66% drop rate
change to 3% show issues with C and D root.

also visible: F root is much better since 2019-10-10 ~14:00 UTC

Andreas

___
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-11 Thread Randy Bush
> 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

s/try to be/are not/

for cogent, v6 and v4 are parity

> but that they should because HE's v6 network is much wider reaching
> and much longer established than Cogent's.

and much longer tunnels and much breakage

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

for a value of 'significant' i do not see from any of my vantage points.

has this not gotten boring yet?

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-11 Thread Arsen STASIC

* Viktor Dukhovni  [2019-10-10 20:51 (-0400)]:

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/


RIPE Atlas DNSMON measurement doesn't indicate this:
https://atlas.ripe.net/dnsmon/group/root?dnsmon.session.color_range_pls=0-66-66-99-100=true=server-probes=root=undefined=156816=1570752000=true=both=false=2001:500:2::c

cheers,
-arsen
___
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-11 Thread David Conrad
Adam,

On Oct 11, 2019, at 12:36 AM, Adam Vallee  wrote:
> 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.

I have no comment on Cogent’s behavior in this context, however I think you 
missed my point.

RSSAC 37 is a proposal. It has not been implemented as yet, so it’s a bit hard 
to apply it in this particular case.

More directly, today, there are no agreements that dictate what root server 
operators must do.

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-11 Thread Stephane Bortzmeyer
On Thu, Oct 10, 2019 at 04:36:32PM -0400,
 Adam Vallee  wrote 
 a message of 114 lines which said:

> DoH and DoT have only become a thing since GDPR. Why is no one
> saying anything?

Are you serious? A lot of electrons are moved around DoH. Many
articles (most of them wrong). You certainly cannot say that "nobody
says anything".
___
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 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] 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] glitch on [ip6|in-addr].arpa?

2019-10-09 Thread sthaug
> 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.

But not universal. Both of these queries work fine from my vantage
point in Oslo, Norway. Traceroute shows 2001:500:2f::f as local,
while 2001:500:2::c seems to be in Hamburg.

Steinar Haug, AS2116
___
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-09 Thread Matthew Pounsett
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


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

2019-10-09 Thread Viktor Dukhovni
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 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. :-(

$ dig +short -t ns arpa. | sort |
while read ns; do
  dig +short -t  $ns |
  while read ip; do
echo "@$ns[$ip]:"
dig -6 +norecur +noall +ans +nocl +nottl -t soa arpa. @$ip
  done
done

I get (for both UDP and TCP):

@a.root-servers.net.[2001:503:ba3e::2:30]:
@b.root-servers.net.[2001:500:200::b]:
@d.root-servers.net.[2001:500:2d::d]:
@e.root-servers.net.[2001:500:a8::e]:
@g.root-servers.net.[2001:500:12::d0d]:
@h.root-servers.net.[2001:500:1::53]:
@i.root-servers.net.[2001:7fe::53]:
@k.root-servers.net.[2001:7fd::1]:
@l.root-servers.net.[2001:500:9f::42]:
@m.root-servers.net.[2001:dc3::35]:
arpa.   SOA a.root-servers.net. nstld.verisign-grs.com. 
2019101000 1800 900 604800 86400

@c.root-servers.net.[2001:500:2::c]:
@f.root-servers.net.[2001:500:2f::f]:
;; connection timed out; no servers could be reached

$ traceroute6 c.root-servers.net.
 1  tunnel545690.tunnel.tserv4.nyc4.ipv6.he.net  5.364 ms  4.937 ms  6.851 
ms
 2  ve422.core1.nyc4.he.net  5.516 ms  5.214 ms  3.592 ms
 3  * * *
 4  * * *
 5  * * *
 6  * *^C

$ 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

$ traceroute6 b.root-servers.net.
 1  tunnel545690.tunnel.tserv4.nyc4.ipv6.he.net  7.586 ms  5.679 ms  6.274 
ms
 2  ve422.core1.nyc4.he.net  2.290 ms  3.214 ms  3.492 ms
 3  100ge16-1.core1.ash1.he.net  30.615 ms  22.676 ms  10.004 ms
 4  100ge8-2.core1.atl1.he.net  19.438 ms  21.777 ms  22.249 ms
 5  100ge5-1.core1.tpa1.he.net  32.631 ms  33.048 ms  31.741 ms
 6  100ge12-1.core1.mia1.he.net  38.909 ms  35.077 ms  36.040 ms
 7  2001:478:124::241  40.241 ms  36.194 ms  36.724 ms
 8  2800:bc0:0:42::12  36.672 ms  36.952 ms  36.865 ms
 9  2001:500:205:5::2  36.565 ms  38.712 ms  36.606 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  *^C

Perhaps the issue is on the HE.net side?  Don't know whether that's
expected.  Doing the test from a server in .DE where I have a guest
account, I get answers from all the roots:

@a.root-servers.net.[2001:503:ba3e::2:30]:
@b.root-servers.net.[2001:500:200::b]:
@c.root-servers.net.[2001:500:2::c]:
@d.root-servers.net.[2001:500:2d::d]:
@e.root-servers.net.[2001:500:a8::e]:
@f.root-servers.net.[2001:500:2f::f]:
@g.root-servers.net.[2001:500:12::d0d]:
@h.root-servers.net.[2001:500:1::53]:
@i.root-servers.net.[2001:7fe::53]:
@k.root-servers.net.[2001:7fd::1]:
@l.root-servers.net.[2001:500:9f::42]:
@m.root-servers.net.[2001:dc3::35]:
arpa.   SOA a.root-servers.net. nstld.verisign-grs.com. 
2019101000 1800 900 604800 86400

But it seems that DNSViz and I are (still) in the same situation
with regard to the C and F IPv6 roots.

http://dnsviz.net/d/arpa/dnssec/

The IPv4 anycasts work fine:

@a.root-servers.net.[198.41.0.4]:
@b.root-servers.net.[199.9.14.201]:
@c.root-servers.net.[192.33.4.12]:
@d.root-servers.net.[199.7.91.13]:
@e.root-servers.net.[192.203.230.10]:
@f.root-servers.net.[192.5.5.241]:
@g.root-servers.net.[192.112.36.4]:
@h.root-servers.net.[198.97.190.53]:
@i.root-servers.net.[192.36.148.17]:
@k.root-servers.net.[193.0.14.129]:
@l.root-servers.net.[199.7.83.42]:
@m.root-servers.net.[202.12.27.33]:
arpa.   SOA a.root-servers.net. nstld.verisign-grs.com. 
2019101000 1800 900 604800 86400

-- 
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-09 Thread Viktor Dukhovni
On Wed, Oct 09, 2019 at 10:46:11PM +0200, A. Schulze wrote:

> while debugging a PTR resolution problem I noticed warnings on
> http://dnsviz.net/d/ip6.arpa/dnssec/ and
> http://dnsviz.net/d/in-addr.arpa/dnssec/
> To me, it looks like some in-addr-servers.arpa servers are unable to handle 
> large responses.

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.

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