Re: Mailing list SPF Failure

"Scott Q." writes: > Anyone else getting SPF failures on all messages sent to the list > ? > > I see them all originating from 50.31.151.76 but nanog.org's SPF > record doesn't list that as allowed. I see the same. nanog.org mail is originated from 2001:1838:2001:8:0:0:0:20 or 50.31.151.76,

Re: Anyone got a contact at OpenAI. They have a spider problem.

"John Levine" writes: > PS: If you were wondering what they're using to train GPT-5, well, now you > know. And it's not very trainable, it seems? I believe most amoebas respond better to 3 million identical events... Bjørn

Re: DNSSEC & WIldcards

Dennis Burgess writes: > Looks like Bjorn was correct, one two many signatures ☹ Removed one > and its all fixed! Thanks too all that replied!! Glad to hear that. But do note that Mark is right, of course. The real problem is a bug in your name server. What you have now is a workaround as

Re: DNSSEC & WIldcards

Looks like your DNS server correctly queues up the RRs, but erronously believes it can drop data from the Authority section without setting the TC bit. Reducing the bufsize so the answer doesn't fit makes trucation work: bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline +norecur

Re: DNSSEC & WIldcards

Matthew Pounsett writes: > But, right off the top I can see that your name server is returning the > NSEC record in the wrong section of the response. No, the Authority section is correct here. See: https://datatracker.ietf.org/doc/html/rfc4035#section-3.1.3.3 But the RRSIG is missing.

Re: DNSSEC & WIldcards

Dennis Burgess via NANOG writes: > So have *.app.linktechs.net that I have been trying to get to work, we > have DNSSEC on this, and its failing, but cannot for the life of me > understand why. I think it may have something to do with proving it > exists as a wildcard, but any DNSSEC experts

Re: puck not responding

George Herbert writes: > If it wasn’t for how clunky they are with email sites, I’d suggest > moving to a cloud somewhere. But … I believe statistics point in favour of the single puck.nether.net host BTW, for anyone else taking advantage of the excellent secondary service provided by

Re: ru tld down?

darkde...@darkdevil.dk writes: > With this example, you are asking why neither GTLD-SERVERS.NET nor > NSTLD.COM has been DNSSEC signed? That's a good point. Yes, I guess I do. I'm sure there is a good reason for all these examples. I just need to have it fed with a tiny spoon :-) Bjørn

Re: ru tld down?

Unrelated question, but this error made me notice: Why do they put their DNS servers in an unsigned zone? I can't figure out a good reason to do that when you have all the signing infrastructure in place. But I guess there must be a reason? Bjørn

Re: Charter DNS servers returning invalid IP addresses

"Jason J. Gullickson via NANOG" writes: > I've been working for a week or so to solve a problem with DNS > resolution for Charter customers for our domain bonesinjars.com. I've > reached-out to Charter directly but since I'm not a customer I > couldn't get any help from them. I was directed by

Re: JunOS/FRR/Nokia et al BGP critical issue

Eugeniu Patrascu writes: > On Fri, Sep 1, 2023 at 12:56 PM Bjørn Mork wrote: > >> But there's obviously not been enough thought applied to realize that >> optional transitive attributes must be considered evil by default. They >> can only be used after extremely care

Re: JunOS/FRR/Nokia et al BGP critical issue

Nick Hilliard writes: > Bjørn Mork wrote on 01/09/2023 08:17: >> Sounds familiar. >> https://supportportal.juniper.net/s/article/BGP-Malformed-AS-4-Byte-Transitive-Attributes-Drop-BGP-Sessions?language=en_US >> You'd think a lot of thought has gone into error han

Re: JunOS/FRR/Nokia et al BGP critical issue

Mike Lyon writes: > https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling?fbclid=IwAR13ePY43Vf3u4X8PDyCDT39DtyXczAKkv6CGXOQbcQv90Y3aIAmTkJxn7k_aem_Ad0hzj2Mh_WlbFZug-vGdlJJdXr2Xo0RFIsPwAU2GviPz6xZDib76YHwFuzU7E0_sJk=Zxz2cZ Sounds familiar.

Re: DNS resolution for hhs.gov

