Re: Geolocation IP help
There is always talk to the local politician route so it gets raised in the state legislature. -- Mark Andrews > On 23 May 2024, at 06:27, Sam Kretchmer wrote: > > Yes, this was mentioned earlier too. I am just worried that the Illinois St > police don't update their database through any automated system, it has been > over 6 years since these IP's were transferred. > > Thanks! > > Sam > > > On 5/22/24, 15:20, "Randy Bush" mailto:ra...@psg.com>> wrote: > > >> You could try publishing Geo loc data per RFC8805 >> https://datatracker.ietf.org/doc/html/rfc8805 >> <https://datatracker.ietf.org/doc/html/rfc8805> > > > or, more specifically, 9092 > > > randy > > >
Re: DNSSEC & WIldcards
Yep. Look for an upgrade then file a bug report if not fixed by the upgrade. It should be < 10 minutes work to fix + tests etc. -- Mark Andrews > On 16 Mar 2024, at 05:18, Bjørn Mork wrote: > 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 solid as a house made of straw. > > > Bjørn
Re: DNSSEC & WIldcards
Wildcards and DNSSEC work fine as long as the nameserver vendor has not stuffed up. Too many vendors play fast and loose with the DNS protocol. Getting this correct is not hard but you do need to test before shipping. Additionally OS vendors tend to be way behind current releases from the nameserver vendors. -- Mark Andrews > On 16 Mar 2024, at 04:33, Bjørn Mork wrote: > > 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 want to take a stab at it >> ? > > Not an expert, but Google knows the answer (as always :-) > > bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline @8.8.8.8 > > ; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline > @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65184 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ; EDE: 10 (RRSIGs Missing): (For _acme-challenge.app.linktechs.net/nsec) > ;; QUESTION SECTION: > ;www.app.linktechs.net. IN A > > ;; Query time: 156 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) > ;; WHEN: Fri Mar 15 18:26:16 CET 2024 > ;; MSG SIZE rcvd: 98 > > > > And they're right. Your server includes the epected NSEC record, but > leaves out the associated RRSIG. Compare this to the > https://datatracker.ietf.org/doc/html/rfc7129#section-5.3 example: > > > bjorn@miraculix:~$ dig a www.app.linktechs.net. +dnssec +multiline > @139.60.210.20 > > ; <<>> DiG 9.18.24-1-Debian <<>> a www.app.linktechs.net. +dnssec +multiline > @139.60.210.20 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11828 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1280 > ;; QUESTION SECTION: > ;www.app.linktechs.net. IN A > > ;; ANSWER SECTION: > www.app.linktechs.net. 3600 IN A 139.60.210.81 > www.app.linktechs.net. 3600 IN RRSIG A 8 3 3600 ( >20240427232616 20240313222616 37041 > linktechs.net. >NYC/4H2VZg12vj+tiWVkEROhXwm7JkBna6RQg6LO8kXr >oosDUpGnxrgOtJYsWYbYfM58opiC1OeAbcaCB9+nctIU >grrwcpuhmvlXYLZi1n/oAmelPldnQ6Hf93HuHi4ULFsS >Qfsoo8sdfjt/YSJ4WxjmsM9LMbZ2CZPMU44a3MdftGW1 >fNKmZ1fLtVreP41KmvP6b01lyUMvjrvT26Yq57DgUDTo >iqU5skT+OHzx6ERJkt3tzzwm2pBMvBWFDXC668NtouIW >s3mrhJRBuNW3xSCsroaLQ0vmdml2BqNNh7MZNc38FNMJ >eh+ts3mbMnOOkzlI1Q8gKMMCWv+VRmv2DA== ) > www.app.linktechs.net. 3600 IN RRSIG A 8 3 3600 ( >20240427232616 20240313222616 11340 > linktechs.net. >Th3OcZwOMNUb1zMdipnTnFdgFEaOGJ/VofQOTyxmnNCg >wl+1Q7eiQ89KHAWEDBisxd0S+EHu6/YBWY2srNx5q58P >XIZJ9oQXCqDLzSE884DTQNDEVrSMoKJ9slRU4N4Lj5tT >9LzbODmCM9ytRavOKXJHIddQa0MZT4p9cV8K2HI7XSFX >0rjieKFa7wDRJqhKyqrT3Rh/S93pavhKWUgN3GVO6hkI >H5F67UFpZK7o7nRlyqvM42ep5XaRZS/WJtLuXcTk/QM3 >MBPTDWgJ0Bh8qpNuHDOb2XFH2I5dwjeKxuYCzeQzN1hL >gsmw3d1J2pNsYbC40jmi1bZr0bz2fDurIA== ) > > ;; AUTHORITY SECTION: > _acme-challenge.app.linktechs.net. 1200 IN NSEC auto.linktechs.net. TXT RRSIG > NSEC > > ;; Query time: 120 msec > ;; SERVER: 139.60.210.20#53(139.60.210.20) (UDP) > ;; WHEN: Fri Mar 15 18:27:13 CET 2024 > ;; MSG SIZE rcvd: 724 > > > > Lots of resolvers will probably just look up that NSEC, get the RRSIG > and be happy with that. But your problem is that there always will be a > number of resolvers not doing that. So you get arbitrary failures. > > I believe there are so many examples of really bad fallout due to > wildcards combined with DNSSEC that it's advisable to stay away. Do one > or the other. Not both. > > > > Bjørn
Re: DNSSEC & WIldcards
The authority section is the correct section for the NSEC. Ask the question using TCP. I suspect that the server isn’t truncating the UDP response correctly. If I’m right you will get RRSIGs for the NSEC added to the additional section. If not the zone needs to be resigned as they are missing. I’m answering from my phone or else I would look it up myself. -- Mark Andrews > On 16 Mar 2024, at 04:36, Matthew Pounsett wrote: > > > > >> On Fri, Mar 15, 2024 at 11:26 AM Dennis Burgess via NANOG >> wrote: >> 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 want to take a stab at it ? >> > > As others have mentioned, the DNS-operations list would be a better place to > get help: <https://lists.dns-oarc.net/mailman/listinfo/dns-operations> > > But, right off the top I can see that your name server is returning the NSEC > record in the wrong section of the response. >
Re: IPv6 uptake (was: The Reg does 240/4)
Well all that shows is that your ISP is obstructionist. If they can can enter a PTR record or delegate the reverse range to you for your IPv4 server they can do it for your IPv6 addresses. In most cases it is actually easier as address space is assigned on nibble boundaries (/48, /52, /56, /60, :64) so there isn’t a need to do multiple delegations and RFC2317 style “delegations” aren’t needed in IPv6. If there is a non nibble assignment just do multiple sequential delegations (2, 4 or 8). It isn’t hard to type the reverse prefix into a zone then ns then the name of a server, bump the serial and reload it. e.g. e.b.c.2.6.0.7.d.0.2.2.2.ip6.arpa. ns ns1.example.com. Good luck. -- Mark Andrews > On 16 Feb 2024, at 04:48, Stephen Satchell wrote: > > Several people in NANOG have opined that there are a number of mail servers > on the Internet operating with IPv6 addresses. OK. I have a mail server, > which has been on the Internet for decades. On IPv4. > > For the last four years, every attempt to get a PTR record in ip6.arpa from > my ISP has been rejected, usually with a nasty dismissive. > > Today, I'm trying again to get that all-important PTR record. If I'm > successful, then I expect to have my mail server fully up and running in the > IPv6 space within 72 hours, or when the DNS changes propagate, whichever is > longer.
Re: The Reg does 240/4
> On 15 Feb 2024, at 13:25, Stephen Satchell wrote: > > On 2/14/24 4:23 PM, Tom Samplonius wrote: >> The best option is what is happening right now: you can’t get new IPv4 >> addresses, so you have to either buy them, or use IPv6. The free market >> is solving the problem right now. Another solution isn’t needed. > > Really? How many mail servers are up on IPv6? Lots. > How many legacy mail clients can handle IPv6? Most. If you are using mbox format there is no change. The only ones that don’t handle it are ones that don’t have support for creating IPv6 connections. > How many MTA software packages can handle IPv6 today "right out of the box" > without specific configuration? Most. Really its been 20+ years since IPv6 was added to most of the mail products that actually use TCP to connect to a mail store or to send email. Just about the only thing that was needed to be done was to look for records in addition to A records after looking up the MX records or to replace gethostbyname with getnodebyname and then getaddrinfo. This was a 10 minute job for most developers. If you publish records for a service they will be used. > Does any IPv6 enabled ISP provide PTR records for mail servers? If they want to send email from those addresses they do. > How does Google handle mail from an IPv6 server? Mostly the same as from IPv4. > The Internet is not just the Web. It isn’t. But you could answer most of these by just looking at the email headers in your own incoming mail. Email has been delivered over IPv6 for over 2 decades now. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ru tld down?
> On 9 Feb 2024, at 03:10, darkde...@darkdevil.dk wrote: > > Den 31-01-2024 kl. 20:47 skrev Bjørn Mork: >> Why do they put their DNS servers in an unsigned zone? > > To try to make a more in-depth example: > > At the moment, .COM/.NET is relying on GTLD-SERVERS.NET for the authoritative > DNS. > > GTLD-SERVERS.NET is currently relying on NSTLD.COM for the authoritative DNS. > > With this example, you are asking why neither GTLD-SERVERS.NET nor NSTLD.COM > has been DNSSEC signed? > > In that case, I would probably be extending that a bit, considering a lot of > critical resources out there (even if announced as IPv6 /48 and IPv4 /24) > still do not have any RPKI ROA, at all. > > (But maybe that's just me...) The NS records in a delegation are NOT SIGNED. The glue addresses in a referral are NOT SIGNED. Resolvers use those. They should get back signed answers from signed zones which are verifiable. If they get back unsigned answers for signed zones they will be rejected. It they get back unsigned answers from an unsigned zone then all bets are off. DNSSEC sign your zones if you are worried about that. There is potential for information leakage with this strategy, but not wrong answers being returned from signed zones. Signing the zones would help a little with the information leakage when the servers are not learnt by glue. It is impossible to prevent all information leakage even if all zones, delgations and glue was signed. > -- > Med venlig hilsen / Kind regards, > Arne Jensen > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ru tld down?
> On 8 Feb 2024, at 17:17, Töma Gavrichenkov wrote: > > Peace, > > On Thu, 8 Feb 2024, 6:39 am Mark Andrews, wrote: > Given “MUST NOT” is not in RFC 4034, Appendix B, I’d take this with a grain > of salt. > > "Implementations MUST NOT assume that the key tag uniquely identifies a > DNSKEY RR." Missed that in my re-reading. > -- > Töma -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ru tld down?
Given “MUST NOT” is not in RFC 4034, Appendix B, I’d take this with a grain of salt. Appendix B has a “NOT RECOMMENDED” but that applies to using RSA/MD5 keys. Key id collisions are part and parcel of DNSSEC. In BIND we reject collisions when generating new keys so we don’t have to deal with multiple keys with the same key id and algorithm when signing. The validator handles them however. They do make re-signing more complicated (you have to verify the old signature against each key with a matching ID if you want to just deal with the signatures from a particular key or just re-sign with all keys with the same key id). Your key store also needs to be able to handle collisions. Mark > On 8 Feb 2024, at 05:58, Töma Gavrichenkov wrote: > > Peace, > > TWIMC: the .ru TLD has issued a post mortem. A tl;dr version: > > After a new key was crafted during an ordinary key update process, its key > tag hash-collided with some other key, and due to a violation of the MUST NOT > clause in the RFC 4034, Appendix B, the wrong key was deployed to the system. > > -- > Töma > > On Wed, 31 Jan 2024, 9:59 am Bill Woodcock, wrote: > >>> On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock wrote: > >>> Not exactly down… they just busted their DNSSEC, or their domain got > >>> hijacked or something. Bad DNSKEY records. > >> > >> On Jan 31, 2024, at 06:34, Eric Kuhnke wrote: > >> Not necessarily saying these are related, but given the current > >> geopolitical situation, not beyond the realm of possibility that this is > >> the result of 'something else' gone wrong. > > Phil Kulin posted a more specific timeline on dns-ops: > > > Begin forwarded message: > > > > From: Phil Kulin > > Subject: Re: [dns-operations] .RU zone failed ZSK rotation > > Date: January 31, 2024 at 03:34:40 GMT+1 > > To: Sergey Myasoedov > > Cc: dns-operati...@lists.dns-oarc.net > > > > Timeline: > > 2024-01-30 12:29:44 UTC: Last correct answer before outage (SOA SN: > > 4058855): https://dnsviz.net/d/ru/ZbjruA/dnssec/ > > 2024-01-30 15:27:27 UTC: First bad answer (SOA SN: 4058857): > > https://dnsviz.net/d/ru/ZbkVXw/dnssec/ > > 2024-01-30 17:27:35 UTC: Resigning attempt (SOA SN: 4058857 and > > 4058858): https://dnsviz.net/d/ru/Zbkxhw/dnssec/ > > 2024-01-30 17:59:46 UTC: Recovering process started (SOA SN: 4058857 > > and 4058857 and 4058858): https://dnsviz.net/d/ru/Zbk5Eg/dnssec/ > > 2024-01-30 19:07:29 UTC: First completely good answer (SOA SN: > > 4058856): https://dnsviz.net/d/ru/ZblI8Q/dnssec/ > > There’s no reason to think that any external parties influenced this. > Ockham’s razor. > > So many euphemisms suggest themselves in a situation like this… Own-goal, > one-car-accident, etc. Except that we all know that one small thing > overlooked and we’ll be in their shoes tomorrow. All geopolitics aside, my > empathy to the .RU operator. > > -Bill > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: route: 0.0.0.0/32 in LEVEL3 IRR
If you are using IPv4 address that belong to someone else internally you really are in a prime position to use IPv6 only internally and use one of the IPv4AAS mechanisms to reach the IPv4 internet. After a quarter of a century all your equipment should be IPv6 capable. -- Mark Andrews > On 1 Feb 2024, at 19:57, Owen DeLong via NANOG wrote: > > > >> On Jan 31, 2024, at 23:19, Frank Habicht wrote: >> >>> On 01/02/2024 01:45, Tom Beecher wrote: >>> Seems a bit dramatic. Companies all over the world have been using other >>> people's public IPs internally for decades. I worked at a place 20 odd >>> years ago that had an odd numbering scheme internally, and it was someone >>> else's public space. When I asked why, the guy who built it said "Well I >>> just liked the pattern." >>> If you're not announcing someone else's space into the DFZ, or otherwise >>> trying to do anything shady, the three letter agencies aren't likely to >>> come knocking. Doesn't mean anyone SHOULD be doing it, but still. >> >> Well... >> >> If you're using 20.20.20.0/24 which is not "yours" (as I've seen happen), >> then certainly your customers can't get to the real 20.20.20.x >> And even if that's not announced and used /today/ - this can change >> quickly... >> >> Frank > > You are repeating exactly the argument I made at the time. > > Owen >
Re: What are these Google IPs hammering on my DNS server?
> On 4 Dec 2023, at 08:21, Michael Hare via NANOG wrote: > > John- > > This is little consolation, but at AS3128, I see the same thing to our > downstream at times, claiming to come from both 13335 and 15169 often > simultaneously at the tune of 25Kpps , "assuming it's not spoofed", which is > pragmatically impossible to prove for me given our indirect relationships > with these companies. When I see these events, I typically also see a wide > variety of country codes participating simultaneously. Again, assuming it's > not spoofed. To me it just looks like effective harassment with 13335/15169 > helping out. I pine for the internet of the 1990s. Just set TC=1 for those clients. If you get queries over TCP then they where not spoofed. If they are using DNS COOKIE (RFC 7873) you can send back BADCOOKIE to the initial (client cookie only) UDP request with your server cookie. Identifying real DNS clients has been possible for years now. It’s not hard. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Am I the only one who thinks this is disconcerting?
The other thing it could be is broken PMTUD / failure fragment at network MTU. We defined socket options to do this 2 decades ago. -- Mark Andrews > On 9 Nov 2023, at 06:00, Matthew Pounsett wrote: > > On Wed, Nov 8, 2023 at 2:12 AM Bryan Fields wrote: >> >> >> Could these be related to the fact that dnsvis.net is trying to reach these >> servers via IPv6 and I think they use Hurricane for transit. Since HE and >> Cogent is a major gap, this causes them to time out trying to reach the C >> root >> server over IPv6. > > We have a tunnel set up to allow DNSViz to reach C-root, however > anything else single-homed on Cogent is unreachable to DNSViz via > IPv6.
Re: Am I the only one who thinks this is disconcerting?
It’s one broken server or firewall dropping fragmented responses In front of it. Just open a ticket. -- Mark Andrews > On 8 Nov 2023, at 07:29, Owen DeLong via NANOG wrote: > > > 10.159.192.in-addr.arpa > dnsviz.net > > > > Seems to report a bunch of errors in the DS records for 192.in-addr.arpa held > in the in-addr.arpa zone. > > I figured I’d wait a few days and try again the first few times I encountered > this, but it’s persisted for more than two weeks now. > > Owen >
Re: swedish dns zone enumerator
> On 2 Nov 2023, at 20:25, Stephane Bortzmeyer wrote: > > On Thu, Nov 02, 2023 at 04:09:24PM +1100, > Mark Andrews wrote > a message of 90 lines which said: > >> I also see QNAME minimisation in action as the QTYPE is NS. This >> could just be a open recursive servers using QNAME minimisation. >> With QNAME minimisation working correctly all parent zones should >> see is NS queries with the occasional DNSKEY and DS query. Both >> BIND and Knot use NS queries for QNAME minimisation. > > I disagree. NS queries were used in the first RFC about QNAME > minimisation (which was experimental) but the current one (which is on > the standards track) now recommends A or queries > <https://www.rfc-editor.org/info/rfc9156>, specially section 2.1. The QTYPE selection is always a matter of trade offs. NS is still perfectly fine and it is the ONLY type that actually works in a number of scenarios. Additionally the number of servers that don’t respond to NS queries is remarkably small and decreasing. More of an issue is garbage NS RRsets below the zone cut. A queries work well when there is a zone cut at each label. They don’t work well when there isn’t a zone cut. You get back nothing to say that there isn’t a zone cut which leaves you needing to do the discovery on the next query to the zone, and the next query to the zone, etc. This leads to complaints that you aren’t caching A (or whatever type you chose) queries. >> Other query types and/or prefixes do not work as they have >> undesirable side effects. > > Rather the contrary, some broken firewalls in front of authoritative > name servers were crashing when using NS queries. Hence the choice of > address queries. (Also, it improves privacy since it makes more > difficult to see you are doing QNAME minimisation.) Hiding that you are doing QNAME minimisation is a non issue. As for firewalls crashing. The more they crash the sooner they get fixed, it’s been years now. >> I would not like anyone to take seeing mostly NS queries as any >> evidence of bad practice. > > We agree here. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: swedish dns zone enumerator
You missed the point I was trying to make. While I think that that source is trying to enumerate some part of the namespace. NS queries by themselves don’t indicate an attack. Others would probably see the series of NS queries as a signature of an attack when they are NOT. There needs to be much more than that to make that conclusion. -- Mark Andrews > On 2 Nov 2023, at 06:15, Randy Bush wrote: > > ya, right, and at a whole bunch of other cctld servers > > from a network called domaincrawler-hosting > > shall we smoke another? > > /home/randy> sudo tcpdump -pni vtnet0 -c 500 port 53 and net 193.235.141 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes > 05:12:30.563268 IP 193.235.141.169.32768 > 666.42.7.11.53: 14 NS? > cgatcity.com.cu. (33) > 05:12:30.565017 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? > christ-jockel.jo. (34) > 05:12:30.565660 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? > cgatcity.al. (29) > 05:12:30.566490 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? > cgatcity.org.al. (33) > 05:12:30.566694 IP 193.235.141.3.32768 > 666.42.7.11.53: 14 NS? > christian-luber-jr.net.al. (43) > 05:12:30.569474 IP 193.235.141.239.32768 > 666.42.7.11.53: 14 NS? > clearing-muenchen.eg. (38) > 05:12:30.571870 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? > clearing-muenchen.com.ps. (42) > 05:12:30.573436 IP 193.235.141.23.32768 > 666.42.7.11.53: 14 NS? > cofls-welt.xn--pgbs0dh. (40) > 05:12:30.573914 IP 193.235.141.173.32768 > 666.42.7.11.53: 14 NS? > club-lederwerk-neustadt.net.al. (48) > 05:12:30.574608 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? > cofls-welt.az. (31) > 05:12:30.575203 IP 193.235.141.183.32768 > 666.42.7.11.53: 14 NS? > cofls-welt.lb. (31) > 05:12:30.575356 IP 193.235.141.215.32768 > 666.42.7.11.53: 14 NS? conomix.eg. > (28) > 05:12:30.575950 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? > conomix.net.ps. (32) > 05:12:30.577242 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? > computercheck-online.tn. (41) > 05:12:30.577800 IP 193.235.141.134.32768 > 666.42.7.11.53: 14 NS? conomix.cu. > (28) > 05:12:30.578272 IP 193.235.141.177.32768 > 666.42.7.11.53: 14 NS? > conomix.net.lb. (32) > 05:12:30.578480 IP 193.235.141.114.32768 > 666.42.7.11.53: 14 NS? > cstreibel.lr. (30) > 05:12:30.578896 IP 193.235.141.114.32768 > 666.42.7.11.53: 14 NS? > cstreibel.org.lb. (34) > 05:12:30.579060 IP 193.235.141.244.32768 > 666.42.7.11.53: 14 NS? > cristallcard.az. (33) > 05:12:30.580681 IP 193.235.141.11.32768 > 666.42.7.11.53: 14 NS? d-cypher.tn. > (29) > 05:12:30.581812 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? > d-cypher.al. (29) > 05:12:30.582157 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? > dailycatesse.sz. (33) > 05:12:30.582381 IP 193.235.141.142.32768 > 666.42.7.11.53: 14 NS? > d-cypher.eg. (29) > 05:12:30.583340 IP 193.235.141.125.32768 > 666.42.7.11.53: 14 NS? > damensattel-duesseldorf.net.ps. (48) > 05:12:30.583439 IP 193.235.141.181.32768 > 666.42.7.11.53: 14 NS? > dailycatesse.az. (33) > 05:12:30.584078 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? > dailycatesse.mw. (33) > 05:12:30.584330 IP 193.235.141.160.32768 > 666.42.7.11.53: 14 NS? > dailycatesse.org.al. (37) > 05:12:30.584730 IP 193.235.141.3.32768 > 666.42.7.11.53: 14 NS? > darkroom24.net.al. (35) > 05:12:30.585506 IP 193.235.141.7.32768 > 666.42.7.11.53: 14 NS? > damensattel-duesseldorf.jo. (44) > 05:12:30.585995 IP 193.235.141.127.32768 > 666.42.7.11.53: 14 NS? > dassehen.lr. (29) > 05:12:30.587759 IP 193.235.141.173.32768 > 666.42.7.11.53: 14 NS? > darkroom24.tn. (31) > 05:12:30.588076 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? > dgurock.org.al. (32) > 05:12:30.589055 IP 193.235.141.212.32768 > 666.42.7.11.53: 14 NS? dictys.jo. > (27) > 05:12:30.589640 IP 193.235.141.240.32768 > 666.42.7.11.53: 14 NS? dgurock.az. > (28) > 05:12:30.591432 IP 193.235.141.172.32768 > 666.42.7.11.53: 14 NS? > dictys.com.ps. (31) > 05:12:30.592608 IP 193.235.141.213.32768 > 666.42.7.11.53: 14 NS? > disko-thema.org.al. (36) > 05:12:30.593365 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? > diesling-1.net.al. (35) > 05:12:30.593814 IP 193.235.141.147.32768 > 666.42.7.11.53: 14 NS? > diesling-1.ps. (31) > 05:12:30.595057 IP 193.235.141.240.32768 > 666.42.7.11.53: 14 NS? > disko-thema.net.al. (36) > 05:12:30.595722 IP 193.235.141.157.32768 > 666.42.7.11.53: 14 NS? > disko-thema.xn--mgbayh7gpa. (44) > 05:12:30.596496 IP 193.235.141.135.32768 > 666.42
Re: swedish dns zone enumerator
While I see evidence for the claim, 5 character left hand label and all non-existant. I also see QNAME minimisation in action as the QTYPE is NS. This could just be a open recursive servers using QNAME minimisation. With QNAME minimisation working correctly all parent zones should see is NS queries with the occasional DNSKEY and DS query. Both BIND and Knot use NS queries for QNAME minimisation. Other query types and/or prefixes do not work as they have undesirable side effects. I would not like anyone to take seeing mostly NS queries as any evidence of bad practice. On the contrary, this is best practice. It’s just relatively new. I would also like to remind everyone here that QNAME minimisation using NS queries will expose the bad practice of having mis-matching NS RRsets above and below the zone cut and having garbage NS RRsets in the child zone when both parent and child are served by the same servers. Please ensure your NS RRsets are consistent on both sides of the zone cut and that they are sane. Mark > On 1 Nov 2023, at 09:46, Randy Bush wrote: > > i have blocked a zone enumerator, though i guess they will be a > whack-a-mole > > others have reported them as well > > /home/randy> sudo tcpdump -pni vtnet0 -c 10 port 53 and net 193.235.141 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes > 22:42:39.516849 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? > 33j4h.org.al. (30) > 22:42:39.517640 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? > 33m6d.xn--mgbayh7gpa. (38) > 22:42:39.519169 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 33lxd.tn. > (26) > 22:42:39.520064 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? 33md6.jo. > (26) > 22:42:39.521081 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? 33lxd.lb. > (26) > 22:42:39.523981 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 33pd2.az. > (26) > 22:42:39.525043 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? > 33nc5.com.al. (30) > 22:42:39.526185 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? 33nc5.sz. > (26) > 22:42:39.527931 IP 193.235.141.150.32768 > 666.42.7.11.53: 14 NS? > 33q5p.com.al. (30) > 22:42:39.529516 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS? > 33qbq.com.al. (30) > 10 packets captured > 124 packets received by filter > 0 packets dropped by kernel > > inetnum:193.235.141.0 - 193.235.141.255 > netname:domaincrawler-hosting > descr: domaincrawler hosting > org:ORG-ABUS1196-RIPE > country:SE > admin-c:VIJE1-RIPE > tech-c: VIJE1-RIPE > status: ASSIGNED PA > notify: c+1...@resilans.se > mnt-by: RESILANS-MNT > mnt-routes: ETTNET-LIR > created:2008-04-03T11:21:00Z > last-modified: 2017-04-10T12:47:06Z > source: RIPE > > randy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Charter DNS servers returning invalid IP addresses
It’s being filtered. Only Charter can tell you why. -- Mark Andrews > On 26 Oct 2023, at 05:07, Jason J. Gullickson via NANOG > wrote: > > > 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 a friend to this list in hopes that there may be > able to reach a Charter/Spectrum engineer who might be able to explain and/or > resolve this one. > > A dig against Google's DNS servers correctly returns 4 A records: > > > dig bonesinjars.com 8.8.8.8 > > ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> bonesinjars.com 8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31383 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 65494 > ;; QUESTION SECTION: > ;bonesinjars.com. IN A > > ;; ANSWER SECTION: > bonesinjars.com.60 IN A 198.49.23.145 > bonesinjars.com.60 IN A 198.185.159.145 > bonesinjars.com.60 IN A 198.49.23.144 > bonesinjars.com.60 IN A 198.185.159.144 > > ;; Query time: 1039 msec > ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) > ;; WHEN: Mon Oct 23 10:26:32 CDT 2023 > ;; MSG SIZE rcvd: 108 > > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26879 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 65494 > ;; QUESTION SECTION: > ;8.8.8.8. IN A > > ;; Query time: 35 msec > ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) > ;; WHEN: Mon Oct 23 10:26:32 CDT 2023 > ;; MSG SIZE rcvd: 36 > > > > Verizon, AT, Comcast and all other DNS servers we tested return the same 4 > A records. However the same dig against a Charter DNS (24.196.64.53) returns > only 127.0.0.54: > > > > dig bonesinjars.com 24.196.64.53 > > ; <<>> DiG 9.16.1-Ubuntu <<>> bonesinjars.com 24.196.64.53 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17691 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 65494 > ;; QUESTION SECTION: > ;bonesinjars.com.INA > > ;; ANSWER SECTION: > bonesinjars.com.60INA127.0.0.54 > > ;; Query time: 55 msec > ;; SERVER: 127.0.0.53#53(127.0.0.53) > ;; WHEN: Tue Oct 24 13:28:36 CDT 2023 > ;; MSG SIZE rcvd: 60 > > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4658 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 65494 > ;; QUESTION SECTION: > ;24.196.64.53.INA > > ;; ANSWER SECTION: > 24.196.64.53.86400INA24.196.64.53 > > ;; Query time: 27 msec > ;; SERVER: 127.0.0.53#53(127.0.0.53) > ;; WHEN: Tue Oct 24 13:28:36 CDT 2023 > ;; MSG SIZE rcvd: 57 > > > > Any help understanding and addressing this is greatly appreciated! > > > > Jason
Re: maximum ipv4 bgp prefix length of /24 ?
> On 13 Oct 2023, at 08:31, scott wrote: > > > > > On 10/11/23 7:47 PM, Mark Andrews wrote: >> Virtually no home network on the planet has fully functional IPv4 available >> to it. > > > Hawaiian Telcom customers have it. No blocks at all. So they don’t use NAT? The internet is a peer-to-peer network. NAT breaks that. But I can’t reach IPv6 devices on the Internet from my IPv4 device without a transition box is no different to I can’t reach IPv4 devices on the Internet from my IPv4 device because PNAT *is* a transition device. It’s a bogus complaint and I’m calling it out. > scott -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: maximum ipv4 bgp prefix length of /24 ?
> On 12 Oct 2023, at 06:51, Delong.com wrote: > > > >> On Oct 11, 2023, at 12:47, Mark Andrews wrote: >> >> It is no different to deploying PNAT44 in every CPE box in the world to >> allow you to connect to the global IPv4 internet today. Virtually no home >> network on the planet has fully functional IPv4 available to it. Many >> businesses networks don’t have fully functional IPv4 networks. We have >> already installed transition middle boxes between the public IPv4 internet >> and your private IPv4 internet. The are just so ubiquitous that you are >> unaware of them. This is just a transition between your IPv4 internet >> (public or private) and the global IPv6 internet. > > 1. I’m one of the few homes that is an exception to that “virtually no home” > statement. > 2. Yes, I’m acutely aware of them, I’ve deployed plenty of them, and regret > each and every one. > 3. The difference is that you can deploy a PNAT44 CPE box without an IPv6 > address. You cannot > deploy a NAPT64 box without an IPv4 address. > >> Almost all traffic flows go through a transition box today. > > Sad but true. Still not really relevant to the point being made. > >> If the router modifies the source or destination addresses or the ports of >> the packet it is a transition box. It is the border between two internets. > > Absolutely agree… Still not the point… > > The point here is that at some point, even with translation, we run out of > IPv4 addresses to use for this purpose. What then? You deliver the Internet over IPv6. A really large functional Internet exists today if you only have IPv6. It is only getting bigger. Lots of (the majority?) of CDNs deliver content over IPv6. Lots of companies outsource their SMTP to dual stacked service providers so that email still gets through. After 20 years there is no excuse for ISPs failing to deliver IPv6. If you have to you, outsource your NAT64, DS-Lite transition service to someone that has IPv4. I’m surprised that it isn’t common today. > Owen > >> >> -- >> Mark Andrews >> >>> On 12 Oct 2023, at 06:07, Delong.com wrote: >>> >>> >>> >>>>> On Oct 10, 2023, at 17:20, Mark Andrews wrote: >>>>> >>>>> >>>>> >>>>>> On 11 Oct 2023, at 09:43, Delong.com via NANOG wrote: >>>>> >>>>>> As a community, we have failed, because we never acknowledged and >>>>>> addressed the need for backward compatibility between IPv6 and IPv4, and >>>>>> instead counted on magic handwaving about tipping points and transition >>>>>> dates where suddenly there would be "enough" IPv6-connected resources >>>>>> that new networks wouldn't *need* IPv4 address space any more. >>>>> >>>>> I’m not sure that we never acknowledged it, but we did fail to address >>>>> it, largely because I think we basically determined that it’s “too hard”. >>>> >>>> It’s not actually that hard to do on a small scale, i.e. inside a home CPE >>>> with a DNS server and a NAT64 implementation that supports semi static >>>> mappings. It does require IPv4 sites have IPv6 connectivity. You stand up >>>> a DNS46 which requests an unused IPv4 address from a prefix block, say >>>> 10/8, when there is an IPv6 address without an IPv4 address from the NAT64 >>>> with the IPv6 address it needs to be mapped to with an initial NAT64 >>>> lifetime value. The DNS46 would forget the mapping after half that >>>> initial lifetime. The DNS46 would return A records limited half the >>>> lifetime or less so they timeout before the NAT64 mapping expires. The >>>> hard part is scaling up to a large client base because not every DNS query >>>> results in IP traffic and you need a prefix block big enough to support >>>> the add rate of the client base. Doing this at ISP scale would be >>>> interesting to say the least. This is not theoretical. It has been >>>> implemented in the past though some to the details might differ. >>> >>> That’s not what we’re talking about… That’s translation, not backwards >>> compatibility. >>> >>>> Companies that have gone IPv6-only internally do this with fully static >>>> IPv4 to IPv6 mappings and skip the DNS46 step. >>> >>> But doing that requires that the companies have a certain amount of V4. The >>> question was how to talk to v4-only host
Re: maximum ipv4 bgp prefix length of /24 ?
It is no different to deploying PNAT44 in every CPE box in the world to allow you to connect to the global IPv4 internet today. Virtually no home network on the planet has fully functional IPv4 available to it. Many businesses networks don’t have fully functional IPv4 networks. We have already installed transition middle boxes between the public IPv4 internet and your private IPv4 internet. The are just so ubiquitous that you are unaware of them. This is just a transition between your IPv4 internet (public or private) and the global IPv6 internet. Almost all traffic flows go through a transition box today. If the router modifies the source or destination addresses or the ports of the packet it is a transition box. It is the border between two internets. -- Mark Andrews > On 12 Oct 2023, at 06:07, Delong.com wrote: > > > >>> On Oct 10, 2023, at 17:20, Mark Andrews wrote: >>> >>> >>> >>>> On 11 Oct 2023, at 09:43, Delong.com via NANOG wrote: >>> >>>> As a community, we have failed, because we never acknowledged and >>>> addressed the need for backward compatibility between IPv6 and IPv4, and >>>> instead counted on magic handwaving about tipping points and transition >>>> dates where suddenly there would be "enough" IPv6-connected resources that >>>> new networks wouldn't *need* IPv4 address space any more. >>> >>> I’m not sure that we never acknowledged it, but we did fail to address it, >>> largely because I think we basically determined that it’s “too hard”. >> >> It’s not actually that hard to do on a small scale, i.e. inside a home CPE >> with a DNS server and a NAT64 implementation that supports semi static >> mappings. It does require IPv4 sites have IPv6 connectivity. You stand up a >> DNS46 which requests an unused IPv4 address from a prefix block, say 10/8, >> when there is an IPv6 address without an IPv4 address from the NAT64 with >> the IPv6 address it needs to be mapped to with an initial NAT64 lifetime >> value. The DNS46 would forget the mapping after half that initial lifetime. >> The DNS46 would return A records limited half the lifetime or less so they >> timeout before the NAT64 mapping expires. The hard part is scaling up to a >> large client base because not every DNS query results in IP traffic and you >> need a prefix block big enough to support the add rate of the client base. >> Doing this at ISP scale would be interesting to say the least. This is not >> theoretical. It has been implemented in the past though some to the details >> might differ. > > That’s not what we’re talking about… That’s translation, not backwards > compatibility. > >> Companies that have gone IPv6-only internally do this with fully static IPv4 >> to IPv6 mappings and skip the DNS46 step. > > But doing that requires that the companies have a certain amount of V4. The > question was how to talk to v4-only hosts with ZERO IPv4 addresses available > to you. > >> So if you have a legacy device that can’t talk IPv6 there is a solution >> space that allows it to talk to the IPv6 internet. You need to install it >> however. Adding DNS46 to a nameserver is about a days if you already have a >> DNS64 model. The hard bit is working out how to talk to the NAT64 >> implementation. A good project to put on a Raspberry Pi or similar. > > I’m a new entity. I need to talk to the IPv4 internet. I have zero IPv4 > addresses and none are available to me. > > How do I make any of this work? > > That’s the question that remains unsolved and that’s the one we most > desperately failed to tackle. > > Owen >
Re: maximum ipv4 bgp prefix length of /24 ?
> On 11 Oct 2023, at 09:43, Delong.com via NANOG wrote: > >> As a community, we have failed, because we never acknowledged and addressed >> the need for backward compatibility between IPv6 and IPv4, and instead >> counted on magic handwaving about tipping points and transition dates where >> suddenly there would be "enough" IPv6-connected resources that new networks >> wouldn't *need* IPv4 address space any more. > > I’m not sure that we never acknowledged it, but we did fail to address it, > largely because I think we basically determined that it’s “too hard”. It’s not actually that hard to do on a small scale, i.e. inside a home CPE with a DNS server and a NAT64 implementation that supports semi static mappings. It does require IPv4 sites have IPv6 connectivity. You stand up a DNS46 which requests an unused IPv4 address from a prefix block, say 10/8, when there is an IPv6 address without an IPv4 address from the NAT64 with the IPv6 address it needs to be mapped to with an initial NAT64 lifetime value. The DNS46 would forget the mapping after half that initial lifetime. The DNS46 would return A records limited half the lifetime or less so they timeout before the NAT64 mapping expires. The hard part is scaling up to a large client base because not every DNS query results in IP traffic and you need a prefix block big enough to support the add rate of the client base. Doing this at ISP scale would be interesting to say the least. This is not theoretical. It has been implemented in the past though some to the details might differ. Companies that have gone IPv6-only internally do this with fully static IPv4 to IPv6 mappings and skip the DNS46 step. So if you have a legacy device that can’t talk IPv6 there is a solution space that allows it to talk to the IPv6 internet. You need to install it however. Adding DNS46 to a nameserver is about a days if you already have a DNS64 model. The hard bit is working out how to talk to the NAT64 implementation. A good project to put on a Raspberry Pi or similar. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: what is acceptible jitter for voip and videoconferencing?
The implication would look at the terminal characteristics and enable as required. -- Mark Andrews > On 23 Sep 2023, at 08:33, Michael Thomas wrote: > > >> On 9/22/23 1:54 PM, Mark Andrews wrote: >> Telnet sessions where often initiated from half duplex terminals. Pushing >> that flow control across the network helped those users. >> > I'm still confused. Did it require the telnet users to actually take action? > Like they'd manually need to enter the GA option? It's very possible that I > didn't fully implement it if so since I didn't realize that. > > Mike >
Re: what is acceptible jitter for voip and videoconferencing?
Telnet sessions where often initiated from half duplex terminals. Pushing that flow control across the network helped those users. -- Mark Andrews > On 23 Sep 2023, at 06:25, Michael Thomas wrote: > > >> On 9/22/23 9:42 AM, Jay Hennigan wrote: >>> On 9/21/23 17:04, Michael Thomas wrote: >>> >>> When I wrote my first implementation of telnet ages ago, i was both amused >>> and annoyed about the go-ahead option. Obviously patterned after audio >>> meat-space protocols, but I was never convinced it wasn't a solution in >>> search of a problem. I wonder if CDMA was really an outgrowth of those >>> protocols? >> >> Typically seen with half-duplex implementations, like "Over" in two-way >> radio. Still used in TTY/TDD as "GA". >> > DId that ever actually occur over the internet such that telnet would need > it? Half duplex seems to be pretty clearly an L1/L2 problem. IIRC, it was > something of a pain to implement. > > Mike >
Re: NTP Sync Issue Across Tata (Europe)
> On 7 Aug 2023, at 12:02, Rubens Kuhl wrote: > > > > On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman wrote: > Or one can read recent research papers that thoroughly document the > incredible fragility of the existing NTP hierarchy and soberly consider their > recommendations for remediation: > > The paper suggests the compromise of critical infrastructure. So, besides not > using NTP, why not stop using DNS ? Just populate a hosts file with all you > need. Well DNS can be cryptographically secured. There really isn’t any good reasons to not sign your zones today. The majority of responses from authoritative servers are validated today so if you sign the responses will be checked. Unfortunately most to those validations still result in insecure instead of secure because people are not signing their zones. > BTW, the stratum-0 source you suggested is known to have been manipulated in > the past (https://www.gps.gov/systems/gps/modernization/sa/), so you need to > bet on that specific state actor not returning to old habits. > > OTOH, 4 of the 5 servers I suggested have their own atomic clock, and you can > keep using GPS as well. If GPS goes bananas on timing, that source will just > be disregarded (one of the features of the NTP architecture that has been > pointed out over and over in this thread and you keep ignoring it). > > Rubens -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: New addresses for b.root-servers.net
Which you can do with DNSSEC but the key management will be enormous. -- Mark Andrews > On 21 Jun 2023, at 15:39, Masataka Ohta > wrote: > > Matt Corallo wrote: > >>> As PKI, including DNSSEC, is subject to MitM attacks, is >>> not cryptographically secure, does not provide end to end >>> security and is not actually workable, why do you bother? >> It sounds like you think nothing is workable, we simply cannot make anything >> secure > > If an end and another end directly share a secret > key without involving untrustworthy trusted third > parties, the ends are secure end to end. > >> - if we should give up on WebPKI (and all its faults) and DNSSEC (and all >> its faults) and RPKI (and all its faults), what do we have left? > > An untrustworthy but light weight and inexpensive (or free) > PKI may worth its price and may be useful to make IP address > based security a little better. > >Masataka Ohta >
Re: FCC Chair Rosenworcel Proposes to Investigate Impact of Data Caps
will he does have big ambitions. >>>>> >>>>> From my standpoint, they don't have to completely replace the >> incumbents. I'd be perfectly happy just keeping them honest. >>>>> >>>>> As I mentioned elsewhere, I'm not sure that the current economics are >> the real economics. I'm pretty sure they've been purposefully throttling >> demand because they still don't have the capacity so it would make sense to >> overcharge in the mean time. Is there something inherent in their cpe that >> makes them much more expensive than, say, satellite tv dishes? I can see >> marginally more because of the LEO aspect, but isn't that mainly just >> software? It wouldn't surprise me that the main cost is the truck roll. >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> On Fri, Jun 16, 2023 at 4:17˙˙PM Michael Thomas wrote: >>>>>> >>>>>> >>>>>> On 6/16/23 1:09 PM, Mark Tinka wrote: >>>>>>> >>>>>>> >>>>>>> On 6/16/23 21:19, Josh Luthman wrote: >>>>>>>> Mark, >>>>>>>> >>>>>>>> In my world I constantly see people with 0 fixed internet options. >>>>>>>> Many of these locations do not even have mobile coverage. >>>>>>>> Competition is fine in town, but for millions of people in the US >>>>>>>> (and I'm going to assume it's worse or comparable in CA/MX) there >> is >>>>>>>> no service. >>>>>>>> >>>>>>>> As a company primarily delivering to residents, competition is not >> a >>>>>>>> focus for us and for the urban market it's tough to survive on a >> ~1/3 >>>>>>>> take rate. >>>>>>> >>>>>>> I should have been clearer... the lack of competition in many >> markets >>>>>>> is not unique to North America. I'd say all of the world suffers >> that, >>>>>>> since there is only so much money and resources to go around. >>>>>>> >>>>>>> What I was trying to say is that should a town or village have the >>>>>>> opportunity to receive competition, where existing services are >>>>>>> capped, uncapping that via an alternative provider would be low >>>>>>> hanging fruit to gain local marketshare. Of course, the alternative >>>>>>> provider would need to show up first, but that's a whole other >> thread. >>>>>>> >>>>>> Won't Starlink and other LEO configurations be that backstop sooner >>>>>> rather than later? I don't know if they have caps as well, but even if >>>>>> they do they could compete with their caps. >>>>>> >>>>>> Mike >>>>>> >> >> >> -- >> Podcast: >> https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/ >> Dave Täht CSO, LibreQos >> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: New addresses for b.root-servers.net
> On 9 Jun 2023, at 14:29, Masataka Ohta > wrote: > > Robert Story wrote: > >> The commitment to maintain service for 1 year after the new LACNIC >> addresses are switched in to the root.hints from IANA does not mean that >> this is a cutoff date and that we intend to turn off service on the >> older addresses after a year. We currently have no plans to do so for >> the foreseeable future. In fact, the possibility has not even been >> suggested or discussed at all. > > Such total lack of advance and public discussion and preparation > on a substantial change on critical infrastructure is a serious > problem, I'm afraid. > > Masataka Ohta I’m curious about what more discussion you want to happen than has happen in the past. Over the last 20 years there have been lots of address changes. None of them have caused operational problems. None required more that has already happened for this change. Mark 4781. [maint] B.ROOT-SERVERS.NET is now 199.9.14.201. [RT #45889] 4633. [maint] Updated (2001:500:200::b) for B.ROOT-SERVERS.NET. 4490. [maint] Added (2001:500:12::d0d) for G.ROOT-SERVERS.NET. 4457. [maint] Added (2001:500:a8::e) for E.ROOT-SERVERS.NET. 4423. [maint] Added missing IPv6 address 2001:500:84::b for B.ROOT-SERVERS.NET. [RT #42898] 4333. [maint] L.ROOT-SERVERS.NET is now 199.7.83.42 and 2001:500:9f::42. 4261. [maint] H.ROOT-SERVERS.NET is 198.97.190.53 and 2001:500:1::53. [RT #40556] 3794. [maint] Added for C.ROOT-SERVERS.NET. 3556. [maint] Added for D.ROOT-SERVERS.NET. 3441. [maint] D.ROOT-SERVERS.NET is now 199.7.91.13. 2918. [maint] Add address for I.ROOT-SERVERS.NET. 2870. [maint] Add address for L.ROOT-SERVERS.NET. 2328. [maint] Add addresses for A.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, J.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET. 2255. [maint] L.ROOT-SERVERS.NET is now 199.7.83.42. 1567. [maint] B.ROOT-SERVERS.NET is now 192.228.79.201. 1397. [maint] J.ROOT-SERVERS.NET is now 192.58.128.30. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: webex.com DNS Contact - Possibly Broken DNSSEC?
There is nothing to worry about here. There is an insecure delegation at webex.com (no DS RRset). Named does bottom up validation (follows the RRSIG signer names) then does to down to prove insecure if that fails. The messages are logged during the first stage. > On 9 May 2023, at 23:33, Reuben Farrelly via NANOG wrote: > > Does anyone know of a contact of someone (presumably at Webex/Cisco) who can > take a look at the DNS for webex.com? > > It has been for some time now, logging a lot of DNSSEC warnings on my > resolver: > > dnssec: validating > external-media75.public.wnrtm-a-2.prod.infra.webex.com/NSEC: no valid > signature found: 1 Time(s) > dnssec: validating > external-media75.public.wsinm-a-3.prod.infra.webex.com/NSEC: no valid > signature found: 1 Time(s) > dnssec: validating > external-media78.public.wbomm-a-2.prod.infra.webex.com/NSEC: no valid > signature found: 1 Time(s) > dnssec: validating > external-media8.public.wnrtm-a-2.prod.infra.webex.com/NSEC: no valid > signature found: 1 Time(s) > > (and a whole lot more hostnames in the same domain). Some basic DNSSec > analysis indicates something in the middle of the trust chain is broken: > > https://dnssec-analyzer.verisignlabs.com/external-media26.public.wjfkm-a-3.prod.infra.webex.com > > It looks to me like the subdomains have DS records but the other parts of the > subdomain don't and I guess there's no point in having DS records on host > records, if the parent domain doesn't have them too. > > I wouldn't bother if it was one or two entries, but it looks like the whole > domain is affected and this probably is a fairly widely utilised domain. > > Thanks, > Reuben > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS resolution for hhs.gov
wever dig +trace cms.hhs.gov <http://cms.hhs.gov> resolves and so does > > That makes sense, delegated sub zone. :) > >> dig +trace eclkc.ohs.acf.hhs.gov <http://eclkc.ohs.acf.hhs.gov> > > No delegated sub zones in the path here, so the hhs.gov name servers are > authoritative for this host. > >> However if I simply ask my local resolver to resolve cob.cms.hhs.gov >> <http://cob.cms.hhs.gov>, it works. Any thoughts on why this is the case? > > Because it's getting the answer from the child zone (cms) like it should. > > I'm sort of curious about what `dig +trace` results you received originally > that made you believe that you weren't getting the right response. Are you > currently seeing what you expect to see? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Your DNS Servers are not working correctly.
I work for a DNS vendor and saw reports about DNS resolution errors when looking up names under dhhs.gov. It looks like your servers are not returning non-existence answers over UDP which breaks servers that are trying to do DNS QNAME minimisation (See RFC 7816). Below are three queries that the servers should be capable of answering if they are following the DNS protocol correctly. dhhs.gov is answered but foobar.dhhs.gov doesn’t return anything and I would expect a NXDOMAIN (Name Error) response. Additionally 355.dhhs.gov should be returning a NODATA/NOERROR response at a minimum as it part of your DNS servers names. If I ask the same questions over TCP instead of UDP I get answers. This really smells like a misconfigured firewall. Mark % dig dhhs.gov @158.74.30.99 ; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.99 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59012 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 7b8cd5530b5fa45190ac7ac264364fe858d1f83093c6da62 (good) ;; QUESTION SECTION: ;dhhs.gov. IN A ;; ANSWER SECTION: dhhs.gov. 9000 IN A 52.7.111.176 ;; Query time: 243 msec ;; SERVER: 158.74.30.99#53(158.74.30.99) (UDP) ;; WHEN: Wed Apr 12 16:30:00 AEST 2023 ;; MSG SIZE rcvd: 81 % dig foobar.dhhs.gov @158.74.30.99 ;; communications error to 158.74.30.99#53: timed out ;; communications error to 158.74.30.99#53: timed out ;; communications error to 158.74.30.99#53: timed out ; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.99 ;; global options: +cmd ;; no servers could be reached [ant-7641:~/git/bind9] marka% dig 355.dhhs.gov @158.74.30.99 ;; communications error to 158.74.30.99#53: timed out ;; communications error to 158.74.30.99#53: timed out ;; communications error to 158.74.30.99#53: timed out ; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov @158.74.30.99 ;; global options: +cmd ;; no servers could be reached % % dig dhhs.gov @158.74.30.99 +tcp ; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.99 +tcp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18254 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 710a14c38e16a91fd4060d86643652ecca2dce18d21e3144 (good) ;; QUESTION SECTION: ;dhhs.gov. IN A ;; ANSWER SECTION: dhhs.gov. 9000 IN A 52.7.111.176 ;; Query time: 246 msec ;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP) ;; WHEN: Wed Apr 12 16:42:52 AEST 2023 ;; MSG SIZE rcvd: 81 % dig 355.dhhs.gov @158.74.30.99 +tcp ; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov @158.74.30.99 +tcp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56223 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: e10fe6bd8dccc0ed038bbff1643652fb582c8d51b5d3a25c (good) ;; QUESTION SECTION: ;355.dhhs.gov. IN A ;; AUTHORITY SECTION: dhhs.gov. 3600 IN SOA rh120ns1.368.dhhs.gov. hostmaster.psc.hhs.gov. 2023021759 1200 300 2419200 3600 ;; Query time: 246 msec ;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP) ;; WHEN: Wed Apr 12 16:43:07 AEST 2023 ;; MSG SIZE rcvd: 137 % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS resolution for hhs.gov
The nameservers are not answering all in scope questions being sent to the servers. Something is blocking or not generating NXDOMAIN responses. This impacts on QNAME minimisation queries that usually elicit a NXDOMAIN response. This happens irrespective of DNSSEC records being requested so I doubt that it is a fragmentation issue. Both _.dhhs.gov <http://dhhs.gov/> and foobar.dhhs.gov <http://foobar.dhhs.gov/> time out but dhhs.gov <http://dhhs.gov/> itself doesn’t. % dig _.dhhs.gov @158.74.30.103 +dnssec ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ; <<>> DiG 9.19.11-dev <<>> _.dhhs.gov @158.74.30.103 +dnssec ;; global options: +cmd ;; no servers could be reached % dig dhhs.gov @158.74.30.103 +dnssec ; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.103 +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18125 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: d939ecfdb6cd2d902678cca26435eb2dd6fcebd65fe5c58f (good) ;; QUESTION SECTION: ;dhhs.gov. IN A ;; ANSWER SECTION: dhhs.gov. 9000 IN A 52.7.111.176 dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 11710 dhhs.gov. YCEsecATdJEHs3OtxQs/kE2A/37/mzgUpGLzQwrPP9xqaGmBq2mDteKx QyUnh0JuURBq0Qy1htxsOD9kX4dxSxUNCEO7/KHw0AOoIbnh2+GL8kc3 jKB2jkcN+whA9+CqThto020nLSCXcgdm7qOfyNBUFICoYNtVrd7/lLCJ kho= dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 21469 dhhs.gov. OkEdR/ofhV+JogwAkZtLmHyxn3pK2E4zaGUV786kKbtQrI6SzetCk+sC Db3W0LrYRZy1BEqqxZeRnLXVEjyyyKfnYMRPtoP3sCTLPuuDeu8oDmhw eniXLbJ10od6YWywgQDl2bYrTLEt6R8+TGG7up446TGgRk9wOV/uU2Jb d+U= ;; Query time: 308 msec ;; SERVER: 158.74.30.103#53(158.74.30.103) (UDP) ;; WHEN: Wed Apr 12 09:20:13 AEST 2023 ;; MSG SIZE rcvd: 417 % dig foobar.dhhs.gov @158.74.30.103 +dnssec ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103 +dnssec ;; global options: +cmd ;; no servers could be reached % dig foobar.dhhs.gov @158.74.30.103 ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103 ;; global options: +cmd ;; no servers could be reached % > On 12 Apr 2023, at 01:12, Samuel Jackson wrote: > > I wanted to run this by everyone to make sure I am not the one losing my mind > over this. > > A dig +trace cob.cms.hhs.gov fails for me as it looks like the NS for hhs.gov > does not seem to resolve the hostname. > > However dig +trace cms.hhs.gov resolves and so does dig +trace > eclkc.ohs.acf.hhs.gov > > However if I simply ask my local resolver to resolve cob.cms.hhs.gov, it > works. Any thoughts on why this is the case? > > Thanks, > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: 1.1.1.1 support?
What about the zone not having a single point of failure? Both servers are covered by the same /24. % dig www.moi.gov.cy @212.31.118.19 +norec +dnssec ; <<>> DiG 9.19.11-dev <<>> www.moi.gov.cy @212.31.118.19 +norec +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17380 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 6387183a6031ef182fa6ade7641ad4ff2a078213f4e24fc9 (good) ;; QUESTION SECTION: ;www.moi.gov.cy. IN A ;; ANSWER SECTION: www.moi.gov.cy. 3600 IN A 212.31.118.26 ;; AUTHORITY SECTION: moi.gov.cy. 3600 IN NS ns01.gov.cy. moi.gov.cy. 3600 IN NS ns02.gov.cy. ;; ADDITIONAL SECTION: ns02.gov.cy. 86400 IN A 212.31.118.20 ns01.gov.cy. 86400 IN A 212.31.118.19 ;; Query time: 374 msec ;; SERVER: 212.31.118.19#53(212.31.118.19) (UDP) ;; WHEN: Wed Mar 22 21:14:23 AEDT 2023 ;; MSG SIZE rcvd: 157 % > On 22 Mar 2023, at 19:36, Saku Ytti wrote: > > Am I correct to understand that 1.1.1.1 only does support via community forum? > > They had just enough interest in the service to collect user data to > monetise, but 0 interest in trying to figure out how to detect and > solve problems? > > Why not build a web form where they ask you to explain what is not > working, in terms of automatically testable. Like no A record for X. > Then after you submit this form, they test against all 1.1.1.1 and > some 9.9.9.9 and 8.8.8.8 and if they find a difference in behaviour, > the ticket is accepted and sent to someone who understands DNS? If > there is no difference in behaviour, direct people to community > forums. > This trivial, cheap and fast to produce support channel would ensure > virtually 0 trash support cases, so you wouldn't even have to hire > people to support your data collection enterprise. The number of times that 8.8.8.8 “works” but there is an actual error is enormous. 8.8.8.8 tolerates lots of protocol errors which ends up causing support cases for others where the result is “the servers are broken in this way”. You then try to report the issue but the report is ignored because “It works with 8.8.8.8”. > Very obviously they selfishly had no interest in ensuring 1.1.1.1 > actually works, as long as they are getting the data. I do not know > how to characterise this as anything but unethical. > > https://community.cloudflare.com/t/1-1-1-1-wont-resolve-www-moi-gov-cy-in-lca-235m3/487469 > https://community.cloudflare.com/t/1-1-1-1-failing-to-resolve/474228 > > If you can't due to resources or competence support DNS, do not offer one. > > -- > ++ytti, cake having and cake eating user -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)
> On 9 Mar 2023, at 08:41, William Herrin wrote: > > On Wed, Mar 8, 2023 at 4:35 AM Lukas Tribus wrote: >> Perhaps I should have started this topic with a very specific example: >> >> - ISP A has a residential customer "Bob" in RFC6598 space >> - ISP A CGNATs Bob if the destination is beyond it's own IP space >> - ISP A doesn't CGNAT if the destination is within its IP space (as >> explained in the OP, this means reducing state and logging) >> - ISP A has a cloud customer "Alice" running mail/webservers, which is >> of course using public IP address space >> - when Bob access Alice's mail/webserver, the source IP will show >> RFC6598 addressing >> - if Alice filters RFC6598, Bob can't connect >> - Alice should not drop RFC6598, it should threat RFC6598 just like >> every other public IP subnet >> - only ISPs (which Alice is not) should drop RFC6598 on its network borders >> >> RFC6598 filters belong on network borders to other autonomous systems, >> not in a datacenter on a mail/webserver. > > Hi Lukas, > > Thanks for the clarification. As others have said: the error lies in > the base conditions of your reasoning, not team-cyrmu's bogon list. > > The bogon list is designed to be used unmodified at one particular > kind of location only: the BGP-speaking link between two different > Autonomous Systems. Anywhere else you might choose to use it, you must > first exclude or override the filtering for locally used addresses. > > Perhaps the folks maintaining the bogon list can document the need to > exclude locally used addresses when employing it elsewhere, and that > for the purposes of the bogons list, "local" includes your immediate > ISP. I can see how the latter part of that might not be completely > obvious. > > > Regarding the specific example, I'm dubious that ISP A should be > presenting Alice with Bob's un-natted 100.64/10 address. The RFC does > allow ISP A to use the address space that way, but there have been > several discussions here and in the groups where the RFC was first > envisioned and debated to the effect that the ISP sending traffic to a > customer with source addresses in 100.64/10 would be unwise due to the > possibility of overlap and/or filtering issues. > > The more common example in these debates was ISP A using a 100.64/10 > address for a DNS resolver or smtp relay intended to be used by only > the downstream customers. The issue with using the addresses that way > was that if the downstream customer had more than one ISP, it would be > unable to differentiate between ISPs for 100.64/10 destinations. > > Regards, > Bill Herrin > -- > For hire. https://bill.herrin.us/resume/ Correct, you can’t use 100.64/10 for any service expected to be reached by customers. CPE shouldn’t see traffic from 100.64/10 with the possible exception of ICMP ERROR messages. Even advertising a 100.64/10 address as next hop is problematic for dual homing CPE. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: the ipv4 vs ipv6 growth debate
If you really want to know if a site works over IPv6 you have to flush any cached pages and turn off IPv4. You also need to be using a IPv6 only nameserver. Only after doing those extra steps can you say a site is IPv6 ready. I’ve had pages that appeared to be all IPv6 fail after doing these extra steps. As for connection racing IPv6 wins 99.99% of the time. There is enough bias that it will win unless there is a lossy path involved. -- Mark Andrews > On 6 Dec 2022, at 06:02, Tom Beecher wrote: > > > But IPv6Foo , ast least as far as I could tell by quickly looking at the > code, cannot tell you if an IPv6 connection WOULD have worked, but IPv4 is > where it ended up. > > With Happy Eyeballs, if the IPv4 TCP session finishes up only a couple ms > faster than the IPv6 ones, the v4 one wins out. That doesn't give you any > meaningful signal as to WHY it landed on IPv4 instead. > >> On Mon, Dec 5, 2022 at 12:32 PM Jorge Amodio wrote: >> >> With IPv6Foo you can click on the icon and it will show you a table listing >> what URLs are serving some piece of a given page with v6 and v4. >> >> LinkedIn for example shows the main feed page served via v6 but there are a >> couple of pieces with v4 from these sites >> >> - dpm.demdex.net >> - lnkd.demdex.net >> - p.adsymptotic.com >> - radar.cedexis.com >> - sb.scorecardresearch.com >> - trkn.us >> >> Some may be feeding ads content, others tracking, market research, etc. >> >> Regards >> Jorge >> >>> On Mon, Dec 5, 2022 at 11:09 AM Tom Beecher wrote: >>> Often lost in the 'debate' about V6 adoption is that for a 100% native IPv6 >>> experience to work, there are multiple other components that have nothing >>> to do with the network that ALSO have to work correctly. Any issues with >>> these are likely going to cause fallback to v4. >>> >>> It's very difficult to know how much v4 traffic to a website COULD have >>> worked just fine on v6, but didn't, and why it didn't. >>> >>>> On Sat, Dec 3, 2022 at 7:16 PM Matt Corallo wrote: >>>> It would be nice if IPvFoo showed the bytes and connection/request count. >>>> It's going to be a >>>> loonnggg time before we can do consumer internet browsing with no v4, >>>> until then it's about reducing >>>> cost of CGNAT with reduced packets/connections. >>>> >>>> For twitter, the main site is v4, yea, but abs.twimg.net (Edgecast) and >>>> pbs.twimg.net (Fastly) make >>>> up the vast majority of the bytes fetched on the site for me and are both >>>> v6 now. I don't recall >>>> when I last checked but they were still v4-only not too long ago. >>>> >>>> The other end of it is v6-only servers that don't accept inbound >>>> connections. Thos have been >>>> hampered IME by github not serving git over v6. Supposedly it's coming >>>> soon but so much modern >>>> software fetches stuff from Github that that's a major blocker. >>>> >>>> Matt >>>> >>>> On 11/27/22 7:44 PM, Jorge Amodio wrote: >>>> > >>>> > I use the same extension on Chrome. >>>> > >>>> > I'm surprised that with all the recent hoopla about it, from the major >>>> > social media platforms, >>>> > Twitter still shows serving their http site over IPv4, Facebook and >>>> > LinkedIn show solid IPv6. >>>> > >>>> > -J >>>> > >>>> > >>>> > On Sun, Nov 27, 2022 at 9:29 PM Dave Taht >>> > <mailto:dave.t...@gmail.com>> wrote: >>>> > >>>> > I use a web plugin tool called ipvfoo to track my actual ipv4 vis >>>> > ipv6 >>>> > usage. I wish it worked over time. With very few exceptions I am >>>> > still >>>> > regularly calling ipv4 addresses in most webpages. Has anyone done a >>>> > more organized study of say, the top 1 million, and how many still >>>> > require at least some ipv4 to exist, and those trends over time? >>>> > >>>> > -- >>>> > This song goes out to all the folk that thought Stadia would work: >>>> > >>>> > https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz >>>> > >>>> > <https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz> >>>> > Dave Täht CEO, TekLibre, LLC >>>> >
Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC
ster. During my first > employment, we had the need to optimize circuit designs. Since I was the only > staff who knew about it, I ended up being the coordinator between several > hardware designers and the supporting programmer. From that teaching, I am > always looking for the most concise solution to an issue, not being > distracted or discouraged by the manifestation on the surface. > > https://en.wikipedia.org/wiki/APL_(programming_language) > > 3) Fast forward half a century, I am hoping that my "one-line code" serves > the purpose of "there exists" an example in proofing a mathematical theorem > for inspiring software colleagues to review the network codes in front of > them for improvement, instead of presenting such as a valid hurdle to > progress. > > > Regards, > > > Abe (2022-11-24 03:53 EST) > > > > > > On 2022-11-21 19:30, Joe Maimon wrote: >> >> >> David Conrad wrote: >>> Barry, >>> >>> On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote: >>>> We've been trying to get people to adopt IPv6 widely for 30 years with >>>> very limited success >>> >>> According to https://www.google.com/intl/en/ipv6/statistics.html, it looks >>> like we’ve gone from ~0% to ~40% in 12 years. >>> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet >>> population of about 5B, this can (simplistically and wrongly) argued to >>> mean 1.5-2B people are using IPv6. For a transition to a technology that >>> the vast majority of people who pay the bills will neither notice nor care >>> about, and for which the business case typically needs projection way past >>> the normal quarterly focus of shareholders, that seems pretty successful to >>> me. >>> >>> But back to the latest proposal to rearrange deck chairs on the IPv4 >>> Titanic, the fundamental and obvious flaw is the assertion of "commenting >>> out one line code”. There isn’t “one line of code”. There are literally >>> _billions_ of instances of “one line of code”, the vast majority of which >>> need to be changed/deployed/tested with absolutely no business case to do >>> so that isn’t better met with deploying IPv6+IPv4aaS. I believe this has >>> been pointed out numerous times, but it falls on deaf ears, so the >>> discussion gets a bit tedious. >>> >>> Regards, >>> -drc >>> >> Had the titanic stayed afloat some hours more, many more would have survived >> and been rescued when assistance eventually arrived. So that makes this a >> debate over whether this is deck chair re-arrangement or something more >> meaningful. >> >> As I and others have pointed out, it depends on how it is used. And perhaps >> the attempt should be made regardless of knowing in advance which it will be. >> >> You assertion needs some back of the envelope numbers, which once provided, >> I suspect will render your estimate grossly incorrect. >> >> You can hardly attempt to convince anybody that 240/4 as unicast would not >> be the more trivial change made in any of these products natural life cycle >> points. >> >> Especially as we have examples of what that type of effort might look like. >> IGTFY and here >> >> https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/ >> >> The burdensome position is ridiculous even more so when stated with a >> straight face. >> >> Joe >> >> >> > > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: V6 still not supported
There is also Customer contacts ACCC in Australia and complains that Sony is not supplying a working product and Sony gets fined and instructed to change their rules about customers behind CGNATs. > On 7 Apr 2022, at 03:24, Jared Brown wrote: > > Owen DeLong via NANOG wrote: >>> I would expect the trend to become that ISP's refuse to accommodate 3rd >>> party vendors shenanigans to the point where it hampers their operations or >>> to the point where it cost them more to do so. >> >> $ISP_1 refuses to accommodate Sony’s shenanigans… >> Three possible outcomes: > The three possible outcomes assume status quo is maintained. > > However, if ISP A makes a business decision to not accommodate 3rd party > shenanigans and modifies policies accordingly, then we have a new equilibrium. > > Outcome 1 is maintained: Customer churns off ISP A. Everybody wins. > > Outcome 2 is no longer a single outcome, but rather several: > a. Customer is upsold to gaming package which includes a static IP. > b. Customer returns Playstation and buys Xbox instead. > c. Customer declines gaming package, but continues to bother customer > service. Customer is directed to 3rd party customer support. Further customer > contact is handled via self service portals and other low cost customer > service channels. > d. Customer terminates contract and goes offline. > > Outcome 3 is resolved by ISP A telling returning customers that service at > that address is only available if ordered together with the gaming package. > >> All of this, of course, becomes an effective non-issue if both $ISP and Sony >> deploy IPv6 and get rid of the stupid NAT tricks. > Well yes... > > ... but why would Sony do that when they have so conveniently externalized > all costs? > > > - Jared -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Only
You have to try running IPv6 only occasionally to weed out the dependencies.
You can do this on a per node basis. Just turn off the IPv4 interface and see
how you run. I do this periodically on my Mac and disable IPv4. This also
makes my recursive nameserver IPv6 only as well. You then see what breaks like
sites where one of the cdn’s is IPv4 only despite the page itself being
reachable over IPv6. Or the nameservers are not reachable over IPv6.
Write down what you find is broken and report it.
--
Mark Andrews
> On 1 Apr 2022, at 05:53, Matthew Petach wrote:
>
>
>
>
>> On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour
>> wrote:
>> Exactly what I was asking, when and how will we collectively turn off the
>> lights on IPv4?
>
> Working on the World IPv6 Launch {day|week|forever} efforts,
> I noticed an interesting pattern of companies that put up IPv6
> resources, with all the associated quad-As, and patted themselves
> on the back for making themselves available via IPv6; but I couldn't
> request those quad-A records via anything but IPv4 transport to their
> DNS servers.
>
> I've seen similar behaviour with hardware vendors. They have great
> IPv6 support, their boxes forward and accept IPv6 packets just fine;
> but, the deeper you dig, the more you find oddities, like syslog host
> destinations that only accept v4 IP addresses, or a requirement for
> an IPv4 router ID to be configured.
>
> I don't think we fully grasp just how wide the chasm is between
> "we support IPv6" and "we can fully turn off IPv4".
>
> There's a whole lot of "we support IPv6" in the world right now that
> comes with lingering IPv4 tendrils that are often under the surface,
> or in the darker corners of the config, that just keep working because
> most of the IPv6 world is still either dual-stacked, or has a translation
> layer that allows the lurking v4 bits to not cause issues.
>
> I don't think we'll be nearly as close to being ready to turn off the lights
> on IPv4 as we think we are, not just because of old customer CPE and
> legacy boxes, but because of embedded assumptions deep in software
> and firmware stacks. For example, let's take a relatively modern
> enterprise wireless platform:
>
> https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/Chp_ZTP/ztp-sup-aos-cx-10.htm
> "
> ZTP operations are supported over IPv4 connections only. IPv6 connections are
> not supported for ZTP operations."
> Sure, the devices pass IPv6 traffic just fine; but you'd better keep your
> IPv4
> network around so the devices can configure themselves after powering on.
>
> There's a *lot* of code out there that's been carried forward for years,
> with dark corners that haven't been touched for a while. I think we're
> going to be stumbling over "can't do that over IPv6 yet" areas for years
> and years to come, not because of any willful myopia around the migration
> from IPv4 to IPv6, but simply because it's code that doesn't get used very
> often, and in dual-stack networks, it just keeps working the few times it
> gets exercised. The only time it would run into a problem is in a pure
> IPv6-only network; and how many of those really exist in the world to
> flag it as an issue?
>
> And yet, in order to "turn off the lights on IPv4", we're going to have to
> root through all those dark corners of code that haven't been touched
> in years to update them to work in an IPv6-only world; and that's *really*
> pushing the rock uphill, because that's work that isn't going to see any
> cost recovery for it at all. No customer is going to say "I won't buy your
> product until you've rooted out every bit of IPv4-only code in your software".
> So, there's really no financial incentive for companies to work towards
> getting their software ready for an IPv6-only world.
>
> So--the tl;dr version of my answer to you?
> "when" is likely to be "not in any of our lifetimes"--because the "how"
> requires completely non-monetizable effort on the part of companies
> that have legacy codebases they're carrying forward.
>
> Thanks!
>
> Matt
>
>
Re: A straightforward transition plan (was: Re: V6 still not supported)
> On 26 Mar 2022, at 21:51, Philip Homburg wrote: > >>> If there is a magical transition technology that allows an IPv6-only host t >> o >>> talk to an IPv4-only host, then let's deploy it. >> >> DNS64/NAT64, DS-Lite, 6rd, 464XLAT, MAP-T, MAP-E, ? pick a transition >> protocol and see what happens! (with more coming every year...) > > The problem with these is that they are not full solutions. That's why we > get new ones every year: everybody picks the subset of the problem they > want solve. > > To go over the ones you listed: > - 6rd. That's the odd one out here. 6rd privdes IPv6 over an IPv4 > infrastructure. Very useful when there was not a lot of IPv6 native. Not a > good approach for organisations that lack IPv4 addresses. Also not a good > approach if you want to switch off IPv4 at some point. > - DS-Lite, MAP-T, MAP-E. Good for connecting CPEs to IPv4aaS over an IPv6-only > backbone. Downstream from the CPE is dual stack. For this reason those > protocols do not see much use outside ISP networks. Got a great transition > technology because hosts will keep IPv4 until the last IPv4 on > the internet is gone. It is a bit of an IETF failure that we have so > many ways to connect a CPE to IPv4aaS. > - NAT64/DNS64. This is the closest to an actual transition technology. > Unfortunately it is completely flawed in too many ways. > - 464XLAT fixes many issues with NAT64/DNS64. The downside is again that > hosts have to have an IPv4 stack until forever and in addition to that > a complex IPv4-to-IPv6 translation module. That fails the requirement > that an IPv6 stack should have roughly the same complexity as IPv4 and > talk to IPv4-only. > > Basically, there is no solution to the transition problem. There are > lots of partial solutions, each with their own advantages and disadvantages. > > If we could go back in time, then developing NAT64 along with IPv6 and > making sure the translation really works including edge cases like IPv4 > literals, DNS A records, NAT traversal, etc. would have made a > difference. > > I don't know if such translation gateways were considered, I can't recall > much discussion about them. By the time the IPv6 socket API was created > it was already too late to get things like IPv4 literals right. DS-Lite was designed to be implemented in the node. You can run IPv6-only everywhere in your network. It is simple IPv4 in IPv6 encapsulation. There was a DHCPv6 option to tell the node how to configure the remote IPv6 tunnel end point and everything else had defaults. You could implement this in stack that only presented IPv6 to the application using IPv4 mapped address. You use getaddrinfo with AI_V4MAPPED set for domain names and address literals which should preference IPv6 over mapped IPv4 moving the traffic to IPv6. Yes, you still have a stub IPv4 implementation. All this was available before DNS64/NAT64, MAP-E, MAP-T, and 464XLAT. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
Sites looking at the traffic they get and saying, you know what all our customers connect to us over IPv6 with some of them also connecting over IPv4. I think we can stop supporting IPv4 now. ISP’s saying this IPv4aaS isn’t getting much traffic anymore lets out source it for the few customers that are still using it. Lots of ISPs are well down the path leading to this point by turning off IPv4 on the access networks. Home / enterprise networks. All my gear is IPv6 capable and supports IPv4aaS for the few legacy IPv4 sites I need to connect to. This is happening today. In the end almost all the IPv4 traffic with be with the third party IPv4aaS providers and collectively they will decide to turn off the lights. > On 30 Mar 2022, at 07:53, Jacques Latour wrote: > > So, in 25, 50 or 100 years from now, are we still going to be dual stack > IPv4/IPv6? > When are we going to give up on IPv4? > People can run IPv4 all they want inside their networks for 1000s of years. > What will it take to be IPv6 only? > > > > From: NANOG On Behalf Of > Owen DeLong via NANOG > Sent: March 29, 2022 3:52 PM > To: Abraham Y. Chen > Cc: NANOG > Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported > re: 202203261833.AYC > > Submit an Internet draft, same as any other IP related enhancement gets > introduced. > > What you’re really complaining about is that it’s been virtually impossible > to gain consensus to move anything IPv4 related forward in the IETF since at > least 2015. > > Well… It’s a consensus process. If your idea isn’t getting consensus, then > perhaps it’s simply that the group you are seeking consensus from doesn’t > like your idea. > > Your inability to convince the members of the various working groups that > your idea has merit isn’t necessarily a defect in the IETF process… It might > simply be a lack of merit in your ideas. > > Owen > > > > On Mar 26, 2022, at 15:43 , Abraham Y. Chen wrote: > > Hi, Justin: > > 1)"... no one is stopping anyone from working on IPv4 ... ": After > all these discussions, are you still denying this basic issue? For example, > there has not been any straightforward way to introduce IPv4 enhancement > ideas to IETF since at least 2015. If you know the way, please make it > public. I am sure that many are eager to learn about it. Thanks. > > Regards, > > > Abe (2022-03-26 18:42) > > > > > On 2022-03-26 11:20, Justin Streiner wrote: > While the Internet is intended to allow the free exchange of information, the > means of getting that information from place to place is and has to be > defined by protocols that are implemented in a consistent manner (see: BGP, > among many other examples). It's important to separate the ideas from the > plumbing. > > That said, no one is stopping anyone from working on IPv4, so what personal > freedoms are being impacted by working toward deploying IPv6, with an eye > toward sunsetting IPv4 in the future? > > Keep in mind that IPv4 started out as an experiment that found its way into > wider use. It's a classic case of a test deployment that suddenly mutated > into a production service. Why should we continue to expend effort to > perpetuate the sins of the past, rather work toward getting v6 into wider use? > > Is IPv6 a perfect protocol? Absolutely not, but it addresses the key pain > point of IPv4 - address space exhaustion. > > Thank you > jms > > On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen wrote: > > 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic > baseline that we need to sort out, first. That is, we must keep in mind that > the Internet community strongly promotes "personal freedom". Assuming that by > stopping others from working on IPv4 will shift their energy to IPv6 is > totally contradicting such a principle. A project attracts contributors by > its own merits, not by relying on artificial barriers to the competitions. > Based on my best understanding, IPv6 failed right after the decision of "not > emphasizing the backward compatibility with IPv4". It broke one of the golden > rules in the system engineering discipline. After nearly three decades, still > evading such fact, but defusing IPv6 issues by various tactics is the real > impedance to progress, not only to IPv4 but also to IPv6. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Not Making Use of 240/4 NetBlock
It’s a business problem for the RIR’s. Selling / leasing known defective products is against lots of consumer law. -- Mark Andrews > On 17 Mar 2022, at 03:43, Owen DeLong wrote: > > > >>> On Mar 15, 2022, at 19:23 , Mark Andrews wrote: >>> >>> >>> >>>> On 16 Mar 2022, at 02:54, Owen DeLong via NANOG wrote: >>> >>> Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able >>> to claim some detailed knowledge on the subject. >>> >>> In general, the RIRs themselves maintain neutrality about such things, >>> looking to their >>> respective communities for input on what to do. However, so long as the >>> IETF and >>> has not designated the space Unicast Address Space to be delegated to the >>> RIRs for allocation/assignment, IANA will not delegate it to the RIRs and >>> the RIRs >>> won’t, therefore, delegate it to users. >>> >>> If you really want to see this happen (and I still argue that the amount of >>> effort already wasted >>> discussing this idea vastly exceeds what would be needed towards IPv6 to >>> get beyond >>> caring about it), then the first step must be to convince the IETF to >>> designate the >>> space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the >>> RIRs. >>> >>> Once that happens, the rest of the allocation process is basically >>> automatic. From a policy >>> perspective at the RIR level, it will be no different than say 4/8 or 1/8. >> >> Actually it would be fundamentally different to 4/8 or 1/8. You are looking >> at firmware upgrades >> rather than dealing with squatters and out-of-date ACLs both of which are >> self-inflicted by one >> of the parties. Routers and end devices that don’t know how to hand 240/4 >> are no self inflicted >> injuries. Issuing 4/8 or 1/8 worked for parties that had been following the >> rules. With 240/4 >> there where no rules to follow which results in RIR’s leasing known >> defective addresses. > > I was speaking from an RIR allocation perspective, NOT talking about the > technological hurdles > to implementation. > > I was specifically responding to someone’s question about how the RIRs would > be impacted by > this if it were to come to pass. > > I addressed your concern in the following paragraph as an aside, however. > >> >>> Now, convincing vendors to update their firmware, software, etc. is another >>> matter >>> and entirely outside of the control of the RIRs. Merchant compliance with >>> IETF standards >>> is generally considered useful, but it is entirely voluntary and even in >>> the best of >>> circumstances doesn’t every happen instantaneously and almost always >>> involves >>> some stumbles along the way. >>> >>> Owen >>> >>> >>>> On Mar 15, 2022, at 02:54 , Sylvain Baya wrote: >>>> >>>> Dear NANOG-ers, >>>> Hope this email finds you in good health! >>>> Please see my comments below, inline... >>>> >>>> Le mardi 15 mars 2022, a écrit : >>>> >>>> >>>> Hi Barry, >>>> Thanks for your email, brother! >>>> >>>> >>>> But the RIRs are the ones fielding requests for IPv4 space, and have >>>> some notion of how policy implementation might work in practice, so >>>> should have a lot of useful input. >>>> >>>> >>>> ...of course, it appears that RIRs have the opportunity >>>> to add their useful inputs, as Impact Analysis Report >>>> (IAR); during the Policy Development Process (PDP) >>>> initiated by the *appropriate* [1] Internet community. >>>> They explain it themselves here [2]. >>>> __ >>>> [1]: <https://tools.ietf.org/html/rfc7020> >>>> [2]: <https://www.nro.net/accountability/rir-accountability/q-and-a/> >>>> >>>> Shalom, >>>> --sb. >>>> >>>> >>>> On March 14, 2022 at 00:45 niels=na...@bakker.net (Niels Bakker) wrote: >>>>> * b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]: >>>>>> Personally I'd rather hear from the RIRs regarding the value or not >>>>>> of making more IPv4 space such as 240/4 available. They're on the >>>>>> front lines of this. >>>>
Re: Not Making Use of 240/4 NetBlock
> On 16 Mar 2022, at 02:54, Owen DeLong via NANOG wrote: > > Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able > to claim some detailed knowledge on the subject. > > In general, the RIRs themselves maintain neutrality about such things, > looking to their > respective communities for input on what to do. However, so long as the IETF > and > has not designated the space Unicast Address Space to be delegated to the > RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the > RIRs > won’t, therefore, delegate it to users. > > If you really want to see this happen (and I still argue that the amount of > effort already wasted > discussing this idea vastly exceeds what would be needed towards IPv6 to get > beyond > caring about it), then the first step must be to convince the IETF to > designate the > space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the > RIRs. > > Once that happens, the rest of the allocation process is basically automatic. > From a policy > perspective at the RIR level, it will be no different than say 4/8 or 1/8. Actually it would be fundamentally different to 4/8 or 1/8. You are looking at firmware upgrades rather than dealing with squatters and out-of-date ACLs both of which are self-inflicted by one of the parties. Routers and end devices that don’t know how to hand 240/4 are no self inflicted injuries. Issuing 4/8 or 1/8 worked for parties that had been following the rules. With 240/4 there where no rules to follow which results in RIR’s leasing known defective addresses. > Now, convincing vendors to update their firmware, software, etc. is another > matter > and entirely outside of the control of the RIRs. Merchant compliance with > IETF standards > is generally considered useful, but it is entirely voluntary and even in the > best of > circumstances doesn’t every happen instantaneously and almost always involves > some stumbles along the way. > > Owen > > >> On Mar 15, 2022, at 02:54 , Sylvain Baya wrote: >> >> Dear NANOG-ers, >> Hope this email finds you in good health! >> Please see my comments below, inline... >> >> Le mardi 15 mars 2022, a écrit : >> >> >> Hi Barry, >> Thanks for your email, brother! >> >> >> But the RIRs are the ones fielding requests for IPv4 space, and have >> some notion of how policy implementation might work in practice, so >> should have a lot of useful input. >> >> >> ...of course, it appears that RIRs have the opportunity >> to add their useful inputs, as Impact Analysis Report >> (IAR); during the Policy Development Process (PDP) >> initiated by the *appropriate* [1] Internet community. >> They explain it themselves here [2]. >> __ >> [1]: <https://tools.ietf.org/html/rfc7020> >> [2]: <https://www.nro.net/accountability/rir-accountability/q-and-a/> >> >> Shalom, >> --sb. >> >> >> On March 14, 2022 at 00:45 niels=na...@bakker.net (Niels Bakker) wrote: >> > * b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]: >> > >Personally I'd rather hear from the RIRs regarding the value or not >> > >of making more IPv4 space such as 240/4 available. They're on the >> > >front lines of this. >> > >> > You've got your policy development process diagram upside down. The >> > community decides what the RIRs implement. They're not in touch with >> > merchant silicon manufacturers. >> > >> > >> > -- Niels. >> >> -- >> -Barry Shein >> >> Software Tool & Die| b...@theworld.com | >> http://www.TheWorld.com >> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD >> The World: Since 1989 | A Public Information Utility | *oo* >> >> >> -- >> Best Regards ! >> __ >> baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> >> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> >> __ >> #LASAINTEBIBLE|#Romains15:33«Que LE #DIEU de #Paix soit avec vous >> tous! #Amen!» >> #MaPrière est que tu naisses de nouveau. #Chrétiennement >> «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire >> après TOI, ô DIEU!»(#Psaumes42:2) >> >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC
s, >> >> Regards, >> >> >> >> Abe (2022-03-14 14:39) >> >> >> >> >> >> -- >> NANOG Digest, Vol 170, Issue 15 >> Message: 17 >> Date: Sun, 13 Mar 2022 21:26:11 -0700 >> From: Fred Baker >> >> >> To: "Abraham Y. Chen" >> >> , William Herrin >> >> >> >> Cc: NANOG >> >> >> Subject: Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock >> Message-ID: >> <79746dec-8c8b-4d6d-b1d6-cb0a0003a...@gmail.com> >> >> Content-Type: text/plain;charset=us-ascii >> >> On Mar 12, 2022, at 8:15 AM, Abraham Y. Chen >> >> wrote: >> >>> 2)On the other hand, there was a recent APNIC blog that specifically >>> reminded us of a fairly formal request for re-designating the 240/4 >>> netblock back in 2008 (second grey background box). To me, this means >>> whether to change the 240/4 status is not an issue. The question is whether >>> we can identify an application that can maximize its impact. >>> >>> >>> https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/ >>> >>> >> I think there might be value in reviewing the discussion of the related >> Internet Drafts >> >> >> https://datatracker.ietf.org/doc/html/draft-deshpande-intarea-ipaddress-reclassification-03 >> https://mailarchive.ietf.org/arch/search/?q=draft-deshpande-intarea-ipaddress-reclassification >> >> >> >> https://datatracker.ietf.org/doc/html/draft-wilson-class-e-02 >> https://mailarchive.ietf.org/arch/search/?q=draft-wilson-class-e >> >> >> >> https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 >> https://mailarchive.ietf.org/arch/search/?q=draft-fuller-240space >> >> >> The walkaway I had from these discussions was that while changing the >> definition of the address space would allow RIRs to sell more IPv4 address >> space for a few weeks (such as happened to APNIC when the last /8's were >> handed out), there were not enough addresses in the identified pools to >> solve the address shortage. So it was in the end a fool's errand. If you >> want to have address space to address the current shortage, you need an >> addressing architecture with more addresses. >> >> I was there for those discussions, and I'm not sure how to put it more >> simply. >> >> -- >> >> >> Virus-free. www.avast.com > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)
Given the draft lies about the status of 127/8. Words have meanings. When all of 127.0.0.0/8 was reserved for loopback addressing, IPv4 addresses were not yet recognized as scarce. Today, there is no justification for allocating 1/256 of all IPv4 addresses for this purpose, when only one of these addresses is commonly used and only a handful are regularly used at all. Unreserving the majority of these addresses provides a large number of additional IPv4 host addresses for possible use, alleviating some of the pressure of IPv4 address exhaustion. It is not RESERVED, it is ASSIGNED. The class A network number 127 is assigned the "loopback" function, that is, a datagram sent by a higher level protocol to a network 127 address should loop back inside the host. No datagram "sent" to a network 127 address should ever appear on any network anywhere. If it was actually reserved there would be much less complaint. People have made use of that space based on the fact that it was ASSIGNED a purpose whether you like that or feel that it was a good use of resources. Compulsory acquisition is something that should not be done lightly. It also requires fair compensation to be paid. > On 9 Mar 2022, at 13:35, Seth David Schoen wrote: > > John R. Levine writes: > >> This still doesn't mean that screwing around with 240/4 or, an even worse >> 127/8 minus 127/24, is a good idea. > > I hope you'll be slightly mollified to learn that it's actually 127/8 > minus 127/16. > > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-127/ > > That's the most challenging one, but we've still seen something of a > lack of people getting in touch to point out concrete problems. > > One person did get in touch to describe an unofficial use of, apparently, > all of 127/8 as private address space in a VPN product. If people let > us know about more, we can investigate workarounds or possible changes > to our proposals. What’s “unofficial” about it? The point of ASSIGNING 127/8 for loopback meant the ANYONE could use that address space OFFICIALLY so long as packets with those addresses didn’t leave the machine. > We previously thought that the reference NTP implementation was using > all of 127/8 to identify hardware clock drivers. But it turns out it > doesn't actually connect to these. > > If anyone reading this knows of something that uses a loopback address > outside of 127/16 for an application, or something that can't be updated > and would be harmed if the rest of the network stopped treating this as > loopback, we'd be glad to hear about it. What does it matter what people are using those addresses for. They are using them in good faith and are under no obligation to report how they are using them. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Anyone else seeing DNSSEC failures from EU Commission ? (european-union.europa.eu)
> On 10 Dec 2021, at 01:36, Ca By wrote: > > > > On Thu, Dec 9, 2021 at 1:07 AM Arne Jensen wrote: > Den 08-12-2021 kl. 15:32 skrev Niels Bakker: > > * darkde...@darkdevil.dk (Arne Jensen) [Wed 08 Dec 2021, 15:23 CET]: > >> To me, that part of it also points towards a broken implementation at > >> CloudFlare, letting a bogus (insecure) responses take effect anyway. > > > > Or they prefer allowing people to visit websites over punishing system > > administrators for operational failures that less secure (read: > > nonvalidating) ISPs wouldn't inflict on their customers. > I find it hard to believe that CloudFlare would do such though, however, > while such kind of things could indeed be the cause, I'm personally > going towards "Rather safe, than sorry". > > > > It's been quite common for DNSSEC-enabled recursors to add overrides > > for outaged domains in situations like this. > > Unfortunately, yes, overrides are too common for many different things. > Time for them (the overrides) to die completely. > > Or accept that dnssec has always been dead since it never solved a problem, > but created a lot of problems. > > Just saying, facts are on my side. Check the number of times dnssec caused an > outage. Then check the number of hacks prevented by dnssec. Literally 0. How do you know? Unless you investigated every single time DNSSEC validation returned bogus to get to the root cause you cannot know. > Be sure to note the time Netnod got hacked because the perps… turned off > dnssec… > > https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ > > Look, i dont have anything personal against dnssec. Just as much as any > droid, i love > > 1. 3rd rate crypto > > 2. Many enabled RCEs > > 3. Complex architectures , doubly complex operational procedure > > 4. Government managed CAs and then related procurement requirements > > But, the thing i dont like is the massive ddos it creates. Those huge records > are really not acceptable into today’s dns environment. Does it really or is it vendors failing to apply mechanisms that can stop large UDP responses to spoofed requests? DNS does support 3 way handshakes over UDP (See RFC 7873 Domain Name System (DNS) Cookies). If your resolver is not sending requests with DNS COOKIEs present you should be asking yourself “why are you using such an outdated platform”? If your resolver or authoritative server doesn’t reply with a SERVER COOKIE to a request with a DNS COOKIE present you should be asking yourself why are you continuing to use this outdated software which doesn’t help protect both the client and server from spoofed traffic. You can deploy DNS COOKIE independently on the server and client sides so you don’t have to wait for the other side to enable it. For requests without DNS COOKIEs present there is RRL mechanisms. > Please stop enabling dnssec on your domain folks, you are going to have > outage, your security is worse off, and you feeding the vendor / hacker ddos > death spiral > > > > > > > It looks like the error has been mitigated, by the way, so this manual > > override may not even have happened. > > +1. > > -- > Med venlig hilsen / Kind regards, > Arne Jensen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 and CDN's
> On 29 Nov 2021, at 09:41, scott wrote: > > > On 11/28/2021 9:47 AM, Owen DeLong via NANOG wrote: >> Why not properly assign /48s to customers and /40s to cities? >> -- > > Side note: I recently tried to get /48 per customer with ARIN on repeated > emails and they refused. We were already given an IPv6 block a while back. > I told them I wanted to expand it so I could give out a /48 per customer and > that we had more than 65535 customers, which is the block we got; 65535 /48s. > I didn't even account for our needs. > > Without arguing the reasons, we will have to hand out /56s, rather than /48s > because of this. So, it's not all /48-unicorns, puppies and rainbows. > > scott Looks like a policy omission. You should be able to grow the per customer allocation up to /48 per customer. One shouldn’t be stuck with /56 because one made a bad choice of prefix size initially. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast
That fine. XP supports IPv6 and apart from the DNS needing a IPv4 recursive server it works fine. -- Mark Andrews > On 21 Nov 2021, at 11:23, ML wrote: > > > >> On 11/19/2021 1:27 PM, William Herrin wrote: >>> On Fri, Nov 19, 2021 at 10:22 AM Zu wrote: >>> One anecdote (the non-technical grandma) illustrates a very real problem >>> that would need to be addressed -- there are non-technical people (of all >>> ages, if your concerned about ageism) which will need to implement >>> technical changes for which they are not equipped with the skills to do. >> Howdy, >> >> That depends on your timeline. Do you know many non-technical people >> still using their Pentium III computers with circa 2001 software >> versions? Connected to the Internet? >> >> Regards, >> Bill Herrin >> >> > > A huge chunk of a country (Armenia) still using Windows XP... > > https://en.wikipedia.org/wiki/Windows_XP#Market_share
Re: WKBI #586, Redploying most of 127/8 as unicast public
s not exist in the IPv4 world. >>> >>> SO an IPv6 only system without any network interfaces can run multiple >>> discrete instances of the same daemon accepting connections on the same >>> TCP port? >> Sure. >> >> Can I script that, can I template that with hardcoded >>> addresses, same as I can now for 127/8? >> Sure, if you think that's a good idea which it isn't. Use LLAs on your >> loopback interface. > > Which LLA's does an IPv6 stack without any IPv6 enabled interfaces have? > > Or worse, which LLA's will the IPv6 stack have with an IPv6 enabled > interface? Depends on the hardware address? > > LLA's are not a loopback range. So using them for that purpose is less than > ideal, and unworthy of this new protocol thats supposed to take all the good > of IPv4, discard the bad, innovate the new, usher in a renewal for the > internet, and fail at all of that. > >> >> Personally, I take my 127/8 addresses from a configuration file since I >> don't know in advance what >> other daemons might also want to run on addresses only visible on the local >> machine. > > How you deal with loopbacks on your system, is by definition, local to your > system. > > All other mechanisms are not. Maybe by convention, but not definition. > > Dont we appreciate standards for that very reason? > >> Or, you know, >> some maniac might decide that part of 127/8 isn't loopback so I have to move >> them to the part that >> still is. >> >> In IPv6 I use ULAs since that gives me the option of routing them or not. >> >> R's, >> John >> >> > ULA and registered ULA are one of those things thats hard to think about with > a straight face. They betray a variety of dichotomies that are quite > ridiculous. > > Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Redploying most of 127/8 as unicast public
> On 18 Nov 2021, at 11:58, Joe Maimon wrote: > > > > Mark Andrews wrote: >> It’s a denial of service attack on the IETF process to keep bringing up >> drafts like this that are never going to be approved. 127/8 is in use. It >> isn’t free. > > There are so many things wrong with this statement that I am not even going > to try to enumerate them. > > However suffice it to say that drafts like these are concrete documentation > of non-groupthink and essentially you are advocating for self-censorship and > loss of historical perspective. I’m advocating for not taking address away that have been allocated for a purpose. No one knows what the impact of doing that will be. Perhaps we should just take back 216.222.144.0/20? You obviously think taking back address that are in use to be a good thing. This is similar to taking back other address that are allocated but not advertised. > Which given the state of IPv6 transition, perhaps more of that in the past > would have been nice. > > For example https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 > from 2008 which fell prey to the "by the time this is usable IPv6 will have > taken over" groupthink. Again an oranges vs apples comparison. Class E is not 127/8. This is “Reserved" vs "Reserved for use on the host”. Totally different histories. Totally different expectations. > Objectively wrong. > > Predictive self-fulfilling circular arguments of this sort should no longer > be given any weight, and along your lines, should never even be brought up. > >> >> Lots of bad attempts to justify a bad idea. >> >> "The IPv4 network 127/8 was first reserved by Jon Postel in 1981 [RFC0776]. >> Postel's policy was to reserve the first and last network of each class, and >> it does not appear that he had a specific plan for how to use 127/8.” >> >> Having a space for permission-less innovation and testing is a good thing. >> Jon understood that. > > Yes its a good idea to have space that is guaranteed to be available to every > system regardless of its networking condition and that the host has > deterministic control over the addressing used in that space. > > However, it turns out that /8 was much too large. The extreme few instances > of its usefulness at that size pale in comparison with even the possibility > of its usefulness to the public. > > So any attempt to adjust that should be given proper attention and serious > thought. > >> >> "By contrast, IPv6, despite its vastly larger pool of available address >> space, allocates only a single local loopback address (::1) [RFC4291]. This >> appears to be an architectural vote of confidence in the idea that Internet >> protocols ultimately do not require millions of distinct loopback addresses.” >> >> This is an apples-to-oranges comparison. IPv6 has both link and site local >> addresses and an architecture to deliver packets to specific instances of >> each. This does not exist in the IPv4 world. > > SO an IPv6 only system without any network interfaces can run multiple > discrete instances of the same daemon accepting connections on the same TCP > port? Yes. I’ve been doing testing over the IPv6 loopback for 20+ years now. > Can I script that, can I template that with hardcoded addresses, same as I > can now for 127/8? > > Good thing I can just use :::127.0.0.1/104 You can script is to the same extent that you can hard code 127/8 addresses. I’ve used ULA addresses but conceptually they are the same. The lo0 interface also has more that 127.0.0.1 IPv4 addresses on it. % ifconfig lo0 inet6 lo0: flags=8049 mtu 16384 options=1203 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet6 fd92:7065:b8e:::1 prefixlen 64 inet6 fd92:7065:b8e:::2 prefixlen 64 inet6 fd92:7065:b8e:::3 prefixlen 64 inet6 fd92:7065:b8e:::4 prefixlen 64 inet6 fd92:7065:b8e:::5 prefixlen 64 inet6 fd92:7065:b8e:::6 prefixlen 64 inet6 fd92:7065:b8e:::7 prefixlen 64 inet6 fd92:7065:b8e:::8 prefixlen 64 inet6 fd92:7065:b8e:::9 prefixlen 64 inet6 fd92:7065:b8e:::10 prefixlen 64 inet6 fd92:7065:b8e:ff::1 prefixlen 64 inet6 fd92:7065:b8e:ff::2 prefixlen 64 inet6 fd92:7065:b8e:99ff::1 prefixlen 64 inet6 fd92:7065:b8e:99ff::2 prefixlen 64 inet6 fd92:7065:b8e:fffe::a35:4 prefixlen 64 nd6 options=201 % >> "In theory, having multiple local loopback addresses might be useful for >> increasing the number of distinct IPv4 sockets that can be used for
Re: Redploying most of 127/8 as unicast public
It’s a denial of service attack on the IETF process to keep bringing up drafts like this that are never going to be approved. 127/8 is in use. It isn’t free. Lots of bad attempts to justify a bad idea. "The IPv4 network 127/8 was first reserved by Jon Postel in 1981 [RFC0776]. Postel's policy was to reserve the first and last network of each class, and it does not appear that he had a specific plan for how to use 127/8.” Having a space for permission-less innovation and testing is a good thing. Jon understood that. "By contrast, IPv6, despite its vastly larger pool of available address space, allocates only a single local loopback address (::1) [RFC4291]. This appears to be an architectural vote of confidence in the idea that Internet protocols ultimately do not require millions of distinct loopback addresses.” This is an apples-to-oranges comparison. IPv6 has both link and site local addresses and an architecture to deliver packets to specific instances of each. This does not exist in the IPv4 world. "In theory, having multiple local loopback addresses might be useful for increasing the number of distinct IPv4 sockets that can be used for inter-process communication within a host. The local loopback /16 network retained by this document will still permit billions of distinct concurrent loopback TCP connections within a single host, even if both the IP address and port number of one endpoint of each connection are fixed.” But it doesn’t deliver millions of end points. Sorry you simulation will not work because we don’t have more that 65000 end points anymore. Sorry RFC 1918 addresses are not always suitable. "Reserved for " is not the same as “Reserved”. Mark > On 18 Nov 2021, at 10:45, scott wrote: > > > > On 11/17/2021 1:29 PM, Jay R. Ashworth wrote: >> This seems like a really bad idea to me; am I really the only one who >> noticed? >> >> >> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html >> >> >> That's over a week old and I don't see 3000 comments on it, so maybe it's >> just >> me. So many things are just me. >> >> [ Hat tip to Lauren Weinstein, whom I stole it from ] >> > - > > > > > Everyone's just tired of rehashing this stuff... ;) I looked up the "IPv4 > Unicast Extensions Project" the authors (S.D. Schoen, J. Gilmore and D. Täht) > are a part of. > > > > https://github.com/schoen/unicast-extensions > > -- > > Fixing the odd nooks and crannies still mildly broken in IPv4, by: > > • Making class-e (240/4), 0/8, 127/8, 224/4 more usable > • Adding 419 million new IPs to the world > • Fixing zeroth networking > • Improving interoperability with multiple protocols and tunnelling > technologies > • Supplying tested patches and tools that address these problems > -- > > Some of these are hardcoded in ASICs, I believe. Change that! ;) > > scott > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: more spaces in PTRs, this time totisp.net
\032 is space. Go read STD13 aka RFC 1034 and RFC 1035. -- Mark Andrews > On 22 Oct 2021, at 16:40, Owen DeLong via NANOG wrote: > > \032 is not a space. > > Decimal 32 (0x20, \040) is a space. > \032 is a Ctrl-Z (26 decimal, 0x1a) > > Owen > > >> On Oct 21, 2021, at 22:14 , Mel Beckman wrote: >> >> Typo I’d say. DB-drive DNS servers, which don’t keep their entries in >> traditional PTR-record text format, can fall victim to this. Rather than >> parse the text every times, they just spit out whatever is in the table >> column, even if it has embedded spaces. I’ve seen this happen in SnitchDNS. >> >> -mel via cell >> >>>> On Oct 21, 2021, at 9:08 PM, Steven Champeon wrote: >>> >>> >>> Anyone? >>> >>> 1.179.154.11:1-179-180.11.cisp.totisp.\\ net >>> >>> dig -x 1.179.154.11 >>> >>> 11.154.179.1.in-addr.arpa. 7200INPTR >>> 1-179-180.11.cisp.totisp.\032net. >>> >>> -- >>> hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: >>> http://hesketh.com/ >>> Internet security and antispam hostname intelligence: >>> http://enemieslist.com/ >
Re: IPv6 woes - RFC
> On 29 Sep 2021, at 05:02, Randy Bush wrote: > >> Heh, NAT is not that evil after all. Do you expect that all the home >> people will get routable public IPs for all they toys inside house? > > in ipv6 they can. and it can have consequences, see > >NATting Else Matters: Evaluating IPv6 Access Control Policies in >Residential Networks; >Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife > >https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf > > the ietf did not give guidance to cpe vendors to protect toys inside > your LAN Really? RFC6092 January 2011 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service https://datatracker.ietf.org/doc/html/rfc6092 CableLabs has similar requirements. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 woes - RFC
r to Windows 98. Or >> "different" in place of "similar". >> >>> It should just fix problem (do we have other problems I am not aware of with >>> IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years >>> of >>> usage we pretty much fixed all problems we had. >> >> I disagree. >> >>> The second failure is adoption. Even if my IPv6 hate is not rational, >>> adoption >>> of IPv6 is crap. If adoption would be much better, more IPv4 could be used >>> for >>> legacy networks ;) So stuborn guys like me could be happy too ;) >> >> I blame the industry, not the IPv6 protocol, for the lackluster adoption of >> IPv6. >> >>> As for details, that list is just my dream IPv6 protocol ;) >>> >>> But lets talk about details: >>> - Loopback on IPv6 is ::1/128 >>> I have setups where I need more addresses there that are local only. >>> Yeah I know, we can put extra aliases on interfaces etc.. but its extra >>> work and not w/o problems >> >> How does IPv6 differ from IPv4 in this context? >> >>> - IPv6 Link Local is forced. >>> I mean, its always on interface, nevermind you assign static IP. >>> LL is still there and gets in the way (OSPFv3... hell yeah) >> >> I agree that IPv6 addresses seem to accumulate on interfaces like IoT >> devices do >> on a network. But I don't see a technical problem with this in and of >> itself. >> -- I can't speak to OSPFv3 issues. >> >>> - ULA space, well.. its like RFC1918 but there are some issues with it >>> (or at least was? maybe its fixed) like source IP selection on with >>> multiple addresses. >> >> I consider this to be implementation issues and not a problem with the >> protocol >> itself. >> >>> - Neighbor Discovery protocol... quite a bit problems it created. >> >> Please elaborate. >> >>> What was wrong w/ good old ARP? I tought we fixed all those problems >>> already like ARP poisoning via port security.. etc >> >> The apparent need to ""fix / address / respond to a protocol problem at a >> lower >> layer seems like a problem to me. >> >>> - NAT is there in IPv6 so no futher comments >>> - DHCP start to get working on IPv6.. but it still pain sometimes >> >> What problems do you have with DHCP for IPv6? I've been using it for the >> better >> part of a decade without any known problems. What pain are you experiencing? >> >>> And biggest problem, interop w/ IPv4 was completly failure. >> >> I agree that the interoperability between IPv4 and IPv6 is the tall pole in >> the >> tent. But I also believe that's to be expected when trying to interoperate >> disparate protocols. >> >>> From ground zero, I would expect that disparate protocols can't interoperate >> without external support, some of which requires explicit configuration. >> >>> Currently we have best Internet to migrate to new protocol. Why? >> >> The primary motivation -- as I understand it -- is the lack of unique IP >> addresses. >> >>> Because how internet become centralized. Eyeball networks just want to reach >>> content. E2E communication is not that much needed. We have games and >>> enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS. >> >> Now you are talking about two classes of Internet connectivity: >> >> 1) First class participation where an endpoint /is/ /on/ the Internet with a >> globally routed IP. >> 2) Second class participation where an endpoint /has/ /access/ /to/ the >> Internet via a non-globally routed IP. >> >> There may be some merit to multiple classes of Internet connectivity. But I >> think it should be dealt with openly and above board as such. >> >>> And end comment. I do NOT want to start some kind of flame war here. Yeah I >>> know, Im biased toward IPv4. >> >> I don't view honest and good spirited discussion of facts and understanding >> to >> be a flame war. In fact, I view such discussions as a good thing. >> >>> If something new popups, I want it better than previous thingie (a lot) and >>> easier or at least same level of complications, but IPv6 just solves one >>> thing >>> and brings a lot of complexity. >> Please elaborate on the complexity that IPv6 brings that IPv4 didn't also >> bring >> with it in the '90s? >> >> Would the things that you are referring to as IPv6 complexities have been any >> different if we had started with IPv6 instead of IPv4 in the '80s & '90s? >> >> In some ways it seems to me that you are alluding to the legacy code / >> equipment >> / understanding / configuration / what have you. This is something that many >> have been dealing with for quite a while. The mainframe's ability to run >> code >> from near half a century ago comes to mind. >> >>> The fact is, IPv6 failed. >> >> I concede that IPv6 has faltered. But I don't believe it's failed. I don't >> think it's fair to claim that it has. >> >>> There are probably multiple reasons for it. Do we ever move to IPv6? I dont >>> know.. Do I care for now? Nope, IPv4 works for me for now. >> >> You are entitled to your own opinion as much as I'm entitled to mine. But the >> key thing to keep in mind is that it's /your/ opinion. The operative word >> being >> "your" as in "you". Your views / opinions / experiences are /yours/. What's >> more important is that other people's views / opinions / experiences may be >> different. >> >> >> >> -- >> Grant. . . . >> unix || die -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 woes - RFC
So a single level of NAT and a similar level of customers to that which was stated could be supported by a single IP. This is not quite a apples to apples comparison to the double NAT scenario being described below but close enough for the number of sessions. Mark > On 24 Sep 2021, at 01:34, Colton Conor wrote: > > 300 apartments Mark. No, it's bulk internet and wifi so a single provider. > > On Wed, Sep 22, 2021 at 8:01 PM Mark Andrews wrote: >> >> And how many apartments where covered by that single IP address? Was this >> where there is a restriction on other providers so the occupants had no >> choice of wireline ISP? >> >>> On 23 Sep 2021, at 09:38, Colton Conor wrote: >>> >>> Where does this "You can only have about 200-300 subscribers per IPv4 >>> address on a CGN." limit come from? I have seen several apartment >>> complexes run on a single static IPv4 address using a Mikrotik with >>> NAT. >>> >>> On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl >>> wrote: >>>> >>>> >>>> >>>> On Wed, 22 Sept 2021 at 16:48, Masataka Ohta >>>> wrote: >>>>> >>>>> Today, as /24 can afford hundreds of thousands of subscribers >>>>> by NAT, only very large retail ISPs need more than one >>>>> announcement for IPv4. >>>> >>>> >>>> You can only have about 200-300 subscribers per IPv4 address on a CGN. If >>>> you try to go further than that, for example by using symmetric NAT, you >>>> will increase the number of customers that want to get a public IPv4 of >>>> their own. That will actually decrease the combined efficiency and cause >>>> you to need more, not less, IPv4 addresses. >>>> >>>> Without checking our numbers, I believe we have at least 10% of the >>>> customers that are paying for a public IPv4 to escape our CGN. This means >>>> a /24 will only be enough for about 2500 customers maximum. The "nat >>>> escapers" drown out the efficiency of the NAT pool. >>>> >>>> The optimization you need to do is to make the CGN as customer friendly as >>>> possible instead of trying to squeeze the maximum customers per CGN IPv4 >>>> address. >>>> >>>> Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. >>>> If it helps just a little bit, that alone will make implementing IPv6 >>>> worth it for smaller emerging operators. Buying IPv4 has become very >>>> expensive. Yes you can profit from selling a public IPv4 address to the >>>> customer, but there is also the risk that the customer just goes to the >>>> incumbent, which has old large pools of IPv4 and provides it for free. >>>> >>>> Regards, >>>> >>>> Baldur >>>> >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 woes - RFC
And how many apartments where covered by that single IP address? Was this where there is a restriction on other providers so the occupants had no choice of wireline ISP? > On 23 Sep 2021, at 09:38, Colton Conor wrote: > > Where does this "You can only have about 200-300 subscribers per IPv4 > address on a CGN." limit come from? I have seen several apartment > complexes run on a single static IPv4 address using a Mikrotik with > NAT. > > On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl > wrote: >> >> >> >> On Wed, 22 Sept 2021 at 16:48, Masataka Ohta >> wrote: >>> >>> Today, as /24 can afford hundreds of thousands of subscribers >>> by NAT, only very large retail ISPs need more than one >>> announcement for IPv4. >> >> >> You can only have about 200-300 subscribers per IPv4 address on a CGN. If >> you try to go further than that, for example by using symmetric NAT, you >> will increase the number of customers that want to get a public IPv4 of >> their own. That will actually decrease the combined efficiency and cause you >> to need more, not less, IPv4 addresses. >> >> Without checking our numbers, I believe we have at least 10% of the >> customers that are paying for a public IPv4 to escape our CGN. This means a >> /24 will only be enough for about 2500 customers maximum. The "nat escapers" >> drown out the efficiency of the NAT pool. >> >> The optimization you need to do is to make the CGN as customer friendly as >> possible instead of trying to squeeze the maximum customers per CGN IPv4 >> address. >> >> Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. If >> it helps just a little bit, that alone will make implementing IPv6 worth it >> for smaller emerging operators. Buying IPv4 has become very expensive. Yes >> you can profit from selling a public IPv4 address to the customer, but there >> is also the risk that the customer just goes to the incumbent, which has old >> large pools of IPv4 and provides it for free. >> >> Regards, >> >> Baldur >> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 woes - RFC
It tells you that AT don’t treat IPv6 on equal footing to IPv4 and nothing more. There is nothing at the protocol level stopping AT offering a similar level of service. Don’t equate poor implementation with the protocol being broken. -- Mark Andrews > On 19 Sep 2021, at 07:19, Stephen Satchell wrote: > > I concur that the problem is not a routing hardware problem. It's a > perception problem with the various ISPs. I have fiber service with AT > > My little server farm endpoints all have IPv6 addresses, including the edge > router. I also have a plan to allocate IPv6 addresses to my LAN devices, and > to protect the LAN devices from outside interference by rules in the NFTABLES > firewall that include connection tracking on outbound requests. (IPv4 will > still use NAT to keep nefarious people from probing my internals.) > > Specifically, when I was doing my mail server refresh (moving from Red Hat to > Canonical) I decided it was time to offer IPv6 connectivity in the mail > server to "future proof" my setup. That included adding records in my > DNS zone files. Failure! The issues: > > 1. I learned that there are no "static addresses" in IPv6, as far as AT > was concerned. By all appearances, though, the IPv6 /64 is relatively > static, for now, similar to the way that early cable modem deployments kept > the same IPv4 addresses. (Until the cable people started forcing changes on > DHCP lease renewal, that is.) > > 2. My request for PTR records was denied, which means I can't satisfy Best > Practices for a mail server in the IPv6 space. No PTR records, no > redirection of ip6.apra space, nothing. I include AT's refusal below. > > 3. I don't know how to get an IPv6 allocation from ARIN, how to request AT > to route it, or how to deal with the DNS server issues. Oh, I know how to > configure BIND9; I would prefer using a 24/7/365 provider. For example, my > master zone files are with Register.com, so if my circuit goes down the name > resolution still happens. Register.com appears not to provide reverse-DNS > PTR zone support (in6.arpa). A Google search turned up NOTHING for in6.arpa > hosting. > > That tells me that IPv6 is not "Internet Ready" for small users. Given the > level of FU responses I get trying to work with it, I will stop banging my > head against the wall. > > So I stick with IPv4, because that will be the "standard" until the day I > die, as far as I can tell. > > (I removed the record, so as not to confuse mail server that DO operate > IPv6.) > >> Subject: RE: Need IPv6 PTR record for my IPv6 mail server >> Date: Mon, 19 Jul 2021 12:52:53 + >> From: Prov-DNS >> To: Prov-DNS , a...@satchell.net >> Hello We don't process DNS request on IPv6 addresses. We only process DNS >> request on IPv4 static assigned addresses. If you would like us to >> process a DNS request for you on a IPv4 address please provide the >> following information. >> IPv4 address you would like the record created for Host name you would > >> like that IP address pointed to > > >> Thanks >> Michael AT Prov-DNS >> -Original Message- >> From: Stephen Satchell >> Sent: Friday, July 16, 2021 5:42 PM >> To: DNSUpdates cB >> Subject: Need IPv6 PTR record for my IPv6 mail server >> Here is the record I need inserted into your ip6.arpa DNS zone: > 2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. 0 > IN PTR smtp.satchell.net. >> This is the result from the question section of a dig(1) request for the PTR >> record for my IPv6 address 2600:1700:79b0:ddc0::32, and the fully-qualified >> domain name of the server. >> You can verify the information using dig smtp.satchell.net and checking >> the reverse. >> This is the only server in my collection that needs the IPv6 pointer. >
Re: IPv6 woes - RFC
> On 10 Sep 2021, at 17:21, Bjørn Mork wrote:
>
> 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 get out of la-la land now.
>
> Your edge routers can do CGN for all connected users just fine. Yes,
> there is still a cost both in resources and management, but you'll have
> to weigh that against the cost of doing dual-stack on the same box. I'm
> not convinced dual-stack wins.
>
> Don't know what you're thinking of wrt support calls, but dual-stack has
> some failure modes which are difficult to understand for both end users
> and support. NAT is pretty well understood in comparison.
>
> Your routing tables won't grow with IPv4 or CGN. They grow when you add
> IPv6.
>
>> Increased cost of developers having to work around NAT and NAT
>> becoming ever more complex with multiple layers, etc.
>
> And this can be avoided by reconfiguring the local network somehow? Or
> are we talking about an Internet without IPv4? This is even more
> fantastic than the idea that IPv4 is optional in the local network.
>
>> All of these are the things driving the ever increasing cost of IPv4
>> services, not just the cost of the addresses.
>
> Yes, the cost of addresses is not prohibitive, and there is no
> indication it will be.
>
> The consolidation of hosting services have reduced the need for globally
> routable addresses. You don't host your own mail server and web server
> anymore, even if you're a large organisation. Most ISPs haven't yet
> taken advantage of this. They are still giving globally routable IPv4
> addresses to customers which have no need for that. These addresses can
> be re-allocated for CGN if there is a need. This is obviously still not
> free, but it does limit the price of fresh IPv4 addresses.
>
> The other costs you list will not affect an IPv4 only shop at all.
>
>
> Bjørn
Or you could deliver IPv6-only to your customers and used to CGN boxes
to deliver IPv4AAS using less than 1/2 the IPv4 address space you need
for a NAT444 solution as +60% of your traffic doesn’t need CGN processing.
464XLAT example
{ Internet IPv4(40% of traffic) + IPv6(60% of traffic) } - [Router w/ NAT64] -
{ IPv6-only (IPv4 traffic has been translated to IPv6) } - [CPE w/ CLAT] { home
network IPv4 + IPv6 }
DS-Lite
{ Internet IPv4(40% of traffic) + IPv6(60% of traffic) } - [Router w/ AFTR] - {
IPv6-only (IPv4 traffic has been encapsulated in IPv6) } - [CPE w/ B4] { home
network IPv4 + IPv6 }
MAP-T and MAP-E are similar to 464XLAT and DS-Lite respectively.
Yes, you have to learn something new but it costs less that a “pure" IPv4
service.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: if not v6, what?
> On 8 Sep 2021, at 12:51, Masataka Ohta > wrote: > > Niels Bakker wrote: > >>> As for well known port, we can specify non-default port numbers >>> in URLs (I'm not sure whether it works for mailto: or not) or. >>> in the future, things like DNS SRV RRs should be helpful. >> This absolutely doesn't work. > > Thank you very much for your emotional and unfounded > comment. > >> And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email). Which is why there is HTTPS and SVCB. If you look at your recursive server logs you are likely to see queries for HTTPS being made as browsers are starting to make queries for HTTPS (a.k.a. TYPE65). > I know SRV and other similar proposals so far are not > very compatible with URL syntax and should better be > simplified. The only thing difficult to map was non-default ports and that could easily have been addressed. Remember SRV required a seperate RFC to specify how to map existing services on to it. HTTPS just prefixed the label "_”. That could have easily been done with SRV. HTTPS and SVBC are just SRV on steroids. >>> Then, to run servers at home, we only need some not-well-known >>> ports forwarded, which can be default or value added service of >>> your local ISP, just like fixed IP addresses today. > >> Oh and we need to work around the whole IP reputation system that governs >> email today. > IP reputation system must evolve to be IP+port reputation > system, which is not my problem. > >> Is there even any IETF work being done on getting port forwards on a device >> behind your immediate LAN at home? > > That's overkill, because servers should have stable > addresses and ports. So, we only need statically > configured port forwarding. > > But if you insist, UPnP by Microsoft has been implemented > on almost all NAT boxes. There even exists PCP. But how much has been implemented in CGNs and how many ISP’s enable it if it is implemented? Getting IPv4 continue to work just add layer upon layer of hacks which we are all continuing to pay for. While we debate more and more services are enabling IPv6 and the traffic is shifting to IPv6. >> Do you have any more practical proposals, or..? > > What are missing are practical comments. > > Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: The great Netflix vpn debacle!
If Netflix, et al. are not accepting connections from CGNs they are ALREADY obsolete. Yes, I know it sucks to have to tell your customers that they just bought obsolete equipment. Plug in Chromecast, Apple TV, and they can get back that functionality with a product that does actually get upgraded. Mark > On 1 Sep 2021, at 09:13, Owen DeLong wrote: > > You just broke 99% of the smart television sets in people’s homes, > unfortunately. > > That will resolve itself over time, of course, as sets are replaced, but > anyone with > a set that is more than ~3 years old is mostly unlikely to have IPv6 support > in it and > the vendors are ALL universally terrible about updating firmware. > > As much as I like the idea (and that if a sufficient number of providers were > willing > to do so, it might just serve as a forcing function to get firmware updates > done), > I wouldn’t hold my breath and I suspect where there are competitive > alternatives, > such a notice would be a boon to the competition. > > Owen > > >> On Aug 31, 2021, at 15:15 , Mark Andrews wrote: >> >> Force the traffic to these companies to use IPv6. Advise your customers that >> you are doing this, why you are doing this and what steps they need to take >> to enable IPv6 on their equipment. Your customers can’t be in a worse >> position. >> >> "Dear customer, >> if you want to reach … you will need to enable IPv6 support in >> your home network. The world ran out of enough IPv4 for everyone several >> years >> back and we have been sharing IPv4 between customers to allow you to reach >> IPv4 >> only sites. The afore mentioned companies are now blocking IPv4 connections >> from >> ISPs that have to share IPv4 addresses. To give you a better service we are >> blocking IPv4 connections to these companies so you will get a more reliable >> service >> over IPv6. >> >> For instructions on how to enable IPv6 connectivity on you home router see >> this >> page …. >> >> If your home router does not support IPv6 you will need to upgrade it to one >> that does." >> >>> On 1 Sep 2021, at 06:36, Bryan Holloway wrote: >>> >>> Thanks, Owen ... good point. >>> >>> Now hearing reports for these same prefixes with Disney+ too. >>> >>> So the common denominators are: >>> >>> HBO >>> Hulu >>> Netflix >>> Amazon Prime >>> Disney+ >>> >>> ... there has _got_ to be some new-fangled DB somewhere. This all started >>> in the last month or so. >>> >>> All of our RR objects, whois, DNS is solid ... dehr? >>> >>> Fun times. >>> >>> >>> On 8/31/21 9:16 PM, Owen DeLong wrote: >>> >>> [snip] >>> >>>> Geolocate and VPN or Not are often kind of tied to the same kinds of >>>> reporting services and it may well be that whatever provider HBO is using >>>> for one is also being used for the other. >>>> Owen >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: The great Netflix vpn debacle!
Force the traffic to these companies to use IPv6. Advise your customers that you are doing this, why you are doing this and what steps they need to take to enable IPv6 on their equipment. Your customers can’t be in a worse position. "Dear customer, if you want to reach … you will need to enable IPv6 support in your home network. The world ran out of enough IPv4 for everyone several years back and we have been sharing IPv4 between customers to allow you to reach IPv4 only sites. The afore mentioned companies are now blocking IPv4 connections from ISPs that have to share IPv4 addresses. To give you a better service we are blocking IPv4 connections to these companies so you will get a more reliable service over IPv6. For instructions on how to enable IPv6 connectivity on you home router see this page …. If your home router does not support IPv6 you will need to upgrade it to one that does." > On 1 Sep 2021, at 06:36, Bryan Holloway wrote: > > Thanks, Owen ... good point. > > Now hearing reports for these same prefixes with Disney+ too. > > So the common denominators are: > > HBO > Hulu > Netflix > Amazon Prime > Disney+ > > ... there has _got_ to be some new-fangled DB somewhere. This all started in > the last month or so. > > All of our RR objects, whois, DNS is solid ... dehr? > > Fun times. > > > On 8/31/21 9:16 PM, Owen DeLong wrote: > > [snip] > >> Geolocate and VPN or Not are often kind of tied to the same kinds of >> reporting services and it may well be that whatever provider HBO is using >> for one is also being used for the other. >> Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A crazy idea
It is theoretically possible to completely automate reverse DNS provisioning.
It just requires will to do it. Enterprises have been doing automated reverse
DNS provisioning for decades now using DNS UPDATE requests from DHCP servers
using TSIG or GSS-TSIG.
This method does it as part of prefix delegation and provides support for
cryptographically secure updates by passing the public key as part of the
prefix delegation request.
https://www.ietf.org/archive/id/draft-andrews-dnsop-pd-reverse-02.txt
You could also just allow DNS UPDATE requests over TCP/IPv6 to add/delete NS
and DS records at the /48 level of reverse tree matching the TCP source address.
BIND has supported this for over a decade now as it was developed to provide a
mechanism to populate the 6to4 reverse zone (2.0.0.2.ip6.arpa). It didn’t get
taken up as Geoff Huston decide to go the HTTP route. I would have the DHCPv6
server delete the records when the prefix delegation expires.
key DHCP-SERVER {
...
};
zone 8.B.D.0.1.0.0.2.ip6.arpa {
...
update-policy {
// limit to 10 NS records and 5 DS records.
grant * 6to4-self . NS(10) DS(5);
grant DHCP-SERVER subdomain *;
};
};
In both cases the customer populates the delegation and adds DS records as
required.
This is just bolting together existing technologies.
This will not take off unless ISPs buy into the mechanisms.
Mark
> On 20 Jul 2021, at 03:01, Bryan Fields wrote:
>
> On 7/19/21 8:09 AM, Stephen Satchell wrote:
>> First, I know this isn't the right place to propose this; need a pointer
>> to where to propose an outlandish idea.
>
>> What would the domain names look like? Let's take my current IP/IPv6
>> assignments from AT:
>>
>> 2600:1700:79b0:ddc0::/64
>> 99.65.194.96/29
>>
>> The IPv6 delegation would be easy:
>>
>>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
>>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.
>
> Yup, simple, I do this for my customers (and DS records).
>
> However that reverse zone has DNSSEC on it. You'd need a DS record to tie
> my-DNS-server-1. to the ATT DNS server and your server would need to support
> DNSSEC. ATT may want to enforce DNSSEC on that zone, but not want to sign
> stuff they can't control.
>
> Just playing devils advocate.
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DANE of SMTP Survey
DANE works with self generated CERTs. The TLSA record provides the cryptographic link back to the DNSSEC root. -- Mark Andrews > On 3 Jun 2021, at 22:32, babydr DBA James W. Laferriere > wrote: > > Hello Mark , > >> On Wed, 2 Jun 2021, Mark Tinka wrote: >>> On 6/2/21 11:07, Jeroen Massar via NANOG wrote: >>> >>> As for solutions: better education, more improvements to the tools & making >>> it easier. CDS records already help a lot. But we might also need to >>> improve recovery mechanisms, as f-ups are made, and you don't want to be >>> off this Internet thing for too long. >> >> I think DNSSEC implementation needs to be made less scary for folk who are >> apprehensive, and broken down into two steps, where step 1 is most >> emphasized: >> >> * Enable DNSSEC on your resolvers. Does not require you to sign your >> zones. Does not require you to read up on what it takes to sign and >> maintain your zones. Does not require you to worry and test for the >> next 60 days whether DNSSEC will break your e-mail delivery, e.t.c.: >> >> dnssec-enable yes; >> dnssec-validation auto; >> >> Done! Two lines (BIND, in this case), and off you go. > >Will this handle the case of self-signed only ? >And as Jeroen Massar mentioned the resignation of a certificate is a tad > troubles some for both DNSSEC & DANE . > >> * Step 2 - take your time cluing up on getting your zone signed, and >> being part of the solution toward a more secure Internet. No >> pressure, at your pace. > >Again , Will this handle the case of self-signed only ? > >> Mark. >Tia , JimL > -- > +-+ > | James W. Laferriere| SystemTechniques | Give me VMS | > | Network & System Engineer | 3237 Holden Road | Give me Linux | > | j...@system-techniques.com | Fairbanks, AK. 99709 | only on AXP | > +-+
Re: login.authorize.net has A and CNAME records
> On 7 Apr 2021, at 17:20, Bjørn Mork wrote: > > 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 and akami, but zone contents >> are different on the two platforms: >> >> bjorn@miraculix:~$ for s in $(dig +short ns authorize.net|sort); do echo -n >> "$s: ";dig +short login.authorize.net @$s|xargs; done >> a10-64.akam.net.: login.authorize.net.cdn.cloudflare.net. >> a1-190.akam.net.: login.authorize.net.cdn.cloudflare.net. >> a2-65.akam.net.: login.authorize.net.cdn.cloudflare.net. >> a9-64.akam.net.: login.authorize.net.cdn.cloudflare.net. >> ns0090.secondary.cloudflare.com.: 104.18.8.127 104.18.9.127 >> ns0210.secondary.cloudflare.com.: 104.18.9.127 104.18.8.127 > > Doh! I should know better. Sorry, ignore that. Don't ask for A records > if you want to see CNAMEs.. 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. "The domain system provides such a feature using the canonical name (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.” Returning a signed CNAME is cryptographic proof that an A record does not exist at the name with DNSSEC. Mark > Bjørn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: login.authorize.net has A and CNAME records
> On 7 Apr 2021, at 05:59, Arne Jensen wrote: > > > Den 06-04-2021 kl. 21:47 skrev Seth Mattinen: >> >>> >>> What kind of local problem or network problems could cause a servfail >>> response from the authoritative ns? >> >> >> >> I'm beginning to think this is a DNSSEC related problem, I'll ask on >> the pdns-users list. I see it's asking for a DS record on >> login.authorize.net.cdn.cloudflare.net when the nearest one appears to >> be at cloudflare.net, so for some reason that's not being applied all >> the way down. > > I do somehow take that "local problem" part back again, which also > wasn't intended exactly in the way that it was written: > > -> > https://dnssec-analyzer.verisignlabs.com/login.authorize.net.cdn.cloudflare.net > > Is looking at login.authorize.net.cdn.cloudflare.net/DNSKEY, but failing > due to the SERVFAIL. > > -> https://dnsviz.net/d/login.authorize.net.cdn.cloudflare.net/dnssec/ > > Seems to claim that it works just fine. > > Asking login.authorize.net.cdn.cloudflare.net/DNSKEY or > login.authorize.net.cdn.cloudflare.net/DS returns SERVFAIL here too. > > > But I don't think you should be querying /DNSKEY or /DS, except a the > (current) delegation's root, e.g. as you say yourself, at > "cloudflare.net" in this case. It shouldn’t matter if you query for them. If the records don’t exist then you should get back NOERROR/NODATA responses with NSEC/NSEC3 records to prove those responses. Note the server claims that TXT records exist at login.authorize.net.cdn.cloudflare.net but can’t return them. % dig login.authorize.net.cdn.cloudflare.net type65 @198.41.222.31 +dnssec ; <<>> DiG 9.15.4 <<>> login.authorize.net.cdn.cloudflare.net type65 @198.41.222.31 +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1641 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;login.authorize.net.cdn.cloudflare.net.IN TYPE65 ;; AUTHORITY SECTION: cloudflare.net. 5 IN SOA ns1.cloudflare.net. dns.cloudflare.com. 1617743605 1 2400 604800 5 login.authorize.net.cdn.cloudflare.net. 5 IN NSEC \000.login.authorize.net.cdn.cloudflare.net. A HINFO MX TXT LOC SRV NAPTR CERT SSHFP RRSIG NSEC TLSA SMIMEA HIP OPENPGPKEY TYPE64 SPF URI CAA cloudflare.net. 5 IN RRSIG SOA 13 2 5 20210407221325 20210405201325 34505 cloudflare.net. BfBNcB9zG3T6d7mu5okde144g0OlxBazynPBD78o/ig5y0JHWo+L2ufu mhSfOquAkq6lqa/V+3yySMERlQKcIQ== login.authorize.net.cdn.cloudflare.net. 5 IN RRSIG NSEC 13 6 5 20210407221325 20210405201325 34505 cloudflare.net. +shgKZcdkQZvH9ZFEZvdXyHe7+FkX1mCit9xe4V7A+uEEYi3L7vnf16x Wyvzs0o4TlQiOJlYBG4vEkKE3d8NwQ== ;; Query time: 17 msec ;; SERVER: 198.41.222.31#53(198.41.222.31) ;; WHEN: Wed Apr 07 07:13:25 AEST 2021 ;; MSG SIZE rcvd: 417 % % dig login.authorize.net.cdn.cloudflare.net txt @198.41.222.31 +dnssec ; <<>> DiG 9.15.4 <<>> login.authorize.net.cdn.cloudflare.net txt @198.41.222.31 +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46557 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;login.authorize.net.cdn.cloudflare.net.IN TXT ;; Query time: 15 msec ;; SERVER: 198.41.222.31#53(198.41.222.31) ;; WHEN: Wed Apr 07 07:14:22 AEST 2021 ;; MSG SIZE rcvd: 67 % > Or if "cdn.cloudflare.net" had been a sub-delegation, then at that point... > > -- > Med venlig hilsen / Kind regards, > Arne Jensen > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: 10 years from now... (was: internet futures)
There are more smart phones in use in the world today the world than can be addressed by IPv4. Complaining about lack of IPv6 deployment has been legitimate for a long time. Telcos shouldn’t have to deploy NATs. Homes shouldn’t have to deploy NATs. Businesses shouldn’t have to deploy NATs. NATs produce a second class Internet. We have had to lived with a second class Internet for so long that most don’t know what they are missing. -- Mark Andrews > On 27 Mar 2021, at 07:14, Andy Ringsmuth wrote: > > >> >>> On 3/26/21 12:26 PM, Mark Tinka wrote: >>> If the last decade is anything to go by, I'm keen to see what the next one >>> brings. >>> Mark. >>> >> >> >> So the obvious question is what will happen to the internet 10 years from >> now. The last 10 years were all about phones and apps, but that's pretty >> well played out by now. Gratuitously networked devices like my dishwasher >> will probably be common, but that's hardly exciting. LEO internet providers >> will be coming online which might make a difference in the corners of the >> world where it's hard to get access, but will it allow internet access to >> parachute in behind the Great Firewall? >> >> One thing that we are seeing a revolution in is with working from home. That >> has some implications for networking since symmetric bandwidth, or at least >> quite a bit more upstream would be helpful as many people found out. Is >> latency going to drive networking, given gaming? Gamers are not just zitty >> 15 year olds, they are middle aged or older nowadays. >> >> Mike > > Ten years from now? Easy. We’ll still be talking about the continued shortage > of IPv4 address space and (legitimately) complaining about why IPv6 still > isn’t the default addressing/routing methodology for the Internet worldwide. > > > -Andy
Re: Ip space Dilemma
I did similar over a bad DNS firewall settings that where dropping queries causing the initial connection to take minutes. I’d already contacted the administrator and been told it would be looked into multiple times. After a several of months without a resolution, I escalated with a letter to the Minster, Shadow Minister and the CEO of the company the servers where outsourced too pointing out the problem. Fixed within a couple of days. -- Mark Andrews > On 10 Mar 2021, at 06:17, Kevin Wallace wrote: > > On Tue, Mar 9, 2021, at 6:13 AM, Justin Wilson (Lists) wrote: >> I [..] was finally told we were not a priority. > >> Does anyone have any creative ideas on how to fix this? > > You might write them a letter like the following: > >Dear $AGENCY, > >Pursuant to the Indiana Access to Public Records Act (IC 5-14-3), >I hereby request the following records: > * all internal communication regarding $PROBLEM_PREFIX > * all configuration files on $IMPLICATED_FIREWALL > >Thank you in advance for your anticipated cooperation in this matter. >I look forward to receiving your response to this request within 7 >business days, as the statute requires. > > See what that yields you, and go from there. YMMV, IANAL, etc. > > Kevin
Re: Newbie Question: Is anyone actually using the Null MX (RFC 7505)?
I think just about everything has been said beyond contacting the operators of the online testing tools and requesting that they update their tool or to take it down. A broken tool is worse that no tool. The is too much out-of-date stuff on the Internet. We should all be doing our little bits to correct it or remove it. Mark > On 26 Feb 2021, at 21:19, Pirawat WATANAPONGSE via NANOG > wrote: > > Dear all, > > > I put the “Null MX” Record (RFC 7505) into one of my domains yesterday, then > those online mail diagnostic tools out there start getting me worried: > > It looks like most of those tools do not recognize the Null MX as a special > case; they just complain that they cannot find the mail server at “.” > [Sarcasm: as if the root servers are going to provide mail service to a mere > mortal like me!] > > Among a few shining exceptions (in a good way) is the good ol’ > https://bgp.he.net/ which does not show that domain as having any MX record. > [maybe it is also wrong, in the other direction?] > > I fear that the MTAs are going to behave that same way, treating my Null MX > as a “misconfigured mail server name” and that my record will mean > unnecessary extra queries to the root servers. [well, minus cache hit] > > So, here comes the questions: > 1. Is there anyone actively using this Null MX? If so, may I please see that > actual record line (in BIND zone file format) just to satisfy myself that I > wrote mine correctly? > 2. Which one makes more sense from the practical point-of-view: having a Null > MX Record for the no-mail domain, or having no MX record at all? > > > Thanks in advance for all advices, > > -- > > Pirawat. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DualStack (CGNAT) vs Other Transition methods
Well then use one of the encapsulating IPv4AAS mechanisms rather than 464XLAT (DS-Lite, MAP-E). They don’t involve translating the payload between IPv4 and IPv6. That said what you are reporting below are implementation bugs. Did you report them to the vendor? Did you install the fix? Rewriting is required as you may have native IPv6 clients rather than clients behind a CLAT on the customer side. > On 25 Feb 2021, at 01:48, Douglas Fischer wrote: > > > > Is this pain you have lived or verified with first hand testing? > > Yep! A lot! > > LOL gamers can be pretty much insistent... > (haha.jpg + haha-crying.jpg) > > And Specifically on SIP/Voip over the Internet, with deep analysis at all the > parts involved. > The most common issue is incoming Calls to SIP endpoints behind 464Xlat using > IPv4 with unidirectional audio. > And several types of causes: > - CPEs receives the RTP-Stream but doesn't Re-Map it correctly to the IPv4 > inside end-point > - Jool receives the RTP-Stream but ignores it and don't map it to the "fake" > v6 address > - Some APPs do (by some crazy reason) the re-write of Session Layer header > to v6 address, and Sip-Proxys ignores it... > > After hours and hours fighting against the lions, we decided: > "Let's keep those clients in Dual-Stak and CGNAT" and it just worked. > > And after that, the obvious conclusions: > - Why will us keep that much options of endpoints connections, if only one > solves all the problems? > - We will need to train the guys on the Dual-Stack/CGNAT Scnario, and > 464Xlat Scenario... Knowing about Danos, about Jool... > - It doesn't scale! > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: CGNAT
IPv4AAS will also work easily for any ISP on the planet. CGNAT requires IPv4 address space between the CGNAT and the customer CPE which doesn’t overlap with that on the Internet nor that behind the CPE (no you can’t use RFC 1918). 100.64/10 gives you ~4M addresses which fit this criteria but that isn’t enough without reuse for the larger ISPs. IPv4AAS uses no IPv4 addresses between the B4/NAT64/… and the CPE. You should also be able to out source IPv4AAS to specialist providers. There is no requirement to run your own hardware. You just populate your DHCPv6/RA/IPV4ONLY.ARPA with the correct information and the traffic will be delivered to the specialist providers. I’m not sure if there are any out there yet but it is a business opportunity for anyone that is already running such boxes. Mark > On 24 Feb 2021, at 09:43, Owen DeLong wrote: > > That’s provably not true if the IPv4AAS implementation is done carefully. > > Owen > > >> On Feb 19, 2021, at 12:11 PM, Tony Wicks wrote: >> >> Because then a large part of the Internet won't work.... >> >> From: NANOG on behalf of Mark >> Andrews >> Sent: Saturday, 20 February 2021, 9:04 am >> To: Steve Saner >> Cc: nanog@nanog.org >> Subject: Re: CGNAT >> >> Why not go whole hog and provide IPv4 as a service? That way you are not >> waiting for your customers to turn up IPv6 to take the load off your NAT box. >> >> Yes, you can do it dual stack but you have waited so long you may as well >> miss that step along the deployment path. >> -- >> Mark Andrews >> >>> On 20 Feb 2021, at 01:55, Steve Saner wrote: >>> >>> >>> We are starting to look at CGNAT solutions. The primary motivation at the >>> moment is to extend current IPv4 resources, but IPv6 migration is also a >>> factor. >>> >>> We've been in touch with A10. Just wondering if there are some alternative >>> vendors that anyone would recommend. We'd probably be looking at a solution >>> to support 5k to 15k customers and bandwidth up to around 30-40 gig as a >>> starting point. A solution that is as transparent to user experience as >>> possible is a priority. >>> >>> Thanks >>> >>> -- >>> Steve Saner >>> ideatek HUMAN AT OUR VERY FIBER >>> This email transmission, and any documents, files or previous email >>> messages attached to it may contain confidential information. If the reader >>> of this message is not the intended recipient or the employee or agent >>> responsible for delivering the message to the intended recipient, you are >>> hereby notified that any dissemination, distribution or copying of this >>> communication is strictly prohibited. If you are not, or believe you may >>> not be, the intended recipient, please advise the sender immediately by >>> return email or by calling 620.543.5026. Then take all steps necessary to >>> permanently delete the email and all attachments from your computer system. >>> >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
STOP USING FONT SIZE SMALL Was: Re: LOAs for Cross Connects - Something like PeeringDB for XC
Really, does anyone here think that it is good form to send email with font size *SMALL*? If your MUA does this by default complain to the developers. The default should be “medium”. If the font is too big on your screen change the magnification *you* choose to display to *yourself*, don’t change the font size you send to everyone else. Mark Well... I must confess that I had some diffi= culty=C2=A0on the first understanding=C2=A0of what is proposed.But = > On 23 Feb 2021, at 04:03, Douglas Fischer wrote: > > Well... I must confess that I had some difficulty on the first understanding > of what is proposed. > > But after the 4 reads, I saw that this "spaghetti" thing is more powerful > than I could imagine! > > > Please correct me if I'm no right: > But it looks like a "crypto sign and publishes" anything related to an > organization. > > Yes, I think that with some effort CrossConnect LOAs can be fitted inside of > it... > I'm not sure if it is the better solution for the scope of LOAs, but > certainly is a valid discussion. > > > What is bubbling in my mind is the standard data model for each type of > different attribute that can exist... > Who will define that? > > > > Em seg., 22 de fev. de 2021 às 12:26, Christopher Morrow > escreveu: > On Mon, Feb 22, 2021 at 9:19 AM Douglas Fischer > wrote: > > > > I believe that almost everyone in here knows that LOAs for Cross Connects > > in Datacenters and Telecom Rooms can be a pain... > > > > I don't know if I'm suggesting something that already exists. > > Or even if I'm suggesting something that could be unpopular for some reason. > > > > But every time I need to deal with some Cross-Connect LOA, and mostly when > > we face some rework on data mistakes, I dream with a "PeeringDB for Cross > > Connects". > > > > are you asking about something like this: > https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-rpki-rsc/ > > Which COULD be used to, as an AS holder: > "sign something to be sent between you and the colo and your intended peer" > > that you could sign (with your rpki stuffs) and your peer could also > sign with their 'rpki stuffs', and which the colo provider could > automatically validate and action upon final signature(s) received. > > > So, this mail is a question and also a suggestion. > > > > > > There is something like an "online notary's office" exclusive for > > Cross-Connect LOAs? > > - Somewhere Organizations can register information authorizing connections > > of Port on their Places (Cages, Racks, etc)... > > > > The RPKI data today doesn't contain information about > cages/ports/patch-panels, so possibly the spaghetti draft isn't a > terrific fit? > > > If it doesn't exist. What would be necessary for that? > > Mostly considering the PeeringDB work model. > > - OpenSource. > > - Free access to the tool, and sponsors to keep the project alive. > > - API driven, with some Web-gui. > > And considering some data-modeling. > > - Most of the data being Open/Public (Organizations, > > Facilities(Datacenters and/or Telecom-Rooms), Presence on Facilities, etc). > > - Access control to Information that can not be public (A-side > > organization, Z-Side Organization, PathPanel/Port). > > And some workflow > > - Cross Connect Requiremento/Authorization from A-Side > > - Acceptance/Authorization from Z-side. > > - Acceptance/Authorization from Facilities involved (could be more than > > one) > > - Execution/Activation notice from Facilities. > > > > > > -- > > Douglas Fernando Fischer > > Engº de Controle e Automação > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: CGNAT
I’m sure the large parts of the world already doing this would disagree. -- Mark Andrews > On 20 Feb 2021, at 07:11, Tony Wicks wrote: > > > Because then a large part of the Internet won't work > > From: NANOG on behalf of Mark > Andrews > Sent: Saturday, 20 February 2021, 9:04 am > To: Steve Saner > Cc: nanog@nanog.org > Subject: Re: CGNAT > > Why not go whole hog and provide IPv4 as a service? That way you are not > waiting for your customers to turn up IPv6 to take the load off your NAT box. > > Yes, you can do it dual stack but you have waited so long you may as well > miss that step along the deployment path. > -- > Mark Andrews > >>> On 20 Feb 2021, at 01:55, Steve Saner wrote: >>> >> >> We are starting to look at CGNAT solutions. The primary motivation at the >> moment is to extend current IPv4 resources, but IPv6 migration is also a >> factor. >> >> We've been in touch with A10. Just wondering if there are some alternative >> vendors that anyone would recommend. We'd probably be looking at a solution >> to support 5k to 15k customers and bandwidth up to around 30-40 gig as a >> starting point. A solution that is as transparent to user experience as >> possible is a priority. >> >> Thanks >> >> -- >> Steve Saner >> ideatek HUMAN AT OUR VERY FIBER >> This email transmission, and any documents, files or previous email messages >> attached to it may contain confidential information. If the reader of this >> message is not the intended recipient or the employee or agent responsible >> for delivering the message to the intended recipient, you are hereby >> notified that any dissemination, distribution or copying of this >> communication is strictly prohibited. If you are not, or believe you may not >> be, the intended recipient, please advise the sender immediately by return >> email or by calling 620.543.5026. Then take all steps necessary to >> permanently delete the email and all attachments from your computer system. >> >
Re: CGNAT
Why not go whole hog and provide IPv4 as a service? That way you are not waiting for your customers to turn up IPv6 to take the load off your NAT box. Yes, you can do it dual stack but you have waited so long you may as well miss that step along the deployment path. -- Mark Andrews > On 20 Feb 2021, at 01:55, Steve Saner wrote: > > > We are starting to look at CGNAT solutions. The primary motivation at the > moment is to extend current IPv4 resources, but IPv6 migration is also a > factor. > > We've been in touch with A10. Just wondering if there are some alternative > vendors that anyone would recommend. We'd probably be looking at a solution > to support 5k to 15k customers and bandwidth up to around 30-40 gig as a > starting point. A solution that is as transparent to user experience as > possible is a priority. > > Thanks > > -- > Steve Saner > ideatek HUMAN AT OUR VERY FIBER > This email transmission, and any documents, files or previous email messages > attached to it may contain confidential information. If the reader of this > message is not the intended recipient or the employee or agent responsible > for delivering the message to the intended recipient, you are hereby notified > that any dissemination, distribution or copying of this communication is > strictly prohibited. If you are not, or believe you may not be, the intended > recipient, please advise the sender immediately by return email or by calling > 620.543.5026. Then take all steps necessary to permanently delete the email > and all attachments from your computer system.
Re: Famous operational issues
> On 17 Feb 2021, at 09:51, Sean Donelan wrote: > > > Biggest internet operational SUCCESS > > 1. Secure Shell (SSH) replaced TELNET. Nearly eliminated an entire class of > security problems on the Internet. But then HTTP took over everything, so a > good news/bad news. > > 2. Internet worms massively reduced by changed default configurations and > default firewalls (Windows XP proved defaults could be changed). Still need > to work on DDOS amplification. > > 3. Head of Line blocking in IX switches (although I miss Stephen Stuart > saying "I'm Sorry" at every NANOG for a decade). Was a huge problem, which is > a non-problem now. > > 4. Classless Inter-Domain Routing and BGP4 changed how Internet routing > worked across the entire backbone, and it worked! Vince Fuller et al rebuilt > the aircraft in flight, without crashing. > > 5. Y2K was a huge suggess because a lot of people fixed things ahead time, > and almost nothing crashed (other than the National Security Agency's > internal systems :-). I'll be retired before Y2038, so that's someone else's > problem. Lets hope you aren’t depending on a piece of medical equipment with a Y2038 issue to keep you alive. Y2038 is everybody's problem! Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DoD IP Space
1993 matches my recollections as well. Network Working Group S. Bradner Internet draftHarvard University A. Mankin NRL September 1994 The Recommendation for the IP Next Generation Protocol > On 16 Feb 2021, at 04:28, Mel Beckman wrote: > > LOL! Well, Mike says “definitely at least 1993”, whereas Wikipedia itself > says that Wikipedia cannot be trusted. Mike, to my knowledge, has never > admitted being wrong. So I’m going with Mike :) > > I think it was Al Gore who first proposed IPv6, right Mike? :) > > -mel beckman > >> On Feb 15, 2021, at 6:36 AM, Kenneth J. Dupuis wrote: >> >> >> 1995? https://en.m.wikipedia.org/wiki/IPv6 >> >> On Feb 11, 2021 8:51 PM, Michael Thomas wrote: >> >> On 2/11/21 5:41 PM, Izaac wrote: >> > >> >> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete >> >> protocol. >> > So, in your mind, IPv4 was "obsolete" in 1996 -- almost three years >> > before IPv6 was even specified? Fascinating. I could be in no way >> > mistaken for an IPv4/NAT apologist, but that one's new on me. >> >> ipv6 was on my radar in the early 90's. it was definitely at least 1993, >> maybe earlier. >> >> Mike >> >> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DoD IP Space
perror("fcntl");
close(fd);
} else if (connect(fd, res->ai_addr, res->ai_addrlen) == -1) {
if (errno != EINPROGRESS) {
perror("connect");
close(fd);
} else {
/*
* Record the information for this descriptor.
*/
fds[i].fd = fd;
fds[i].events = POLLERR | POLLHUP |
POLLIN | POLLOUT;
count++;
i++;
}
} else {
/*
* We connected without blocking.
*/
goto done;
}
if (count == 0)
continue;
do {
if (res->ai_next == NULL)
timeout = -1;
n = poll(fds, i, timeout);
if (n == 0) {
timeout >>= 1;
break;
}
if (n < 0) {
if (errno == EAGAIN || errno == EINTR)
continue;
perror("poll");
fd = -1;
goto done;
}
for (j = 0; j < i; j++) {
if (fds[j].fd == -1 || fds[j].events == 0 ||
fds[j].revents == 0)
continue;
fd = fds[j].fd;
if (fds[j].revents & POLLHUP) {
close(fd);
fds[j].fd = -1;
fds[j].events = 0;
count--;
continue;
}
/* Connect succeeded. */
goto done;
}
} while (timeout == -1 && count != 0);
}
/* We failed to connect. */
fd = -1;
done:
/* Close all other descriptors we have created. */
for (j = 0; j < i; j++)
if (fds[j].fd != fd && fds[j].fd != -1) {
close(fds[j].fd);
}
if (fd != -1) {
/* Restore default blocking behaviour. */
if ((flags = fcntl(fd, F_GETFL)) != -1) {
flags &= ~O_NONBLOCK;
if (fcntl(fd, F_SETFL, flags) == -1)
perror("fcntl");
} else
perror("fcntl");
}
cleanup:
/* Free everything. */
if (fds != NULL) free(fds);
return (fd);
}
See https://users.isc.org/~marka/
Mark
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DoD IP Space
> On 12 Feb 2021, at 12:41, Izaac wrote: > > On Thu, Feb 11, 2021 at 06:29:42AM -0800, Owen DeLong wrote: >> Ridiculous… TCP/IP was designed to be a peer to peer system where each >> endpoint was uniquely >> addressable whether reachable by policy or not. > > I think that is a dramatic over-simplification of the IP design criteria > -- as it was already met by NCP or even a single ethernet segment. But > that's an aside. I recommend that you read rfc1918, with a particular > focus on Section 2, because I'm about to employ its language: > > When dealing at large scale, an incompetent network engineer sees a > network under their control as a single enterprise. Whereas a competent > network engineer recognizes that they are actually operating a > federation of enterprises. They identify the seams, design an > architecture which exploits them, and allocate their scarce resources > appropriately. > >> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete >> protocol. > > So, in your mind, IPv4 was "obsolete" in 1996 -- almost three years > before IPv6 was even specified? Fascinating. I could be in no way > mistaken for an IPv4/NAT apologist, but that one's new on me. IPv4’s address space was known to be too small well before RFC1918. September 1994 https://tools.ietf.org/html/draft-ipng-recommendation-00 -> RFC 1752 July 1995 https://tools.ietf.org/html/draft-ietf-cidrd-private-addr-00 -> RFC 1918 RFC 1918 was deployed as a mechanism to extend the usefulness of IPv4 until IPNG, which became IPv6, was available by reducing the address space pressure on the registries. I knew IPv4 didn’t have enough addresses in 1988 when I got my first IPv4 address allocation. Anyone with a bit of common sense could see that 4B addresses was not enough for the Earth. It was just a matter of time before it would need to be replaced. >> Stop making excuses and let's fix the network > > If you want to "fix the network," tolerate neither incompetence or sloth > from its operators. Educate the former. Encourage the latter. > > -- > . ___ ___ . . ___ > . \/ |\ |\ \ > . _\_ /__ |-\ |-\ \__ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DoD IP Space
> On 12 Feb 2021, at 10:25, Tim Howe wrote: > > On Fri, 12 Feb 2021 09:05:51 +1100 > Mark Andrews wrote: > >> Almost everything you buy today works with IPv6. Even the crappy $50 home >> router does IPv6. > > You're testing very different gear than I am. I have not found > this to be true, and I look harder than most. > > I put every new CPE I come across, high-end and low-end, > against our auto-config dual-stack setup to see how well they work with > v6. Our setup is fairly simple: dhcp v4, dhcp v6 with /56 PD > I also test with static IP configs (/30 or /31 v4, /127 v6 with routed /56 or > /48) > > devices seem to fall into many different categories: > > * Just works. I think I have fewer than 5 tested devices that land here. >Some of them only after I reported bugs and managed to get fixes >(these are my favorite vendors). > * almost just works; minor bugs that can be worked around if you research how > * works if configured a very specific way, but not without ISP cooperation > * can be made to work if you are an expert who will go past the normal > interface. > * works when static, but requires extra help and knowledge to get working > with >dynamic config or just doesn't > * allows you to configure it as if it would work, but doesn't; >sometimes works at first but fails over time (I do long-term stability > testing). > * doesn't even pretend to work (even if the packaging claims support) > * doesn't work. Doesn't claim to. No plans to make it work. Stop asking > us. > > More surprising is that having a big name or being a no-name is > no indication of what category you will fall into. Juniper SRX needs > a little help due to known bug, for example. Another nice, big-name > device starts by sending a malformed packet to my dhcpv6 server and > just fails before getting out of the gate. Ubiquiti ERx was a nice > surprise as far as functionality and configurability, but no support in > the GUI. > > Support is non-existent in SMX solutions even from the biggest > names. This is often a surprise to them when I point it out. > > I'm convinced most people claiming IPv6 support is common > haven't actually tried it with many devices. We support v6 one way or > another on all our Internet services, but it has been a chore, to put it > mildly. CPE hasn't even been the biggest problem. > > —TimH Well I’m glad you are testing so you don’t distribute garbage to your customers. I wish more ISPs would do more of it. There is also plenty of garbage on the IPv4 side as well. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DoD IP Space
> On 12 Feb 2021, at 08:11, Jim Shankland wrote: > > On 2/11/21 6:29 AM, Owen DeLong wrote: >> >>> On Feb 11, 2021, at 05:55 , Izaac wrote: >>> >>> On Wed, Feb 10, 2021 at 04:04:43AM -0800, Owen DeLong wrote: >>>> without creating partitioned networks. >>> Ridiculous. Why would you establish such a criteria? The defining >>> characteristic of rfc1918 networks is that they are partitioned. >>> >>> The ability to recognize and exploit partitions within a network, >>> natural or otherwise, is the measure of competence in a network >>> engineer. >>> >>> Stop making excuses. >> Ridiculous… TCP/IP was designed to be a peer to peer system where each >> endpoint was uniquely >> addressable whether reachable by policy or not. >> >> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete >> protocol. >> >> Stop making excuses and let’s fix the network. >> >> Owen > > TCP/IP wasn't designed; it evolved (OK, a slight exaggeration). The ISO-OSI > protocol stack was designed. Many years ago, I taught a course on TCP/IP > networking. The course was written by someone else, I was just being paid to > present/teach it. Anyway, I vividly remember a slide with bullet points > explaining why TCP/IP was a transitional technology, and would be rapidly > phased out, replaced by the "standard", intelligently designed ISO-OSI stack. > By the time I taught the course, I had to tell the class that every single > statement on that slide was incorrect. In the end, evolution beat out > intelligent design, by a country mile. > > It was probably a couple of years later -- the year definitely started with a > 1 -- that I first heard that IPv4 was being phased out, to be replaced over > the next couple of years by IPv6. We've been hearing it ever since. > > That doesn't mean that we'll be living with IPv4 forever. A peer to peer > system where each endpoint is uniquely addressable is desirable. But in a > world of virtual machines, load balancers, etc., the binding of an IP address > to a particular, physical piece of hardware has long since become tenuous. > IPv4 is evolving into a 48-bit address space for endpoints (32-bit host + > 16-bit port). That development has extended IPv4's useful life by many years. > > There is pain associated with continuing to make IPv4 work. And there is pain > associated with transitioning to IPv6. IPv6 will be adopted when the pain of > the former path is much larger than the pain of the latter path. Saying > "RFC-1918 is a bandaid for an obsolete protocol" is using a normative, rather > than empirical, definition of "obsolete". In the empirical sense, things are > obsolete when people stop using them. Tine will tell when that happens. > > Jim Shankland For most networks there is almost no pain in enabling IPv6. Its reconfigure the routers to announce IPv6 prefixes and you are done. We are 20+ years into IPv6 deployment. Almost everything you buy today works with IPv6. Even the crappy $50 home router does IPv6. 100s of millions of household networks have had IPv6 enabled without the owners of those networks needing to anything other than perhaps swap out a IPv4-only router to one that supports IPv6. Hell lots of those home networks are behind IPv6-only uplinks with the CPE router translating the legacy IPv4 to IPv6 for transport over the IPv6-only uplink. The same happens with mobile phones these days. If you have a phone that was purchased in the last 10 years, give or take, you will most probably be talking to the world over a IPv6-only link. Even Telstra here in Australia is transition their network to IPv6-only, the network in South Australia is IPv6-only with the other states to come. Optus here has been shipping IPv6 capable routers for the last several years with every new install / replacement. Optus haven’t yet enabled IPv6 to the home but the installed base is becoming IPv6 capable. The harder part is making sure every piece of kit works with IPv6 when you want to turn off IPv4 internally but even then you can put that equipment behind bi-directional NAT-64 boxes. You have large parts of the world actively turning off as much IPv4 as they can. Connections to legacy IPv4-only services are being tunnelled over IPv6 either by encapsulation or bi-directional protocol translation. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DoD IP Space
There's no error code. Customer only sees the message "DRM license resquest failed" on LG TV WebOS 3.8 or above. Translation “I use a broken GEOIP database that doesn’t handle IPv6 correctly. If you turn off IPv6 then the request will use IPv4 and it may work.”. Mark > On 25 Jan 2021, at 01:03, Travis Garrison wrote: > > I have personally seen the issue with streaming from a Samsung cell phone and > the Disney+ app to a Google chrome cast and a regular not-smart TV. > > Travis > > -Original Message- > From: NANOG On Behalf Of > Doug Barton > Sent: Friday, January 22, 2021 5:30 PM > To: nanog@nanog.org > Subject: Re: DoD IP Space > > The KB indicates that the problem is with the "LG TV WebOS 3.8 or above." > > Doug > > (not speaking for any employers, current or former) > > > On 1/22/21 12:42 PM, Mark Andrews wrote: >> Disney should hire some proper developers and QA team. >> >> RFC 1123 instructed developers to make sure your products handled >> multi-homed servers properly and dealing with one of the addresses being >> unreachable is part of that. It’s not like the app can’t attempt to a >> stream from the IPv6 address and if there is no response in 200ms start a >> parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop >> the IPv4 stream Happy Eyeballs is just a specific case of multi-homed >> servers. >> >> QA should have test scenarios where the app has a dual stack network and the >> servers are silently untraceable over one then the other transport. It >> isn’t hard to do. Dealing with broken networks is something every >> application should do. >> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Nice work Ron
Majority only means >50% when there are 2 parties. When there is more than 2 parties the majority can be less than 50%. When there is more than 2 parties, one uses the term “absolute majority” to indicate >50%. There are more than 2 RIRs. If 40% of address are used in LACNIC, 30% in APNIC and 30% in RIPE then the majority of addresses by region are in the LACNIC region. -- Mark Andrews > On 22 Jan 2021, at 23:48, JORDI PALET MARTINEZ via NANOG > wrote: > > > > El 22/1/21 13:25, "NANOG en nombre de Masataka Ohta" > mo...@necom830.hpcl.titech.ac.jp> escribió: > >JORDI PALET MARTINEZ via NANOG wrote: > >> My proposal added the clarification that "majority" is understood as "over >> 50%". > >And the proposal is denied to be unreasonable by Toma and, more >aggressively, by me. > >So? > > [Jordi] The proposal, on this specific point, only made a "clarification", > didn't mean an actual policy change. The existing policy already had > "majority", so unless you believe that majority means something different > than more than 50% (in the context of the full text), the change was > "neutral". If anyone disagree with a policy in any region, MUST DO SOMETHING > ABOUT THAT: "bring the problem to the policy list, discuss it with the > community, and if needed make a policy proposal". In Spain we say "barking > dogs seldom bite" and in this context means "if you complain, but don't act, > then you have nothing to do". > >> The staff was already interpreting the policy like that, because >> usually when you say majority, you mean more than half. Do you >> agree on that? > >How can you ask such a question. already opposed by Toma and, >more aggressively, by me, to me? > > [Jordi] I think if we don't agree what means majority, then it is difficult > to get us understanding among ourselves, so that's why I'm asking if you > agree that in English, majority means more than half. In Spanish it means > that. > >My point is that locality requirement, whether it is 50% or 40%, is >impractical and, with operational practices today, is not and can >not be enforced. > > [Jordi] Then you need to come to the right mailing list and discuss that with > the community. It is not me who decides that! > >>> The community decided that my proposal to add the explicit "footnote" > >Then, the "footnote" might be applicable to *SOME* part of "the >community" but definitely not beyond it. > > [Jordi] A footnote in the policy manual is a clarification to the manual > text, and of course *applies* to anyone who signs a contract with the RIR to > obtain resources. > >Masataka Ohta > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > >
Re: DoD IP Space
Big networks do run out of IPv4 space. It doesn’t require incompetence just lots of devices. That said if the devices where purchased in the last 2 decades they should support IPv6. How many devices do you think a large car manufacture has on the shop floor? Remember some run their own bus services to move staff around the factory. -- Mark Andrews > On 23 Jan 2021, at 07:42, Mark Andrews wrote: > > Disney should hire some proper developers and QA team. > > RFC 1123 instructed developers to make sure your products handled multi-homed > servers properly and dealing with one of the addresses being unreachable is > part of that. It’s not like the app can’t attempt to a stream from the IPv6 > address and if there is no response in 200ms start a parallel attempt from > the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy > Eyeballs is just a specific case of multi-homed servers. > > QA should have test scenarios where the app has a dual stack network and the > servers are silently untraceable over one then the other transport. It isn’t > hard to do. Dealing with broken networks is something every application > should do. > -- > Mark Andrews > >> On 23 Jan 2021, at 01:28, Travis Garrison wrote: >> >> What's all your opinion when company's such as Disney actively recommend >> disabling IPv6? They are presenting it as IPv6 is blocking their app. We all >> know that isn’t possible. Several people have issues with their app and >> Amazon firesticks. I use my phone and a chromecast and I see the issues when >> IPv6 is enabled. We are in the testing phase on rolling out IPv6 on our >> network. All the scripts are ready, just trying to work through the few >> issues like this one. >> >> https://help.disneyplus.com/csp?id=csp_article_content_kb_id=c91af021dbe46850b03cc58a139619ed >> >> Thank you >> Travis >> >> >> >> -Original Message- >> From: NANOG On Behalf Of >> Mark Andrews >> Sent: Thursday, January 21, 2021 7:45 PM >> To: Sabri Berisha >> Cc: nanog >> Subject: Re: DoD IP Space >> >> IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming. >> Every data set says the same thing. It may not be coming as fast as a lot >> of us would want or actually think is reasonable as ISP’s are currently >> being forced to deploy CGNs (NAT44 and NAT64) because there are laggards >> that are not doing their part. >> >> If you offer a service over the Internet then it should be available over >> IPv6 otherwise you are costing your customers more to reach you. CGNs are >> not free. >> >> Mark >> >>>> On 22 Jan 2021, at 06:07, Sabri Berisha wrote: >>> >>> - On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth a...@andyring.com wrote: >>> >>> Hi, >>> >>>> I’m sure we all remember Y2k >>> >>> Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I >>> upgraded many bioses in many office buildings in the months leading up to >>> it... >>> >>>> I’d love to see a line in the concrete of, say, January 1, 2025, >>>> whereby IPv6 will be the default. >>> >>> The challenge with that is the market. Y2K was a problem that was >>> existed. It was a brick wall that we would hit no matter what. The >>> faulty code was released years before the date. >>> >>> We, IETF, or even the UN could come up with 1/1/25 as the date where >>> we switch off IPv4, and you will still find networks that run IPv4 for >>> the simple reason that the people who own those networks have a choice. >>> With Y2K there was no choice. >>> >>> The best way to have IPv6 implemented worldwide is by having an >>> incentive for the executives that make the decisions. From experience, >>> as I've said on this list a few times before, I can tell you that >>> decision makers with a limited budget that have to choose between a >>> new revenue generating feature, or a company-wide implementation of >>> IPv6, will choose the one that's best for their own short-term interests. >>> >>> On that note, I did have a perhaps silly idea: One way to create the >>> demand could be to have browser makers add a warning to the URL bar, >>> similar to the HTTPS warnings we see today. If a site is IPv4 only, >>> warn that the site is using deprecated technology. >>> >>> Financial incentives also work. Perhaps we can convince Mr. Biden to >>> give a .5% tax cut to corporations that fully implement v6. That will >>> create some bonus targets. >>> >>> Thanks, >>> >>> Sabri >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>
Re: DoD IP Space
Disney should hire some proper developers and QA team. RFC 1123 instructed developers to make sure your products handled multi-homed servers properly and dealing with one of the addresses being unreachable is part of that. It’s not like the app can’t attempt to a stream from the IPv6 address and if there is no response in 200ms start a parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy Eyeballs is just a specific case of multi-homed servers. QA should have test scenarios where the app has a dual stack network and the servers are silently untraceable over one then the other transport. It isn’t hard to do. Dealing with broken networks is something every application should do. -- Mark Andrews > On 23 Jan 2021, at 01:28, Travis Garrison wrote: > > What's all your opinion when company's such as Disney actively recommend > disabling IPv6? They are presenting it as IPv6 is blocking their app. We all > know that isn’t possible. Several people have issues with their app and > Amazon firesticks. I use my phone and a chromecast and I see the issues when > IPv6 is enabled. We are in the testing phase on rolling out IPv6 on our > network. All the scripts are ready, just trying to work through the few > issues like this one. > > https://help.disneyplus.com/csp?id=csp_article_content_kb_id=c91af021dbe46850b03cc58a139619ed > > Thank you > Travis > > > > -Original Message- > From: NANOG On Behalf Of > Mark Andrews > Sent: Thursday, January 21, 2021 7:45 PM > To: Sabri Berisha > Cc: nanog > Subject: Re: DoD IP Space > > IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming. > Every data set says the same thing. It may not be coming as fast as a lot of > us would want or actually think is reasonable as ISP’s are currently being > forced to deploy CGNs (NAT44 and NAT64) because there are laggards that are > not doing their part. > > If you offer a service over the Internet then it should be available over > IPv6 otherwise you are costing your customers more to reach you. CGNs are > not free. > > Mark > >> On 22 Jan 2021, at 06:07, Sabri Berisha wrote: >> >> - On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth a...@andyring.com wrote: >> >> Hi, >> >>> I’m sure we all remember Y2k >> >> Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I >> upgraded many bioses in many office buildings in the months leading up to >> it... >> >>> I’d love to see a line in the concrete of, say, January 1, 2025, >>> whereby IPv6 will be the default. >> >> The challenge with that is the market. Y2K was a problem that was >> existed. It was a brick wall that we would hit no matter what. The >> faulty code was released years before the date. >> >> We, IETF, or even the UN could come up with 1/1/25 as the date where >> we switch off IPv4, and you will still find networks that run IPv4 for >> the simple reason that the people who own those networks have a choice. With >> Y2K there was no choice. >> >> The best way to have IPv6 implemented worldwide is by having an >> incentive for the executives that make the decisions. From experience, >> as I've said on this list a few times before, I can tell you that >> decision makers with a limited budget that have to choose between a >> new revenue generating feature, or a company-wide implementation of >> IPv6, will choose the one that's best for their own short-term interests. >> >> On that note, I did have a perhaps silly idea: One way to create the >> demand could be to have browser makers add a warning to the URL bar, >> similar to the HTTPS warnings we see today. If a site is IPv4 only, >> warn that the site is using deprecated technology. >> >> Financial incentives also work. Perhaps we can convince Mr. Biden to >> give a .5% tax cut to corporations that fully implement v6. That will >> create some bonus targets. >> >> Thanks, >> >> Sabri > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
Re: Nice work Ron
I would think as long as most of the LACNIC addresses are used in region they are fine. Without going and reading the policies in full, I would expect that there would be a exception for multinationals to allow them to get addresses from wherever they held a significant usage. -- Mark Andrews > On 22 Jan 2021, at 22:09, Töma Gavrichenkov wrote: > > > Peace, > > On Fri, Jan 22, 2021, 12:27 PM JORDI PALET MARTINEZ via NANOG: >> The numbering resources under the stewardship of LACNIC must be distributed >> among organizations legally constituted within its service region >> [COBERTURA] and mainly *serving networks and services operating in this >> region. External clients connected directly to main infrastructure located >> in the region are allowed. >> >> *“Mainly” is understood to mean more than 50%. > > > Just out of curiosity, I wonder what would happen if all the RIRs implemented > the same policy. What if a company does business across the globe and any > particular ICANN ASO region is only responsible e.g. of 40% of revenue at > most? > > -- > Töma
Re: DoD IP Space
IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming. Every data set says the same thing. It may not be coming as fast as a lot of us would want or actually think is reasonable as ISP’s are currently being forced to deploy CGNs (NAT44 and NAT64) because there are laggards that are not doing their part. If you offer a service over the Internet then it should be available over IPv6 otherwise you are costing your customers more to reach you. CGNs are not free. Mark > On 22 Jan 2021, at 06:07, Sabri Berisha wrote: > > - On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth a...@andyring.com wrote: > > Hi, > >> I’m sure we all remember Y2k > > Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I upgraded > many > bioses in many office buildings in the months leading up to it... > >> I’d love to see a line in the concrete of, say, January 1, 2025, whereby IPv6 >> will be the default. > > The challenge with that is the market. Y2K was a problem that was existed. It > was > a brick wall that we would hit no matter what. The faulty code was released > years > before the date. > > We, IETF, or even the UN could come up with 1/1/25 as the date where we > switch off > IPv4, and you will still find networks that run IPv4 for the simple reason > that > the people who own those networks have a choice. With Y2K there was no choice. > > The best way to have IPv6 implemented worldwide is by having an incentive for > the > executives that make the decisions. From experience, as I've said on this > list a > few times before, I can tell you that decision makers with a limited budget > that > have to choose between a new revenue generating feature, or a company-wide > implementation of IPv6, will choose the one that's best for their own > short-term > interests. > > On that note, I did have a perhaps silly idea: One way to create the demand > could > be to have browser makers add a warning to the URL bar, similar to the HTTPS > warnings we see today. If a site is IPv4 only, warn that the site is using > deprecated technology. > > Financial incentives also work. Perhaps we can convince Mr. Biden to give a > .5% > tax cut to corporations that fully implement v6. That will create some bonus > targets. > > Thanks, > > Sabri -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNSSEC failures for www.cdc.gov
This has been noted many times over the last 3 months on multiple lists but it looks like the CDC have made things worse recently. All the servers for cdc.gov now return unsigned answers for akam.cdc.gov. Previously only 3 of the six where returning bad answers, the other 3 where returning referrals. responsibledisclos...@hhs.gov, If you are going to have parent servers for a zone serve the child zone (akam.cdc.gov) you need to ensure that they serve the CORRECT content. I suggest that you find someone that is competent to configure CDC.GOV's DNS servers as whomever is currently doing it is out of their depth. Mark > On 15 Jan 2021, at 11:04, John R. Levine wrote: > > I see that www.cdc.gov is a CNAME for www.akam.cdc.gov. which in turn is a > CNAME for www.cdc.gov.edgekey.net. > > But it appears that while www.cdc.gov is signed, www.akam.cdc.gov in > the same zone on the same server is not. Huh? What? > > $ dig @ns1.cdc.gov www.cdc.gov +dnssec > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27760 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;www.cdc.gov. IN A > > ;; ANSWER SECTION: > www.cdc.gov. 300 IN CNAME www.akam.cdc.gov. > www.cdc.gov. 300 IN RRSIG CNAME 7 3 300 20210119032636 > 20210109024411 9155 cdc.gov. > FxxFahuaCEw8gUXH6CuiqUgXWzPDkQlY0HTtJwjMAVMS7Lc3VOelfkmT > hT/ZmDpdUiYsNr7YXMUNhF4Ii/49lu5AGTxwlu9dtX66HSK+8vf/FnzF > XUZrC0UXFEPLl0K+pmdLEiUpiHDq3lIwAfKNmiOrwlPvtXttqDs+JC1d w6A= > www.akam.cdc.gov. 3600IN CNAME www.cdc.gov.edgekey.net. > > > $ dig @ns1.cdc.gov www.akam.cdc.gov +dnssec > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59380 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;www.akam.cdc.gov.IN A > > ;; ANSWER SECTION: > www.akam.cdc.gov. 3600IN CNAME www.cdc.gov.edgekey.net. > > > Regards, > John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: nike.com->nike.com/ca
I fail to see how this is a NANOG issue. Go to the bottom left of the page and select the correct region. > On 7 Jan 2021, at 08:41, Kain, Becki (.) wrote: > > At home, using 8.8.8.8, if I goto www.nike.com, I get rerouted to > nike.com/ca. I cleared the dns cache (I’m running Catalina macos) and > rebooted just because. Anyone else seen a weirdism on this? thanks > > Becki in Detroit -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: CNAME records in place of A records
> On 9 Nov 2020, at 16:35, Matt Palmer wrote:
>
> On Sun, Nov 08, 2020 at 08:01:12PM -0500, Rob McEwen wrote:
>> except - don't forget that the root of a domain (that domain without "www."
>> or any other label) - cannot have a CNAME as the "A" record - fwiw...
>
> Yes. I didn't think that was something that needed to be explained on NANOG,
> though.
Given the number of ISPs (and others) that ask ISC to support CNAME at the APEX
to whom we have to politely say:
“No. It is not permitted by this part of RFC 1034.”
It’s well worth reiterating.
> - Matt
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: CNAME records in place of A records
> On 9 Nov 2020, at 12:01, Rob McEwen wrote: > > On 11/8/2020 7:10 PM, Matt Palmer wrote: >> On Fri, Nov 06, 2020 at 05:07:26AM -0500, Dovid Bender wrote: >>> Sorry if this is a bit OT. Recently several different vendors (in >>> completely different fields) where they white label for us asked us to >>> remove A records that we have going to them and replace them with CNAME >>> records. Is there anything *going around* in the security aranea that has >>> caused this? >> The closest thing to a *security* issue I can think of is IP agility in the >> face of DDoS attacks -- most booter-style attacks are dumb as rocks, and >> null-routing the target IP and moving all the customers on that IP to >> another one is the easiest solution. >> >> However, there are many *other* great reasons to get customers to CNAME onto >> their SaaS vendors, including: >> >> * No need to coordinate routine renumbering events; >> * IPv6 support; >> * CAA record (SSL cert issuance) support; and >> * no doubt a bunch of other reasons I've forgotten for the moment. >> >> Basically, if you sign up for a SaaS that uses your own domain and they >> *don't* give you a CNAME target to point at, I'd be very cautious, because >> they're either *very* new to the game, or they're probably also >> operationally deficient in a lot of other areas, too. >> >> - Matt > > > except - don't forget that the root of a domain (that domain without "www.” > or any other label) - cannot have a CNAME as the "A" record - fwiw… Which is why there are HTTPS and SVCB records coming and SRV exists. You don’t need CNAME, you need indirection. Indirection does require a small amount of client support. > -- > Rob McEwen, invaluement > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Vint Cerf & Interplanetary Internet
It wouldn’t be NANOG. Perhaps LUNOG or MOONOG. > On 22 Oct 2020, at 14:07, scott weeks wrote: > > > *From:* NANOG on behalf of Rod > Beck >> https://www.quantamagazine.org/vint-cerfs-plan-for-building-an-internet-in-space-20201021/ > > > On 10/21/20 2:27 PM, Suresh Ramasubramanian wrote: > > Right. This means we are going to catch a spaceship for a future nanog / have > interplanetary governance federation debates with space aliens from Andromeda, > and we will finally run out of v6 and ipv9 will rule the roost while there’s a > substantial aftermarket + hijack scene going on for the last remaining v6 > blocks. > > > > More like IP to Nokia's new cell network on the moon: > > https://www.theguardian.com/science/2020/oct/20/talking-on-the-moon-nasa-and-nokia-to-install-4g-on-lunar-surface > (Everyone on the moon will want to have access to LOL cats!) > > Or... using DTN (https://datatracker.ietf.org/wg/dtn/about) to reach Mars and > other > planets by being relayed through communications relay satellites similar to > the > Mars Telecommunication Orbiter (canceled), Mars Odyssey or Mars > Reconnaissance Orbiter spacecraft. > > Or... IP to robots visiting other non-planet objects in the solar system like > comets/asteroids: > https://spacenews.com/osiris-rex-touches-down-on-asteroid > https://www.bbc.com/news/science-environment-47293317 > > Or... > > The IPI idea has been around for a long time now: > https://en.wikipedia.org/wiki/Interplanetary_Internet > > The main question is will NANOG On The Road meet on the moon? I missed > the only Hawaii one, so maybe I could make the moon one! > > scott -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Virginia voter registration down due to cable cut
It’s not the population. It’s the number of positions/things you are voting for. New Zealand doesn’t vote for sheriffs, judges, mayors etc. AFAIK so there is much less to count. More population should lead to more polling stations. These need to be collated but that is a relatively quick job compared to counting the votes. Timezone spread also makes the night longer. If you have a result within 2 hours of the Hawaiian polls closing you are on par. -- Mark Andrews > On 17 Oct 2020, at 07:49, Alain Hebert wrote: > > Hi, > > Beside being: > > . a country with 1/10th of the population; > > . centralized voting rules; > > . ... > > > PS: And there is a lot in that about the (publicly) unreal > amount of insanity being pulled by the GOP this year. > > - > Alain Hebertaheb...@pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 > On 2020-10-16 02:36, Sean Donelan wrote: >> On Tue, 13 Oct 2020, Valdis Klētnieks wrote: >>> my reaction was more like >>> >>> Surprise, surprise, surprise... >>> >> >> S.N.A.F.U. >> >> Other SNAFUs, Georgia had technical problems with its voter database systems >> during the first couple of days of early voting. Expect all sorts of minor >> problems throughout the election and afterwards. Nonetheless they are >> unlikely to significantly impact the results (hopefully), but will generate >> lots of noise. >> >> Its not just underfunded state I.T. systems. Even very large social media >> companies can have technical Oopsies. Again, hopefully Twitter won't fall >> down again during the evening of November 3rd. The digeratti will lose >> thier minds. >> >> Even if Twitter or another major social media platform does go belly-up, >> most likely it will be a normal technical problem. Wishing the FBI & CISA & >> OGAs watch officers a very boring night on November 3rd. >> >> >> >> In other news, New Zealand is having national elections this weekend. New >> Zealand is usually ranked in the top 10 best election administrations >> worldwide. NZ expects to have the majority of ballots counted within 2 hours >> of their polls closing on Saturday evening. >> >> Jealous of the Kiwis and their competently run elections. :-) >
Re: Ingress filtering on transits, peers, and IX ports
> On 15 Oct 2020, at 04:09, Casey Deccio wrote: > > >> On Oct 13, 2020, at 8:49 PM, Chris Adams wrote: >> >> Once upon a time, Eric Kuhnke said: >>> Considering that one can run an instance of an anycasted recursive >>> nameserver, under heavy load for a very large number of clients, on a $600 >>> 1U server these days... I wonder what exactly the threat model is. >> >> A customer forwarded one of these notices to us - looked like it's about >> recursive DNS cache poisoning. > > In part, yes. More generally, it's about allowing spoofed-source packets in > your front door, appearing to be from your own network, and what a bad actor > could do with them. The probes from the experiment were harmless. But if > there were malicious intent, this access could facilitate cache poisoning, > depending on your DNS server configuration. > >> It's been a while since I looked >> closely, but I thought modern recursive DNS software was pretty >> resistant to that, and anyway, the real answer to that is DNSSEC. > > It is. But DNSSEC requires support both on the side of the resolver > (validation enabled) and the authoritative server (zone signed). Adoption is > still far from universal. There are efforts to improve that, but it can't be > your only hope, in its current state. > > But, perhaps more importantly, cache poisoning is not the only concern. > Other vulnerable DNS (for example) configurations might be exploited by a > single packet being received and acted on as "trusted”. I know Casey knows this, but to the rest of you, this is why TSIG, SIG(0) and DNS COOKIE where invented. IP addresses, especially IP addresses on UDP packets, are not trustworthy. If you are not using one or more of these when sending a query you should be updating your DNS software. If you are a ISP that is purchasing CPEs you should be requiring that the CPE uses these by default. If you are purchasing other equipment it also should be using it by default. Fixing security issues requires everyone to play their part. +10% (and growing) of the worlds authoritative DNS servers support DNS COOKIE. I don’t have measurements for recursive servers. For it to be of benefit the clients also need to be sending requests with an DNS COOKIE option present. Many recursive servers send this option by default as well. The option was design to allow independent upgrade of servers and clients to occur. The only coordination required is within a anycast server cluster where all the servers need to support the option and use a common shared secret and algorithm. Clients will workaround shared secret / algorithm misconfigurations. Mark >> I could be wrong, but getting a scary-sounding OMG SECURITY ALERT email > > Crafting wording in an alert email such that it should both be taken > seriously and it doesn't sound too dramatic is hard. We have gotten many > positive responses. But we've also gotten some *meh*. In the end we made a > choice about whether individual reach-out was important and worth the effort, > ahead of future publication and presentation. We decided that it was. Many > operators have agreed with us. But I get that not everyone will feel the > same about it. > >> from some group I've never heard of (and haven't AFAIK engaged the >> community about their "new" attack, scans, or notices) > > I suppose it depends on your definition of "engage the community". I think > that's what we're doing right now. We're also no stranger to NANOG (though > perhaps more of a lurker on the mailing list). But community is a much > broader term. And anyway, there is some order to this whole thing, and > broader announcements will come later. > > Cheers, > Casey -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IP addresses on subnet edge (/24)
You may want to do traceroute using syn/ack packets to find the offending piece of equipment (may require modifying traceroute to set the syn and ack). > On 15 Sep 2020, at 07:25, Andrey Khomyakov wrote: > > TL;DR I suspect there are middle boxes that don't like IPs ending in .255. > Anyone seen that? > > Folks, > We are troubleshooting a strange issue where some of our customers cannot > establish a successful connection with our HTTP front end. In addition to > checking the usual things like routing and interface errors and security > policy configurations, hopening support tickets with the load balancer vendor > so far all to no avail, we did packet captures. > Based on the packet captures we receive a SYN, we reply with SYN-ACK, but the > client never actually receives that SYN-ACK. In a different instance the > 3-way completes, followed by TLS client hello to us, we reply with TLS Server > Hello and that server hello never makes it to the client. > And again, this is only affecting a small subset of customers thus suggesting > it's not the load balancer or the edge routing configuration (in fact we can > traceroute fine to the customer's IP). > So far the only remaining theory that remains is that there are middle boxes > out there that do not like IPs ending in .255. The service that the clients > can't get to is hosted on two IPs ending in .255 > Let's just say they are x.x.121.255 and x.x.125.255. We even stood up a basic > "hello world" web server on x.x.124.255 with the same result. Standing up the > very same basic webserver on x.x.124.250 allows the client to succeed. > So far we have a friendly customer who has been working with us on > troubleshooting the issue and we have some pcaps from the client's side > somewhat confirming that it's not the customer's system either. > This friendly customer is in a small 5 people office with Spectrum business > internet (that's the SYN-ACK case). The same customer tried hopping on his > LTE hotspot which came up as Cellco Partnership DBA Verizon Wireless with the > same result (that's the TLS server hello case). That same customer with the > same workstation drives a town over and he can get to the application fine > (we are still waiting for the customer to let us know what that source IP is > when it does work). > Before you suggest that those .255 addresses are broadcasts on some VLAN, > they are not. They are injected as /32s using a routing protocol, while the > VLAN addressing is all RFC1918 addressing. > > --Andrey -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Ipv6 help
> On 27 Aug 2020, at 17:33, Brian Johnson wrote: > > If an ISP provides dual-stack to the customer, then the customer only uses > IPv4 when required and then will only use NAT444 to compensate for a lack of > IPv4 address space when an IPv4 connection is required. What am I missing? Lots of assumptions people are making about how equipment is configured which is causing people to talk past each other. >> On Aug 27, 2020, at 1:20 AM, Mark Andrews wrote: >> >> >> >>> On 27 Aug 2020, at 15:58, Bjørn Mork wrote: >>> >>> 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 and I can do the same over sub >>>> ratio under both circumstance. Tell me how the math is different. >>> >>> Because NAT64 implies DNS64, which avoids NATing any dual stack service. >>> This makes a major difference today. >> >> Only if you don’t have a CLAT installed and for home users that is suicide >> at there is too much IPv4 only equipment. >> >> What really pushes traffic to IPv6 is that hosts prefer IPv6 by default. >> This >> works as long as the clients see a dual stack network. >> >> And no NAT64 does not imply DNS64. You can publish a ipv4only.arpa zone with >> the mappings for the NAT64. There are now also RA options for publishing >> these >> mappings. There are also DHCPv6 options. >> >> Mark >> >>> Bjørn >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Ipv6 help
> On 27 Aug 2020, at 15:58, Bjørn Mork wrote: > > 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 and I can do the same over sub >> ratio under both circumstance. Tell me how the math is different. > > Because NAT64 implies DNS64, which avoids NATing any dual stack service. > This makes a major difference today. Only if you don’t have a CLAT installed and for home users that is suicide at there is too much IPv4 only equipment. What really pushes traffic to IPv6 is that hosts prefer IPv6 by default. This works as long as the clients see a dual stack network. And no NAT64 does not imply DNS64. You can publish a ipv4only.arpa zone with the mappings for the NAT64. There are now also RA options for publishing these mappings. There are also DHCPv6 options. Mark > Bjørn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Ipv6 help
And in the end it will come down to a clueful customer taking Sony to task. with the backing of a government for selling a product which is not fit for purpose. They have paid to play games and if Sony is blocking them because they happen to be on a CGN, which they have no control over, then Sony is in breach of lots of consumer laws around the planet. No EULA trumps the law. Here is Australia it would be the ACCC that would take them to task. -- Mark Andrews > On 27 Aug 2020, at 04:38, Brian Johnson wrote: > > I‘m going further... They shouldn’t have to care. Sony should understand > what they are delivering and the circumstance of that. That they refuse to > serve some customers due to the technology they use is either a business > decision or a faulty design. The end-customer (gamer) doesn’t care. They just > want to play. > > >> On Aug 26, 2020, at 1:31 PM, Mark Tinka wrote: >> >> >> >>> On 26/Aug/20 20:20, Brian Johnson wrote: >>> >>> Either way. Nothing you can do in the network will help Sony enable IPv6 >>> capability, Or to serve their users even if using a technology that they do >>> not like. >> >> Agreed. >> >> The problem is gaming customers that neither care for nor know about how >> NAT444 and/or IPv6 play (no pun intended) here. >> >> Mark. >
Re: Ipv6 help
How doesn’t it work? As long as IPv6 is *on* NAT444 + dual stack has the same properties (or better, less PMTUD issues) as turning on 464XLAT in the CPE. Traffic shifts to IPv6 due to hosts preferring IPv6. You can still disable sending RA’s in either scenario. Mark > On 26 Aug 2020, at 16:51, JORDI PALET MARTINEZ via NANOG > wrote: > > No, this doesn't work > > The point your're missing (when I talked before about putting all the costs > to make a good calculation of each case and then replacing CPEs become > actually cheaper) is that you need more IPv4 addresses in CGN than in NAT64 > and further to that, in CGN, your IPv4 pools sooner or later become blocked > by PSN (unless you don't have gammers among your customers). > > El 25/8/20 22:42, "NANOG en nombre de Brian Johnson" > brian.john...@netgeek.us> escribió: > >I usually solve this problem by designing for NAT444 and dual-stack. This > solves both problems and allows for users to migrate as they are able/need > to. If you try and force the change, you will loose users. > > >> On Aug 25, 2020, at 3:15 PM, Brandon Martin wrote: >> >> 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 network edge router (I >> provide the ONT, though, and I provide an edge router that works and most >> users do take it), but it can be tough to ensure users have something that >> supports all the right modern features and can be configured via standard >> means. >> >> It would be nice if the consumer router industry could get its collective >> act together and at least come up with some easy-ish to understand feature >> support table that customers can match up with their service provider's list >> of needs. The status quo of a list of devices that work right (which is of >> course often staggeringly short if you're doing any of these modern >> transition mechanisms) that needs constant updating and may not be easily >> available is not ideal. >> >> Heck just having a real, complete list of supported features on the model >> support page on their website would be an improvement... >> -- >> Brandon Martin > > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP
> On 8 Jul 2020, at 03:23, JORDI PALET MARTINEZ via NANOG > wrote: > > Hi Douglas, > > There was, long time ago, something developed by ISC, but I think never > completed and not updated … ISC did a DS-LITE implementation called AFTR. This can be found at: https://ftp.isc.org/isc/aftr/ > 464XLAT is always a solution and becomes much cheaper, than CGN from vendors, > even if you need to replace the CPEs. I’m doing that now with 25.000.000 > subscribers … (slowed down by the Covid-19). > > Regards, > Jordi > > @jordipalet > > > > > > El 7/7/20 18:44, "NANOG en nombre de Douglas Fischer" > fischerdoug...@gmail.com> escribió: > > We are looking for a CGNAT solution open source based. > > Yep, I know that basic CGNAT can be done with iptables / nftables, or PF / > IPFILTER / IPFW. > > But I only know Open Source CGNAT recipes with predefined public-ports <-> > private IPs mapping. > > What It brings two types of issues: > A - The need to overprovision the number of private IPs (Considering Multiple > BNGs behind the CGN). > B - The inability of those basic recipes to deal with incoming auxiliary > connections of p2p protocols (mostly used by games). > > Te market solutions that I've dealt with solves those issues beautifully. > a - Bulk-Port Allocation - BPA, avoid the need overprovisioning private > address that is not being used, and give us an excellent rate between public > IPv4 Address vs Private IP Address. > b - The support of a framework of protocols(Ex.: UPnP, PCP, EIM/EIF, NAT-PMP, > etc...) ensure an acceptable quality of experience to end-users. > > But, the market solution brings also some down-sides... > - The cost, evidently. > - The need for detouring the traffic that doesn't need CGNAT(Internal CDNs, > Internal Servers, etc), to stay on the license limits of those boxes, > sometimes brings some issues. > > So, I and some friends are(for a long time) looking for an OpenSource > solution that can give us something near what the market solutions give. > > Any of you guys ave some suggestions for that? > > > P.S.: Yes, I know that IPv6 is the only real solution for that, but until > there, our customers still want to access a lot os p2p content(mostly audio > in game rooms, sip calls, and things like that.) > > P.S.2: Yes, I also know that 464 could be a good possibility, but is not > possible in this scenario. > > -- > Douglas Fernando Fischer > Engº de Controle e Automação > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: mail admins?
And it is still on going. Just got 4 of these. Mark > On 22 Apr 2020, at 08:34, Bryan Fields wrote: > > On 4/21/20 6:28 PM, Bryan Fields wrote: >> On 4/21/20 5:11 PM, William Herrin wrote: >>> Howdy,, >>> >>> How do we contact the nanog mail admins? I looked at >>> https://archive.nanog.org/list and https://archive.nanog.org/list/faq >>> but apparently someone thought it'd be clever to redact all the email >>> addresses from that page. "Questions should be directed to[email >>> protected]." >> >> It's a mailman list, so nanog-ow...@nanog.org should work. If not reach out >> to the communications committee. >> >> Now i did try searching the website for the communications committee, and I >> can't tell if it's still a thing. The one time I actually interacted with >> them, I just emailed Matt Griswold, but that was years ago. > > I'm also assuming this is about the 5 bounce messages I got from this last > message to the list "Message to 9728466...@email.uscc.net failed." > > Lets see if it honors "Reply-to:" :) > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Abuse Desks
The machines that are ssh probing are probably doing other stuff. Take the win that you have been informed about a compromised machine and get it cleaned / quarantined. -- Mark Andrews > On 30 Apr 2020, at 06:20, Bottiger wrote: > > > It is rather easy to block SSH cracking attempts from your own side. Rarely > do they put any significant load on your network or computer. > > I would sympathize with this except for the fact that abuse desks won't even > respond to DDoS attacks, something that can't be fixed on your own end > without spending a lot of money. > > That needs to be fixed first before worrying about password cracking. > >> On Tue, Apr 28, 2020 at 8:58 AM Mike Hammett wrote: >> I noticed over the weekend that a Fail2Ban instance's complain function >> wasn't working. I fixed it. I've noticed a few things: >> >> 1) Abusix likes to return RIR abuse contact information. The vast majority >> are LACNIC, but it also has kicked back a couple for APNIC and ARIN. When I >> look up the compromised IP address in Abusix via the CLI, the APNIC and ARIN >> ones return both ISP contact information and RIR information. When I look >> them up on the RIR's whois, it just shows the ISP abuse information. Weird, >> but so rare it's probably just an anomaly. However, almost everything I see >> in LACNIC's region is returned with only the LACNIC abuse information when >> the ones I've checked on LACNIC's whois list valid abuse information for >> that prefix. Can anyone confirm they've seen similar behavior out of Abusix? >> I reached out to them, but haven't heard back. >> 2) Digital Ocean hits my radar far more than any other entity. >> 3) Azure shows up a lot less than GCP or AWS, which are about similar to >> each other. >> 4) Around 5% respond saying it's been addressed (or why it's not in the >> event of security researchers) within a couple hours. The rest I don't know. >> I've had a mix of small and large entities in that response. >> 5) HostGator seems to have an autoresponder (due to a 1 minute response) >> that just indicates that you sent nothing actionable, despite the report >> including the relevant log file entries. >> 6) Charter seems to have someone actually looking at it as it took them 16 - >> 17 hours to respond, but they say they don't have enough information to act >> on, requesting relevant log file entries... which were provided in the >> initial report and are even included in their response. They request >> relevant log file entries with the date, time, timezone, etc. all in the >> body in plain text, which was delivered. >> 7) The LACNIC region has about 1/3 of my reports. >> >> >> >> Do these mirror others' observations with security issues and how abuse >> desks respond? >> >> >> >> - >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com
Re: ISC BIND 9 breakage?
It was a glitch with the re-signing of the zone. There should be a official report sometime tomorrow. That said "dnssec-lookaside auto;" has been a no-op in BIND since BIND 9.9.12, BIND 9.10.7, BIND 9.11.3 and a fatal configuration error as of BIND 9.12.0. We didn’t want the DLV lookup traffic and provides no benefit as the zone has been empty since 2017. If you have dnssec-lookaside configured in named.conf please remove it otherwise the DLV code in the validator has to cryptographically prove that DLV records don’t exist before returning that the response is insecure. That requires talking to the servers for dlv.isc.org. It does this every hour for a active validating resolver that is still running DNSSEC lookaside validation. Mark > On 26 Mar 2020, at 04:18, Drew Weaver wrote: > > Did anyone else on CentOS 6 just have some DNS resolvers totally fall over? > > I noticed that this command: dnssec-lookaside auto; was causing the issue. > The issue occurred right at about 1PM EST. > > I see this note in the ISC key file.. > > # ISC DLV: See https://www.isc.org/solutions/dlv for details. > # > # NOTE: The ISC DLV zone is being phased out as of February 2017; > # the key will remain in place but the zone will be otherwise empty. > # Configuring "dnssec-lookaside auto;" to activate this key is > # harmless, but is no longer useful and is not recommended. > > It’s not harmless anymore. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: QUIC traffic throttled on AT residential
> On 20 Feb 2020, at 11:29, Daniel Sterling wrote: > > On Tue, Feb 18, 2020 at 11:47 PM Daniel Sterling > wrote: >> random-source-port UDP traffic does not impress the AT network flow >> control systems, and your DNS traffic becomes unbearably slow (or is > > I received a comment that maybe the issue is not AT's "core" > network, but rather to do with the NAT device in my house. > > Oh, I wish this were the case! > > Unfortunately, there is no NAT CPE from AT involved: > > I've taken AT's RG CPE out completely. That device, which otherwise > would indeed be my gateway, is unused on my home network, completely > unpowered and unplugged. > > Instead I've got a linux box hooked directly up to the ONT. This works > fine; occasionally I *do* have do reconnect their RG and let it > re-auth to the PON, but once the connection is live, I fully unplug > their RG again, and plug my laptop (spoofing its MAC) back in directly > to the ONT. > > The laptop is running ubuntu 19.10, so there should be no artificial > limits. It's running NAT directly from the v4 IP I get from DHCP. > > > You may have noticed v4 is a theme here. I have nothing against using > v6 -- , I must admit the truth is I have no idea how to make ubuntu > acquire a v6 -- address? block ? I don't even know the right term -- > from uverse. It should just be a DHCPv6 PREFIX DELEGATION (PD). See RFC 8415. If AT are still using 6RD (IPv6 Rapid Deployment) that is described in RFC 5969. There is a DHCPv4 option that you can request that gives you the details for configuring the IPv6 in IPv4 tunnel and how to compute the IPv6 prefix from the allocated IPv4 address. CPE’s just try both and use DHCPv6 PD if both exist. > I know v6 works cuz AT's device supports it, and openwrt does it out > of the box-- but heck if I know how it works. At the risk of asking > this list for tech support -- does anyone want to ping me off list and > point me in the right direction?? Maybe somebody from Google -- you > can make up for breaking my v4 internet!! > > Thanks, > Dan -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