Interestingly enough, the company behind this mess decided to sign it: bjorn@canardo:~$ dig dhhs.gov @158.74.30.99 +nsid|grep NSID ; NSID: 4c 65 69 64 6f 73 20 62 75 69 6c 64 20 57 2e 56 45 52 4e 41 20 32 30 32 33 ("Leidos build W.VERNA 2023") Guessing this was done by "security

Re: Spamhaus flags any IP announced by our ASN as a criminal network

Brandon Zhi writes: > Well, those prefixes are not for their VPS hosting service (which cause a > lot of complaint). Just like there are many IP addresses under the > telecommunication company, the entire ASN cannot be "blocked" just because > there is a complaint on one IP address April came

Re: Random shower thought: GBIC with LC connector...

Maybe you're thinking of X2, looking similar to GBIC but even bigger? There were converters taking 2 gig SFPs in one X2 slot. Don't think either GBIC to SFP or GBIC with LC makes much sense. The alternatives were dirt cheap and easily available by the time these could have been products. Bjørn

Re: Router ID on IPv6-Only

Jeff Tantsura writes: > Looking at the fix, Donald has only removed IPV4_CLASS_DE(a) > uint32_t)(a)) & 0xe000) == 0xe000) > validation but kept INADDR_ANY. > I’ll bring up RFC6286 to him I believe it is implementing the RFC6286 requirements. INADDR_ANY is ((in_addr_t) 0x),

Re: Router ID on IPv6-Only

Jeff Tantsura writes: > Indeed, someone was recently complaining that FRR is unhappy with a > peer with router-id from class E range… This made me curious enough to dig up the fix. If anyone else is interested: https://github.com/FRRouting/frr/commit/b5c2113e47f846d0c48fb4ef63e29bf96bd2fbe2

Re: Router ID on IPv6-Only

Saku Ytti writes: > On Thu, 8 Sept 2022 at 10:01, Bjørn Mork wrote: > >> Why would you do it differently than for dual-stack routers, except that >> you skip the step where you configure the ID as a loopback address? > > Because you may not have an option, if you're

Re: Router ID on IPv6-Only

Crist Clark writes: > During some IPv6 numbering discussions at work today, someone had a > question that I hadn't really considered before. How to choose 32-bit > router IDs for IPv6-only routers. Why would you do it differently than for dual-stack routers, except that you skip the step where

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

Michael Thomas writes: > On 5/23/22 11:49 AM, Aaron Wendel wrote: >> The Fiber Broadband Association estimates that the average US >> household will need more than a gig within 5 years.  Why not just >> jump it to a gig or more? > > Really? What is the average household doing to use up a gig

Re: opendkim

Bjørn Mork writes: > Any hints on how to configure sendmail to avoid this are appreciated. This turned out to be simple. Should have looked first, as usual. The sendmail config problem was Debian specific, caused by dnl # add .' to mustquote chars (and match the binary default) changequ

opendkim (was: Re: Gmail (thus Nanog) rejecting ipv6 email)

"John Levine" writes: > It appears that Michael Thomas said: >> >>On 4/3/22 12:12 PM, Bjørn Mork wrote: >>> On a slightly related subject... This DKIM failure surprised me, but at >>> least I verified that many NANOG subscribers have mailservers retu

Re: Gmail (thus Nanog) rejecting ipv6 email

On a slightly related subject... This DKIM failure surprised me, but at least I verified that many NANOG subscribers have mailservers returning DMARC failure reports ;-) Bjørn Mork writes: > Authentication-Results: mx.google.com; > dkim=fail header.i=@mork.no header.s=b header.b=NB

Re: Gmail (thus Nanog) rejecting ipv6 email

Randy Bush writes: > i try to keep a list of goog's ipv6 email space and don't deliver to it; > rather using ipv4 instead. unfortunately, goog does not cooperate with > dnswl.org, so this can not be automated. How about using their SPF records as automation input? Their MXes are inside those

Re: Gmail (thus Nanog) rejecting ipv6 email

I didn't know anyone still cared? Google has been trying to move away from Internet email for many years now. Just let them. There is no way you can "fix" that problem on your side. If you care about specific recipients, then inform them that Google randomly throws away some of their

Re: MAP-T

JORDI PALET MARTINEZ via NANOG writes: > It comes from actual measurements in residential networks that already > offer IPv6. > > In typical residential networks, a very high % of the traffic is > Google/Youtube, Netflix, Facebook, CDNs, etc., which all are IPv6 > enabled. I wonder about

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

Paschal Masha writes: > :) probably the longest prepend in the world. > > A thought though, is it breaking any standard or best practice procedures? Don't think so. But there is this draft suggesting max 5: https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/ Bjørn

Re: V6 still not supported

Owen DeLong via NANOG writes: > Virtually every useful flow of packets in one direction requires a > relatively symmetrical flow of packets in the other direction. Packet captures are useful without anything being returned. It's not uncommon to use some sort of unidirectional tunnel to

Re: Russia to disconnect from global Internet

Stephane Bortzmeyer writes: > And yet noone says that the USA are disconnecting from the Internet. Exactly. They've never connected to it. Bjørn

Re: Certificates for DoT and DoH?

John Todd writes: > To validate that the addresses were “ours” or at least under our > control, there were still some hoops to jump through other than the > standard validation of registry data. For example, we had to activate > web servers and objects on our anycast network to answer specific >

Re: Certificates for DoT and DoH?

Bill Woodcock writes: >> Does this mean that DigiCert is the only alternative? > > I assume not, but we’d already used them for other things, and they > didn’t have a problem doing it, so we didn’t shop any further. Makes sense. That's how I started as well. But we are using Buypass, and for

Re: Certificates for DoT and DoH?

David Guo writes: > You don't need a certificate for your IP address if your DoT and DoH > use domains. Sorry if I'm slow, but isn't that a chicken-and-egg problem? We're going to provide this as an add-on to our standard ISP resolver service. Most clients will pick up the addresses from

Certificates for DoT and DoH?

Any recommendations for a CA with a published policy allowing an IP address SAN (Subject Alternative Name)? Preferably someone using ACME with a simple RFC 8738 reference. Let's Encrypt had this in their TODO list for a while, but it was removed and the project was put on hold:

Re: VPN recommendations?

Sabri Berisha writes: > I read on some mailing list that Meraki likes to ping 8.8.8.8 every > second... :) That's probably to be fair with the quad-x dns providers since they alrady were abusing 1.1.1.1. Makes me wonder what Meraki uses 9.9.9.9 for :-) Bjørn

Re: Slack.com DNSSEC on Feb 12th 15:00 UTC

RFC1912 says Wildcard As and CNAMEs are possible too, and are really confusing to users, and a potential nightmare if used without thinking first. You know the nightmare is real. You've been there. So why the heck do you insist on keeping that wildcard? Nobody else use wildcard A

Re: What do you think about the "cloudification" of mobile?

I don't know what that article says, but cloudification of the mobile core has been a thing for a while. We have this: https://wgtwo.com/ Disclaimer: I'm working for Telenor and spouse is working for Cisco. WG2 is a joint venture between Cisco, Telenor and Digital Alpha. Bjørn

Re: SOHO IPv6 switches

Brandon Martin writes: > The Netgear GS108T is my typical go-to "not a dumb switch". 8 ports > for about $80. > > Make sure you get the v3 if you want most of the modern IPv6 L2 > features (you also get some very limited L3 capabilities). Extra bonus with the GS108Tv3, and anything else based

Re: Anyone seeing ping corruption?

Masataka Ohta writes: > No, an ICMP echo reply does not include the entire request packets RFC792: The data received in the echo message must be returned in the echo reply message.

Re: .bv ccTLD

Jaap Akkerhuis writes: > SIDN and NORID once considered to market .BV together: > The rest of the story is here: https://www.norid.no/en/aktuelt/plans-to-utilize-bv-shelved-en/ Bjørn

Re: multihoming

Christopher Morrow writes: > Also, for completeness, MP-TCP clearly does not help UDP or ICMP flows... > nor IPSEC nor GRE nor... > unless you HTTP over MP-TCP and encap UDP/ICMP/GRE/IPSEC over that! IP over DNS has been a thing forever. IP over DoH should work just fine. > Talk about layer

Re: DNS pulling BGP routes?

Masataka Ohta writes: > William Herrin wrote: > This is quite common to tie an underlying service announcement to BGP announcements in an Anycast or similar environment. >>> >>> Yes, that is a commonly seen mistake with anycast. >> You don't know what you're talking about. > > I do but

Re: Better description of what happened

Tom Beecher writes: > Even if the external > announcements were not withdrawn, and the edge DNS servers could provide > stale answers, the IPs those answers provided wouldn't have actually been > reachable Do we actually know this wrt the tools referred to in "the total loss of DNS broke many

Re: Facebook post-mortems...

Masataka Ohta writes: > Bjørn Mork wrote: > >> Removing all DNS servers at the same time is never a good idea, even in >> the situation where you believe they are all failing. > > As I wrote: > > : That facebook use very short expiration period for zon

Re: Facebook post-mortems...

Masataka Ohta writes: > As long as name servers with expired zone data won't serve > request from outside of facebook, whether BGP routes to the > name servers are announced or not is unimportant. I am not convinced this is true. You'd normally serve some semi-static content, especially wrt

Re: Facebook post-mortems...

Jean St-Laurent via NANOG writes: > Let's check how these big companies are spreading their NS's. > > $ dig +short facebook.com NS > d.ns.facebook.com. > b.ns.facebook.com. > c.ns.facebook.com. > a.ns.facebook.com. > > $ dig +short google.com NS > ns1.google.com. > ns4.google.com. >

Re: IPv6 woes - RFC

Masataka Ohta writes: > That IPv6 will be disaggregated into /40 or even /32 is disastrous. It won't. No ISPs will deaggregate anything. Some multi-site enterprises might assign a /48 per remote site from their single prefix, and want those /48s routed via some transit peers. But this does

Re: IPv6 woes - RFC

Owen DeLong via NANOG writes: > The addresses aren’t the major cost of providing IPv4 services. > > CGN boxes, support calls, increasing size of routing table = buying new > routers, etc. You're counting dual-stack costs as if IPv4 was the optional protocol. That's a fantasy world. Time to

Re: IPv6 woes - RFC

Owen DeLong via NANOG writes: > This is my point… That is why I think an announcement of “On X date, > we will begin charging extra for IPv4 services and define Internet Access > to be IPv6” by a couple of the larger eyeball ISPs would light a pretty > big fire under those laggards. > > Think

Re: IPv6 woes - RFC

Saku Ytti writes: > On Tue, 7 Sept 2021 at 19:51, Owen DeLong wrote: > >> Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon. > > Fully agreed, I just don't see the driver. But I can imagine a > different timeline where in 2000 several tier1 signed mutual binding >

Re: IPv6 woes - RFC

JORDI PALET MARTINEZ via NANOG writes: > It is simple, most of your traffic will use IPv6. Depending on your > network/customer base 65-85%. > > You need less and less IPv4 addresses in the NAT64, less NAT64 boxes. > > Less resources to operate IPv6-only vs dual-stack. > > And because the IPv6

Re: IPv6 woes - RFC

JORDI PALET MARTINEZ via NANOG writes: > All this is resolved using IPv6-only and IPv4aaS, the same way as > cellular providers are doing with 464XLAT. Sure, there are a gazillion ways to provde edge access to both IPv4 and IPv6. You can pick anyone you like. But the extra layers still do not

Re: IPv6 woes - RFC

Saku Ytti writes: > On Mon, 6 Sept 2021 at 10:20, Bjørn Mork wrote: > >> Adding new access infrastructure of any sort (Fixed Wireless is the >> hype...)? Why would you want to continue being stupid even if you >> implemented dual-stack for all your fibre, hfc and dsl cus

Re: IPv6 woes - RFC

Saku Ytti writes: > I absolutely HATE testing, developing and supporting IPv4+IPv6, more > than doubling my time, adding 3rd stack would actually not increase > cost that much, it's the 1=>2 which is fantastically expensive. And > costs are transferred to customers. +1 > Those who have not

Re: IPv6 woes - RFC

Saku Ytti writes: > I view IPv6 as the biggest mistake of my career and feel responsible > for this horrible outcome and I do apologise to Internet users for > it. This dual-stack is the worst possible outcome, and we've been here > over two decades, increasing cost and reducing service quality.

Re: Where to get IPv4 block these day

Randy Bush writes: > what i love most about the why ipv6 {has not deployed | does not work > for me | must be used immediately if not sooner | ...} is that it > provides such a rich field for posting to nanog etc. and folk think of > new brilliant discussion points every day. +1 The endless

Re: FreeBSD's ping Integrates IPv6

Mark Tinka writes: > Been nearly 14 years since I last operated a Linux machine. I seriously doubt that. You're just not aware of it. Bjørn

Re: NAT devices not translating privileged ports

Fernando Gont via NANOG writes: > What has been reported to us is that some boxes do not translate the > src port if it's a privileged port. > > IN such scenarios, NTP implementations that always use src port=123, > dst port=123 might be in trouble if there are multiple NTP clients > behind the

Re: amazon.com multiple SPF records

Jean St-Laurent via NANOG writes: > What is spf2.0/pra ? https://datatracker.ietf.org/doc/html/rfc4406 It doesn't say April 1st, but it is pretty close Bjørn

Re: DANE of SMTP Survey

Jeroen Massar via NANOG writes: > For many organisations DNSSEC is 'scary' and a burden as it feels > 'fragile' for them. For "many"? Can you name one that doesn't feel like that? https://www.arin.net/vault/announcements/2019/20190204.html

Re: Juniper hardware recommendation

Adam Thompson writes: > * Skip the MX 2k/10k series – they don’t support SFP+ interfaces! https://apps.juniper.net/hct/model/?component=MX2K-MPC6E https://apps.juniper.net/hct/model/?component=MIC6-10G Bjørn

Re: Myanmar internet - something to think about if you're having a bad day

scott writes: > Telenor and Ooredoo, it's time to do the right thing. Wrt Telenor, please see the info posted at https://www.telenor.com/sustainability/responsible-business/human-rights/mitigate/human-rights-in-myanmar/directives-from-authorities-in-myanmar-february-2021/ Bjørn

Time to validate the TLS configuration on your SMTP servers (was: Re: AS5 ipv6 hijack?)

OK, so that email bounced. Or will eventually because this does not go away with someone doing something: ... Deferred: 403 4.7.0 TLS handshake failed. I am posting this in public because it unfortunately is a very common problem. Debian buster was released on July 6th, 2019. It includes

Re: AS5 ipv6 hijack?

Dmitry Sherman writes: > I see ipv6 bgp hijack of our prefixes via AS5. Or misunderstood prepending attempt, like hijacks from low AS numbers often are? Bjørn

Re: login.authorize.net has A and CNAME records

Mark Andrews writes: > It shouldn’t matter. Only non-rfc-compliant servers allow A and CNAME > to co-exist at the same name. That combination was prohibited by RFC > 1034. Right. Thanks. I confused myself multiple times here ;-) The issue seems to be that the cloudflare servers takes a

Re: login.authorize.net has A and CNAME records

Bjørn Mork writes: > Seth Mattinen writes: >> On 4/6/21 11:35 AM, Arne Jensen wrote: >>> login.authorize.net. is a CNAME, but does not have any A records itself. >> >> >> This one returns A records: > > Looks like they host DNS on both cloudflare an

Re: login.authorize.net has A and CNAME records

Seth Mattinen writes: > On 4/6/21 11:35 AM, Arne Jensen wrote: >> login.authorize.net. is a CNAME, but does not have any A records itself. > > > This one returns A records: Looks like they host DNS on both cloudflare and akami, but zone contents are different on the two platforms:

Re: DoD IP Space

Ca By writes: > The 3 cellular networks in the usa, 100m subs each, use ipv6 to uniquely > address customers. And in the case of ims (telephony on a celluar), it is > ipv6-only, afaik. I certainly agree that this is easier and makes more sense. I just don't buy the "can't be done" wrt using

Re: DoD IP Space

Ca By writes: > On Wed, Feb 10, 2021 at 4:32 AM Valdis Klētnieks > wrote: > >> On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said: >> > Please explain to me how you uniquely number 40M endpoints with RFC-1918 >> without running out of >> > addresses and without creating partitioned networks.

Re: DoD IP Space

Owen DeLong writes: > Please explain to me how you uniquely number 40M endpoints with RFC-1918 > without running out of > addresses and without creating partitioned networks. > > If you can’t, then I’m not the one making excuses. You added "without ..." and did not explain why. This does

Re: "Hacking" these days - purpose?

For fun and/or profit. Like the purpose always has been. Note that the definition of fun will vary. But overcoming a challenge of some sort is almost universally considered "fun". Bjørn

Re: Centurylink having a bad morning?

Eric Kuhnke writes: > There's a number of enterprise end user type customers of 3356 that have > on-premises server rooms/hosting for their stuff. And they spend a lot of > money every month for a 'redundant' metro ethernet circuit that takes > diverse fiber paths from their business park office

Re: Ipv6 help

Brian Johnson writes: >> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of >> customers. > > I cannot see how this is even possible. If I use private space > internally to the CGN, then the available external space is the same > and the internal customers are the same

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

What problem are you trying to solve? Bjørn

Re: Ipv6 help

Brandon Martin writes: > On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote: >> This is very common in many countries and not related to IPv6, but >> because many operators have special configs or features in the CPEs >> they provide. > > I really, really hate to force users to use my

Re: understanding IPv6

On Sun, Jun 7, 2020 at 2:00 AM Fred Baker wrote: > I'm sorry you have chosen to ignore documents like RFC 3315, which is > where DHCP PD was first described (in 2003). It's not like anyone's > hiding it. Erhm, you probably meant RFC 3633 (also 2003). There was no PD in the original DHCPv6

Re: understanding IPv6

Daniel Sterling writes: > In all seriousness, I have been trying to understand IPv6 for a long > time, and the documentation that I read (again, admittedly not often > RFCs, but certainly Wikipedia, linux distro docs, etc) never mentioned > DHCP PD, or at least never mentioned it as something

Don't email clients have a kill file?

At the risk of starting an off topic discussion here, but am I the only one who'd like to see more plonks and less troll feeding? I miss Usenet. Bjørn

Re: Are underground utility markers essential workers?

Nick Hilliard writes: > we have a very poorly-defined idea of what constitutes an "essential > worker" I thought "management" was the definition of non-essential workers. Who else would have a job without being essential/critical for day-to-day business? Bjørn

Re: free collaborative tools for low BW and losy connections

Nick Hilliard writes: > nntp is a non-scalable protocol which broke under its own > weight. How is nntp non-scalable? It allows an infinite number of servers connected in a tiered network, where you only have to connect to a few other peers and carry whatever part of the traffic you want.

Re: Gmail email blocking is off the rails (again)

"John Levine" writes: > Google accepts my mail just fine, including from my mailing lists. > Their goal is to make their users happy by accepting the mail the > users want and not the mail the users don't want. If we rule out asking the users for every mail, then that means applying statistics

Re: Disney+ Streaming

Sure. Like we all have been begging for an "Internet service" without any peering... The consumers have been begging for unbundling of content and transport. This does not imply fragmentation of either. That's a content provider straw man. It is only reasonable to assume that all content

Re: BGP over TLS

Christopher Morrow writes: > The x.509 system, to be effective here would require a TrustAnchor / > Root-of-Trust that both parties agreed was acceptable... As in a shared TrustAnchor? No. Both ends could use a simple self signed certificate and be configured to trust the other. A hash of

Re: BGP over TLS

Jeffrey Haas writes: > Exactly how the cert lifetime interacts with peering sessions is > likely to be several flavors of ugly. If you pin the key, then there is no reason to care about expiration. You could define the certificate as valid for as long as the pinned key matches. This is

BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")

Christopher Morrow writes: > isn't julien's idea more akin to DOT then DOH ? Yes, and I really like Julien's proposal. It even looks pretty complete. There are just a few details missing around how to make the MD5 => TLS transition smooth. Sorry for any confusion caused by an attempt to make

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

Julien Goodwin writes: > On 20/10/19 11:08 pm, Bjørn Mork wrote: >> Hank Nussbacher writes: >>> On 07/10/2019 17:42, Stephane Bortzmeyer wrote: >>>> On Fri, Oct 04, 2019 at 03:52:26PM -0400, >>>> Phil Pishioneri wrote >>>> a message o

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

Hank Nussbacher writes: > On 07/10/2019 17:42, Stephane Bortzmeyer wrote: >> 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

Re: Elad Cohen

Jon Sands writes: > On 9/19/2019 6:12 AM, Ronald F. Guilmette wrote: >> >> I just want to ruling on this. Am I the first and only person who has ever >> received a cartooney directly on the NANOG list? > > I can't remember if it was over NANOG or not, but back in 2010 a good > friend of mine

Re: Mx204 alternative

Mark Tinka writes: > The MX80 and MX104 have no business being in any modern conversation > these days :-). Except for the other MX-80, of course, which are better than ever. https://en.wikipedia.org/wiki/MX-80 Bjørn

Re: Protecting 1Gb Ethernet From Lightning Strikes

Måns Nilsson writes: > /Måns, has 6 pairs 9/125 between garage and house at home. Now you made me worry that my single OM4 pair to the garden shed might be insufficient ;-) Bjørn

Re: SFP supplier in Europe?

nanog-...@mail.com writes: > Unfortunately Fiberstore is what led me to ask about alternative > suppliers. Fiberstore actually ships in their Bidi SFPs from Asia Odd. They have lots of different BiDi SFFs "in Stock, EU Warehouse" according to https://www.fs.com/de-en/c/bidi-sfp-89 > and lead

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

Stephen Satchell writes: > On 3/5/19 2:54 AM, Thomas Bellman wrote: >> Out of curiosity, which operating systems put anything useful (for use >> in ECMP) into the flow label of IPv6 packets? At the moment, I only >> have access to CentOS 6 and CentOS 7 machines, and both of them set the >> flow

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

Måns Nilsson writes: > NS5 > 21 > DNSKEY3 > SPF 1 > A 28 > NSEC 62 > AFSDB 3 > RP1 > MX2 > CNAME 9 > SOA 2 > RRSIG 147 > TXT 6 > SSHFP 14 > SRV 20 > DS4 > Total:16 rrtypes in zone No TLSA records? Bjørn

Re: A Deep Dive on the Recent Widespread DNS Hijacking

Bill Woodcock writes: > We need to get switched over to DANE as quickly as possible, and stop > wasting effort trying to keep the CA system alive with ever-hackier > band-aids. Sure. Just won't happen as long as there is money left in the CA business. Bjørn

Re: sendmail.cf

b...@theworld.com writes: > The predecessor to sendmail was delivermail, 1979, also written by > Eric Allman. > > https://en.wikipedia.org/wiki/Delivermail Damn. Now you made me read RFC801 and wonder why we didn't have an updated version for the IPv6 transition. Or: Where would the Internet

Re: DNS Flag Day, Friday, Feb 1st, 2019

Mark Andrews writes: > I’ve been complaining for YEARS about lack of EDNS compliance. Didn't help. bjorn@miraculix:~$ dig +edns=42 +noednsnegotiation @1.1 ; <<>> DiG 9.11.5-P1-1-Debian <<>> +edns=42 +noednsnegotiation @1.1 ; (1 server found) ;; global options: +cmd ;; Got answer: ;;

Re: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk...

Miles Fidelman writes: > Ever since the net went commercial, we've been seeing more and more > walled gardens - driven by folks with an economic advantage to > segmenting & capturing audiences.  Whenever someone talks about how > great some new technology is, I'm always reminded to "follow the >

Re: Enough port 26 talk...

Yes. What is all the fuzz about? Email will be as dead as USENET in a couple of years anyway. Welcome to the age of "feeds". You may cry now. Bjørn

Re: WIndows Updates Fail Via IPv6

John Von Essen writes: > I recently go a Linksys home wifi router, by default it enables ipv6 > on the LAN. If there is no native IPv6 on the WAN side (which is my > case since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel. Could this be a 6RD tunnel requested by your ISP using

Re: bloomberg on supermicro: sky is falling

"Naslund, Steve" writes: > It only proves that you have seen the card at some point. Useless. It doesn't even prove that much. There is nothing preventing a rogue online shop from storing and reusing the CVV you give them. Or selling your complete card details including zip code, CVV and

  1   2   >