Re: Vendors spamming NANOG attendees
In message <583541363.462.1497966071756.JavaMail.mhammett@ThunderFuck>, Mike Ha mmett writes: > I'm still not sure people understand the situation. There's an attendee > list, but that list doesn't have e-mail addresses. It didn't come from > the mailing list. The person looked up who went to the conference and > then found their e-mail address elsewhere. I also don't think the above > is wrong in any way and people should just get on with their lives. When will the US get sane anti-spam laws. No, I don't expect a answer. That behaviour here is illegal. Any Australian company / individual that does this can be fined regardless of where the email is sent from in the world or which third party they hire to do it. If you send to a Australian email address you can also be fined, provided you know it is a Australian address, as you are implicitly doing business in Australia. Remember you are choosing to do business with Australia when you send the email. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv4 Hijacking For Idiots
In message <1496816542.3628250.1001312328.70df4...@webmail.messagingengine.com> , Scott Christopher writes: > Mark Andrews wrote: > > > but we do have the tech to do this. > > I wholeheartedly agree. > > > All it takes is a couple of transit providers to no longer accept word-of-m > outh and > > the world will transition overnight. > > This is the hard part. > > It seems trivial - being probably only a handful of transit providers - > but then again, these providers have massive infrastructure spread > globally, often ancient legacy systems that still work, and management > has a legal responsibility in most places to maximize the profits of > their shareholders. > > Look at the rollout of EMV in the U.S.: the world "has done had that > tech to do that" for decades (in Europe) but it only arrived in the U.S. > two years ago. And the U.S. doesn't do the (more secure) chip-and-pin > like the rest of the world (that costs too much money according to the > banks) but rather chip-and-signature. > > Whereas U.S. banks are (sometimes) liable for fraud on their systems, > transit providers don't have any liability for anything in the U.S. And > they are actively fighting for their right to transit some packets > faster than others - for an additional fee, of course! Actually they do have liability. It just needs someone to sue them for them to wake up. The injured party isn't a customer of the transit provider so there isn't any weasle worded contract to sace the transit provider. > I think the solution is legislation + regulations. > > -- > Regards, > S.C. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv4 Hijacking For Idiots
In message <cal9jlaznrde0gl4nvn93vhv1bobtx0ekgjet8pvxa3mve1g...@mail.gmail.com>, Christopher Morrow writes: > > On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews <ma...@isc.org> wrote: > > > Now we could continue discussing how easy it is to hijack addresses > > of we could spend the time addressing the problem. All it takes is > > a couple of transit providers to no longer accept word-of-mouth and > > the world will transition overnight. > > i don't think any transit providers were used in the previous thread worth > of examples/comms... > I don't know that IXP folk either: > 1) want to be the police of this > 2) should actually be the police of this (what is internet abuse? from > who's perspective? oh...) > > The 'solution' here isn't new though... well, one solution anyway: > https://tools.ietf.org/html/rfc6810 You missed the point. We have the mechanisms to prevent hijacking today. We just need to use them and stop using the traditional mechanisms which cannot be mathematically be verified as correct. Getting to that stage requires several companies to simultaneously say "we will no longer accept as valid mechanisms to verify routes announcements. You need to use X or else we won't accept the announcement". Yes, this requires guts to do. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv4 Hijacking For Idiots
In message <2541cadf-4a76-b172-b395-0822f1889...@bryanfields.net>, Bryan Fields writes: > On 6/6/17 9:13 PM, Mark Andrews wrote: > > Getting to that stage requires several companies to simultaneously > > say "we will no longer accept as valid mechanisms to verify > > routes announcements. You need to use X or else we won't accept > > the announcement". Yes, this requires guts to do. > > And what of legacy address holders? ARIN will not permit RPKI use of their > blocks. This really doesn't prevent it being used. RPKI could have a forth CA for legacy holders that don't accept ARIN's terms for issuing of RPKI. You just need to co-ordinate yourselves. There is nothing magical about the current three other than they are accepted by everyone. Or we can just abandon IPv4 and its legacy baggage and do it for IPv6. Mark > -- > 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: IPv4 Hijacking For Idiots
In message <1496754899.2014592.1000384072.3e553...@webmail.messagingengine.com>, Scott Christopher writes: > Hank Nussbacher wrote: > > > 2. Create a domain called acme-corp.com and a user called peering > > Or one could register aÑme.com > > (If the reader can't tell the difference between acme.com and aÑme.com , > the reader is using one of the multitude of email clients and/or fonts > that presents Unicode poorly.) > > > 3. Contact an IX, preferably not one in a Westernized, clueful area: > > https://en.wikipedia.org/wiki/List_of_Internet_exchange_points > > I don't think the ordinary Westernized IX is immune to this. Any system > requiring human scrutiny is only as secure as the laziest human employed > by it. Don't underestimate the "too busy to check this crap" > attitude and its potential for serious problems. > > -- > Regards, > S.C. Route hijacking is theoretically preventable. You have machines verify the bonifides. This does require that people take the time to get the bonifides machines can process but we do have the tech to do this. Now we could continue discussing how easy it is to hijack addresses of we could spend the time addressing the problem. All it takes is a couple of transit providers to no longer accept word-of-mouth and the world will transition overnight. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Vendors spamming NANOG attendees
In message <a9d2d1be-0724-4cbb-ace3-8d2de9c89...@beckman.org>, Mel Beckman writes: > Mark, > > What law makes the harvesting of email addresses illegal? None that I > know of. If you can trust wikipedia sending to harvested addresses is illegal under CAN-SPAM. https://en.wikipedia.org/wiki/CAN-SPAM_Act_of_2003 While this is not US law, the act of harvesting addresses is illegal under the Australian anti-spam act https://www.legislation.gov.au/Details/C2016C00614 Mark > -mel via cell > > > On Jun 13, 2017, at 6:58 PM, Mark Andrews <ma...@isc.org> wrote: > > > > > > In message <f7e1f127-e971-4e92-af44-13193bd0e...@beckman.org>, Mel > Beckman writes: > >> Mark, > >> > >> The problem with your idea is that these NANOG attendee emails aren't > >> illegal under CAN-SPAM. This toothless Act let's anyone email any > address > >> they want, however obtained, with virtually any content (except > sexually > >> explicit), as long as they don't use misleading headers, deceptive > >> subject lines, or obscure the fact that the email is an ad. Those > >> features, plus clear identification of the originator and an opt-out > >> mechanism, let anyone send unlimited spam. > > > > The act of harvesting the email addresses is illegal which makes > > the subsequent emails illegal even if they meet all the other > > requirements of the CAN-SPAM act. > > > >> So, in reality, these so-called NANOG spammers are within the law. We > >> just don't like what they're doing. > >> > >> We definitely can't sue them as you advise. In fact, individual CANT > use > >> under CAN-SPAM. Only we network operators can. > >> > >> Thanks for nothing, Congress. > > > > As someone with stonger local anti-spam legislation that has to put > > up with the spam from US sources I have to agree. > > > > Mark > > > >> -mel via cell > >> > >>> On Jun 13, 2017, at 5:10 PM, Mark Andrews <ma...@isc.org> wrote: > >>> > >>> > >>> In message <38e506a8-247a-478f-9c4d-21602bee6...@beckman.org>, Mel > >> Beckman writes: > >>>> That still leaves the question: how to you invoke this financial > >>>> punishment? Prohibit NANOG members from buying their products? > >>> > >>> Everyone that has received the email bring a action under the > >>> CAN-SPAM act. Really if you don't want the list to be harvested, > >>> which is illegal under the act, bring the action. Opt out doesn't > >>> save the sender if they have already committed a illegal act. > >>> > >>> Mark > >>> > >>>> -mel via cell > >>>> > >>>>>> On Jun 13, 2017, at 10:12 AM, Rich Kulawiec <r...@gsp.org> wrote: > >>>>>> > >>>>>> On Tue, Jun 13, 2017 at 03:31:46PM +, Mel Beckman wrote: > >>>>>> Sometimes they're ignorant and don't realize they're spamming. > >>>>> > >>>>> That excuse stopped being viable sometime in the last century. They > >>>> know > >>>>> exactly what they're doing, they're just counting on the prospective > >>>>> gains to outweigh the prospective losses. If they're right, then > the > >>>>> spamming will not only continue, it will increase. (As we've seen: > >>>>> over and over and over again.) That's because they don't care about > >>>>> being professional or responsible or ethical: they only care about > >>>> profits. > >>>>> > >>>>> So the choice is clear: either make it plain to such "people" (if I > >>>>> may dignify sociopathic filth with that term) that this is > absolutely > >>>>> unacceptable and that it will have serious, immediate, ongoing > >> negative > >>>>> financial consequences, or do nothing while the problem escalates > >>>>> indefinitely. > >>>>> > >>>>> If you give people the means to hurt you, and they do it, and > >>>>> you take no action except to continue giving them the means to > >>>>> hurt you, and they take no action except to keep hurting you, > >>>>> then one of the ways you can describe the situation is "it isn't > >>>>> scaling well". > >>>>> --- Paul Vixie, on NANOG > >>>>> > >>>>> ---rsk > >>> > >>> -- > >>> 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Vendors spamming NANOG attendees
In message <f7e1f127-e971-4e92-af44-13193bd0e...@beckman.org>, Mel Beckman writes: > Mark, > > The problem with your idea is that these NANOG attendee emails aren't > illegal under CAN-SPAM. This toothless Act let's anyone email any address > they want, however obtained, with virtually any content (except sexually > explicit), as long as they don't use misleading headers, deceptive > subject lines, or obscure the fact that the email is an ad. Those > features, plus clear identification of the originator and an opt-out > mechanism, let anyone send unlimited spam. The act of harvesting the email addresses is illegal which makes the subsequent emails illegal even if they meet all the other requirements of the CAN-SPAM act. > So, in reality, these so-called NANOG spammers are within the law. We > just don't like what they're doing. > > We definitely can't sue them as you advise. In fact, individual CANT use > under CAN-SPAM. Only we network operators can. > > Thanks for nothing, Congress. As someone with stonger local anti-spam legislation that has to put up with the spam from US sources I have to agree. Mark > -mel via cell > > > On Jun 13, 2017, at 5:10 PM, Mark Andrews <ma...@isc.org> wrote: > > > > > > In message <38e506a8-247a-478f-9c4d-21602bee6...@beckman.org>, Mel > Beckman writes: > >> That still leaves the question: how to you invoke this financial > >> punishment? Prohibit NANOG members from buying their products? > > > > Everyone that has received the email bring a action under the > > CAN-SPAM act. Really if you don't want the list to be harvested, > > which is illegal under the act, bring the action. Opt out doesn't > > save the sender if they have already committed a illegal act. > > > > Mark > > > >> -mel via cell > >> > >>>> On Jun 13, 2017, at 10:12 AM, Rich Kulawiec <r...@gsp.org> wrote: > >>>> > >>>> On Tue, Jun 13, 2017 at 03:31:46PM +, Mel Beckman wrote: > >>>> Sometimes they're ignorant and don't realize they're spamming. > >>> > >>> That excuse stopped being viable sometime in the last century. They > >> know > >>> exactly what they're doing, they're just counting on the prospective > >>> gains to outweigh the prospective losses. If they're right, then the > >>> spamming will not only continue, it will increase. (As we've seen: > >>> over and over and over again.) That's because they don't care about > >>> being professional or responsible or ethical: they only care about > >> profits. > >>> > >>> So the choice is clear: either make it plain to such "people" (if I > >>> may dignify sociopathic filth with that term) that this is absolutely > >>> unacceptable and that it will have serious, immediate, ongoing > negative > >>> financial consequences, or do nothing while the problem escalates > >>> indefinitely. > >>> > >>> If you give people the means to hurt you, and they do it, and > >>> you take no action except to continue giving them the means to > >>> hurt you, and they take no action except to keep hurting you, > >>> then one of the ways you can describe the situation is "it isn't > >>> scaling well". > >>> --- Paul Vixie, on NANOG > >>> > >>> ---rsk > > > > -- > > 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: Vendors spamming NANOG attendees
In message <38e506a8-247a-478f-9c4d-21602bee6...@beckman.org>, Mel Beckman writes: > That still leaves the question: how to you invoke this financial > punishment? Prohibit NANOG members from buying their products? Everyone that has received the email bring a action under the CAN-SPAM act. Really if you don't want the list to be harvested, which is illegal under the act, bring the action. Opt out doesn't save the sender if they have already committed a illegal act. Mark > -mel via cell > > > On Jun 13, 2017, at 10:12 AM, Rich Kulawiec <r...@gsp.org> wrote: > > > >> On Tue, Jun 13, 2017 at 03:31:46PM +, Mel Beckman wrote: > >> Sometimes they're ignorant and don't realize they're spamming. > > > > That excuse stopped being viable sometime in the last century. They > know > > exactly what they're doing, they're just counting on the prospective > > gains to outweigh the prospective losses. If they're right, then the > > spamming will not only continue, it will increase. (As we've seen: > > over and over and over again.) That's because they don't care about > > being professional or responsible or ethical: they only care about > profits. > > > > So the choice is clear: either make it plain to such "people" (if I > > may dignify sociopathic filth with that term) that this is absolutely > > unacceptable and that it will have serious, immediate, ongoing negative > > financial consequences, or do nothing while the problem escalates > > indefinitely. > > > >If you give people the means to hurt you, and they do it, and > >you take no action except to continue giving them the means to > >hurt you, and they take no action except to keep hurting you, > >then one of the ways you can describe the situation is "it isn't > >scaling well". > >--- Paul Vixie, on NANOG > > > > ---rsk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DHCPv6-PD -> Lack of route injection in RFC
You know CPE devices are routers. They can tell you what routes DHCP has given them. That annoucement could be cryptographically authenticated. Send a CPE generated public key with the PD request. Generate a CERT for the prefix delegation using those two pieces of information and return it with the prefix delegation. The CPE announces the route using that CERT to sign the announcement to prevent spoofing. Each ISP can be its own CA here if it wants to be or they can tie into the public infrastructure. Mark In message <capkb-7aja1osy8ksurtfncx+kqe4b6mhvl8t3v+uxjhr77y...@mail.gmail.com> , Baldur Norddahl writes: > I know of several methods all flawed in some ways. There seems to be no > progress in this obvious lack of a solid easy way to inject routes to match > DHCP-PD. > > We use ExaBGP to inject routes via BGP that matches the configuration that > our DHCP server has. But this is non standard and clumsy to implement. Does > not work with all CPE routers either. > > Regards > > Baldur > > > Den 22. sep. 2017 19.08 skrev "Nicholas Warren" <nwar...@barryelectric.com>: > > Which method would you recommend as an alternative? > > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Baldur Norddahl > Sent: Friday, September 22, 2017 11:52 AM > > This method is lacking because you might have several routers eg. using > VRRP and the backup router will not learn anything from a relay on the > primary. > > > Den 22. sep. 2017 14.02 skrev "Steve Teusch" <steve.teu...@rtr.guru>: > > I am running into venders that do not support injection of a delegated > route when operating as a DHCPv6 relay (or server for that matter). > Brocade supports this, but I am not finding this as part of any of the > RFC's. This is to deliver home ISP service, so it is very important or > return packets won't go to the client unless the route is manually added as > a routing protocol is not an option. There should be a MUST activity for > this somewhere. > > Anyone know what gives? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Protocol 17 floods from Vietnam & Mexico?
In message <08ed2903-c81c-aa2e-cd04-4fa117840...@gmx.com>, Large Hadron Collider writes: > Yes, I'm being UDP flooded. I worked that out by grepping /etc/protocols. > > > On 12/09/2017 18:24, Matt Harris wrote: > > Protocol 17 is UDP. UDP is pretty common on the internet. Not sure > > why source and destination ports aren't being shown by your tool > > there, might be malformed UDP packets designed to obscure themselves > > from or otherwise evade some intrusion detection or firewall systems. No ports are listed because they are not the initial fragment of the UDP packet. Only the initial fragment that contains the UDP header has the ports reported. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Protocol 17 floods from Vietnam & Mexico?
Protocol 17 == UDP. These are just very big (65500 byte) UDP packets which have been fragmented. Somebody need to teach that packet analyser that UDP packets can be this big over IPv4 and bigger still if you are using IPv6 jumbo packets. Mark In message <1bf07b56-f71c-1fec-bfd2-386a67c2b...@gmx.com>, Large Hadron Collider writes: > 18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx > > umbrellix.net: ip-proto-17 > 18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx > > umbrellix.net: ip-proto-17 > 18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP, bad > length 65500 > 1464 > 18:04:32.391145 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391152 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391158 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391164 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391170 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391176 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391182 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391188 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391194 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391199 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391205 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391211 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391217 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391223 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391229 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391234 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391248 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391255 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391261 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391266 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391272 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391278 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391284 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391289 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391295 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391313 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391319 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391325 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391331 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391336 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391342 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391348 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391354 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391367 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391374 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391379 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391385 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391391 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391396 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391402 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391408 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391414 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391420 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > 18:04:32.391426 IP 115.75.50.106 > umbrellix.net: ip-proto-17 > > Some stupidity has me wondering... protocol 17? Huh? > > > Is this some attempt to exploit me while at the same time flooding me at > over 800Mbit/s? > > > Needless to say, I've shut my computer down to avoid going over my data > allowance. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Google DNS --- Figuring out which DNS Cluster you are using
If Google was being sensible the servers would just return the
information along with the answer. They all support EDNS.
e.g. dig +nsid @8.8.8.8
This is the type of thing the NSID (RFC 5001) was designed to do.
It just requires Google to configure the servers to return a id.
You would then back something like this. In this case the nsid is
the hostname but it can be anything you like it to be. A value
that makes sense to most people or a value that only make sense
to a Google.
; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> +nsid .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38770
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 72 6f 63 6b 2e 64 76 2e 69 73 63 2e 6f 72 67 ("rock.dv.isc.org")
; COOKIE: f58c358da14bc19476e2331f599e21c452df41a06367d78d (good)
;; QUESTION SECTION:
;. IN A
;; AUTHORITY SECTION:
. 10773 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2017082301 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 24 10:45:56 AEST 2017
;; MSG SIZE rcvd: 150
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Anyone from AT DNS?
In message
Re: Anyone from AT DNS?
In message <50298399-672d-4ba1-a726-7128b84b8...@apple.com>, Matt Peterman writes: > Got it! Youâre the winner here. I just setup both of my zones the name > way and obviously AT changed the way they did RDNS entries from when I > got a /25 last November and this second /25 in June. Oh well! > > Now I am running into the challenge of Route53 does seem to support > creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.â It > changes it to "128\05725.168.207.107.in-addr.arpa.â every time⦠*sigh* If > it isn't one thing its something else. Which is "128925.168.207.107.in-addr.arpa." when fed into a domain name parser. DNS escapes sequences are DECIMAL not OCTAL. I suggest that you log a bug report. 128/25.168.207.107.in-addr.arpa. == 128\04725.168.207.107.in-addr.arpa RFC 1035 \DDDwhere each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. That said '/' is not special to DNS parsers and shouldn't need to be converted to \DDD. Mark % dig '128\05725.168.207.107.in-addr.arpa' ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0a1+hotspot+add-prefetch+marka <<>> 128\05725.168.207.107.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8078 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ac2bc18c4e18f907a872f2b559dacb6ab6e64fb72a9c71d5 (good) ;; QUESTION SECTION: ;128925.168.207.107.in-addr.arpa. INA ;; AUTHORITY SECTION: 168.207.107.in-addr.arpa. 3600 IN SOA ns1.swbell.net. rm-hostmaster.ems.att.com. 2 10800 900 604800 7200 ;; Query time: 1244 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 09 12:05:46 AEDT 2017 ;; MSG SIZE rcvd: 163 % % dig '128\04725.168.207.107.in-addr.arpa' ;; BADCOOKIE, retrying. ; <<>> DiG 9.12.0a1+hotspot+add-prefetch+marka <<>> 128\04725.168.207.107.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54452 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: e6bdbbdf26697275cf492e9059dacbecc9eb8186d940bd69 (good) ;; QUESTION SECTION: ;128/25.168.207.107.in-addr.arpa. INA ;; AUTHORITY SECTION: 128/25.168.207.107.in-addr.arpa. 900 IN SOA ns-1746.awsdns-26.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; Query time: 1142 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Oct 09 12:07:56 AEDT 2017 ;; MSG SIZE rcvd: 175 % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Companies using public IP space owned by others for internal routing
Companies like COMCAST did. They manage the modems over IPv6. They also supported DS-Lite’s development as a transition mechanism so they wouldn’t have to run IPv4 to their customers. They wanted to be able to go IPv6 only. That meant having IPv4 as a service available. -- Mark Andrews > On 19 Dec 2017, at 06:34, Harald Koch <c...@pobox.com> wrote: > >> On 17 December 2017 at 17:48, Tom Carter <m1enr...@gmail.com> wrote: >> >> RFC1918 isn't big enough to cover all use cases. Think about a large >> internet service providers. If you have ten million customers, 10.0.0.0/8 >> would be enough to number modems, but what happens when you need to number >> video set top boxes and voice end points? I don't think anyone goes out and >> says "Lets go use someone else's space, because I don't want to use this >> perfectly good private space". >> > > :cough: > > They could use IPv6. I mean, if the mobile phone companies can figure it > out, surely an ISP can... > > -- > Harald
Re: Companies using public IP space owned by others for internal routing
> On 20 Dec 2017, at 2:39 am, Livingood, Jason <jason_living...@comcast.com> > wrote: > > On 12/18/17, 2:36 PM, "NANOG on behalf of Harald Koch" > <nanog-boun...@nanog.org on behalf of c...@pobox.com> wrote: >> They could use IPv6. I mean, if the mobile phone companies can figure it >> out, surely an ISP can... > > Except for cases when it is impossible or impractical to update software on a > great number of legacy devices… > > JL You mean devices where the manufacture ignore IPv6 and shipped you a dud. Even devices with a 15 year life cycle should be IPv6 capable today. Microsoft shipped IPv6 capable versions of Windows in 2001. If they could see the writing on the wall back then *every* other device manufacture should have also been able to see this. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Companies using public IP space owned by others for internal routing
> On 18 Dec 2017, at 1:20 pm, Robert Webb <rw...@ropeguru.com> wrote: > > Apologies for not responding sooner. > > This came to light with me on a forum where someone posted that they thought > it strange that their MTA received an IP that is assigned to the DoD DNIC. > > Where I work I have the opposite issue. They have a lot of public IPv4 space > and only use it internally never be advertised to the internet. Something I > have never agreed > With doing. > > Robert Why? This is a perfectly legitimate use of the IP addresses. The purpose of assigning addresses is so that they are unique WORLD WIDE in whatever context you wish to use them in. Mark > -Original Message- > From: Richard Porter [mailto:rich...@pedantictheory.com] > Sent: Sunday, December 17, 2017 8:25 PM > To: Robert Webb <rw...@ropeguru.com> > Cc: nanog@nanog.org > Subject: Re: Companies using public IP space owned by others for internal > routing > > Robert, > I’ve heard of two cases recently, large companies (non carrier/ISP). One > company looking to solve challenge with IPv6 and 6to4 and DNS. > > Also curious how wide-spread this is? Maybe just the kick in the butt for > catching the elusive IPv6 unicorn? > > ~Richard > >> On Dec 17, 2017, at 3:30 PM, Robert Webb <rw...@ropeguru.com> wrote: >> >> Will anyone comment on the practice of large enterprises using non RFC1918 >> IP space that other entities are assigned by ARIN for internal routing? >> >> Just curious as to how wide spread this might be. I just heard of this >> happening with a large ISP and never really thought about it until now. >> >> Robert > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Whois vs GDPR, latest news
Domain whois is absolutely useful. Try contacting a site to report that their nameservers are hosed without it. People forget that the primary purpose of whois is to report faults. You don’t need to do it very often but when you do it is crucial. Remember that about 50% of zones have not RFC compliant name servers (the software is broken) and that newer resolver depend on default behaviour working correctly. > On 23 May 2018, at 12:37 pm, Matt Harris <m...@netfire.net> wrote: > > Maybe I'm going out on a limb here, but was domain whois ever really that > useful? I can't remember ever using it for any legitimate sort of > activity, and I know it gets scraped quite a bit by spammers. Most of the > data is bogus these days on a lot of TLDs which allow "anonymous > registrations" and which registrars often charge an extra dollar or two > for. Showing the authoritative nameservers is neat, but a simple NS record > query against the next level up would suffice to provide that information > as well. The date of expiration may be useful if you're trying to grab a > domain when it expires, but registrar policies often drag that out anyways > and half the time the registrar squats on any decent domain when it expires > anyhow. Date of original registration may be interesting for one reason or > another... but none of this data is personally identifiable information > anyhow. > > Now on the other hand, RIR whois is actually very useful for determining > the rightful owner and abuse contacts for IP address space... Since RIRs > are designated by region and, afaik, only RIPE NCC data would be impacted > by GDPR... well, I'm surprised this isn't being talked about more than the > domain name side of things. > > Take care, > Matt -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Time to add 2002::/16 to bogon filters?
If you are using 2002::/16 you know are relying on third parties. Not that it is much different to any other address where you are relying on third parties. If one is going to filter 2002::/16 from BGP then install your own gateway to preserve the functionality. > On 19 Jun 2018, at 10:23 am, Ca By wrote: > > > > On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews wrote: > If a ASN is announcing 2002::/16 then they are are happy to get the traffic. > It > they don’t want it all they have to do is withdraw the prefix. It is not up > to > the rest of us to second guess their decision to keep providing support. > > That sounds like an interesting attack scenario where a malicious actor can > insert themselves in a path, via bgp, announcing 6to4 space > > > If you filter 2002::/16 then you are performing a denial-of-service attack on > the few sites that are still using it DELIBERATELY. > > None of the problems required removing it from BGP. There were end sites that > had firewalls that blocked 6to4 responses and the odd site that ran a gateway > and failed to properly manage it. The rest could have been dealt with by > configuring more gateways. If every dual stacked ASN had run their own > gateways > there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic and > dump it onto IPv4 as soon as possible and take the encapsulated traffic for > the > rest of IPv6 and de-encapsulate it as soon as possible. > > Mark > > On 19 Jun 2018, at 8:56 am, McBride, Mack > > wrote: > > > > This should have been filtered before. > > Lots of people improperly implemented this so it caused issues. > > > > Mack > > > > -Original Message- > > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff > > Sent: Monday, June 18, 2018 3:48 PM > > To: Job Snijders > > Cc: NANOG [nanog@nanog.org] > > Subject: Re: Time to add 2002::/16 to bogon filters? > > > > On Mon, 18 Jun 2018 21:08:05 + > > Job Snijders wrote: > > > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > > > Hi Job, > > > > I've been asking people about this recently. I don't particularly like > > having misdirected traffic or badly configured hosts sending junk to those > > who happen to be announcing addresses from this prefix. I'm planning on > > adding this to a bogon filter here. > > > > John > > E-MAIL CONFIDENTIALITY NOTICE: > > The contents of this e-mail message and any attachments are intended solely > > for the addressee(s) and may contain confidential and/or legally privileged > > information. If you are not the intended recipient of this message or if > > this message has been addressed to you in error, please immediately alert > > the sender by reply e-mail and then delete this message and any > > attachments. If you are not the intended recipient, you are notified that > > any use, dissemination, distribution, copying, or storage of this message > > or any attachment is strictly prohibited. > > > > -- > 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: Time to add 2002::/16 to bogon filters?
If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It they don’t want it all they have to do is withdraw the prefix. It is not up to the rest of us to second guess their decision to keep providing support. If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY. None of the problems required removing it from BGP. There were end sites that had firewalls that blocked 6to4 responses and the odd site that ran a gateway and failed to properly manage it. The rest could have been dealt with by configuring more gateways. If every dual stacked ASN had run their own gateways there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic and dump it onto IPv4 as soon as possible and take the encapsulated traffic for the rest of IPv6 and de-encapsulate it as soon as possible. Mark > On 19 Jun 2018, at 8:56 am, McBride, Mack wrote: > > This should have been filtered before. > Lots of people improperly implemented this so it caused issues. > > Mack > > -Original Message- > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff > Sent: Monday, June 18, 2018 3:48 PM > To: Job Snijders > Cc: NANOG [nanog@nanog.org] > Subject: Re: Time to add 2002::/16 to bogon filters? > > On Mon, 18 Jun 2018 21:08:05 + > Job Snijders wrote: > >> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters? > > Hi Job, > > I've been asking people about this recently. I don't particularly like > having misdirected traffic or badly configured hosts sending junk to those > who happen to be announcing addresses from this prefix. I'm planning on > adding this to a bogon filter here. > > John > E-MAIL CONFIDENTIALITY NOTICE: > The contents of this e-mail message and any attachments are intended solely > for the addressee(s) and may contain confidential and/or legally privileged > information. If you are not the intended recipient of this message or if this > message has been addressed to you in error, please immediately alert the > sender by reply e-mail and then delete this message and any attachments. If > you are not the intended recipient, you are notified that any use, > dissemination, distribution, copying, or storage of this message or any > attachment is strictly prohibited. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: WC 2018 impact on network yet
> On 20 Jun 2018, at 6:59 am, Bryan Fields wrote: > > On 6/15/18 6:23 AM, Ong Beng Hui wrote: >> With every operators looking at high quality HD video stream, anyone >> feeling the impact for WC 2018 yet ? > > I took and uber today, the driver was streaming a match on his phone in the > suction cup mount. > > Hands free, so it's technically legal… It wouldn’t be here. Videos other than reversing cameras are illegal to watch while driving. I suspect that there is a similar rule where you are. If there isn’t there is always the distracted driving coverall laws as well. > -- > 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: Time to add 2002::/16 to bogon filters?
> On 20 Jun 2018, at 4:16 am, Wes George wrote: > > On 6/18/18 7:34 PM, Mark Andrews wrote: > >> If a ASN is announcing 2002::/16 then they are are happy to get the traffic. >> It >> they don’t want it all they have to do is withdraw the prefix. It is not up >> to >> the rest of us to second guess their decision to keep providing support. > WG] I don't think that this is intentional in most cases anymore. It's > most likely legacy cruft/zombie services. Because it mostly operates > unattended and the few that are still using it probably don't notice > when it breaks nor can they figure out to whom they should complain > because anycast makes that nearly impossible, it continues operating > quietly in the dusty and disused corners of the net below a sign saying > "beware of the leopard" until the equipment gets retired or dies of old > age. Also this argument would carry more weight if it hadn't already > been had and concluded with RFC7526, and if it wasn't completely > disabled on MS products now: > https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features#features-were-no-longer-developing >> >> If you filter 2002::/16 then you are performing a denial-of-service attack on >> the few sites that are still using it DELIBERATELY. > WG] As opposed to the unintentional denial-of-service attacks that > happen all the time because of the inherent flaws in the implementation > and the low importance people place on first-class deployments of this > service? Sites that are still using it deliberately should have found a > more reliable solution years ago, even if it's a statically-provisioned > GRE or 6in4 tunnel. Plenty of tunnel brokers out there to facilitate > this if native IPv6 still isn't available. Keeping this around past its > sell-by date is simply enabling bad behavior and a bad user experience > for IPv6. Actually there aren’t plenty of tunnel brokers anymore. Lots have shut up shop in the last couple of years. HE is still there but the others are gone or are not accepting new tunnels. At the moment I’m waiting for sane routing between HE and Optus to move my tunnel end point closer. Crossing the Pacific twice to get to HE’s pop in Sydney is insane. If I used it for IPv6 traffic there would be 6 crossing of the Pacific for most IPv6 traffic to get a IPv6 reply. That’s 4 more than there should be. I don’t expect Optus to offer IPv6 any time soon. Mark > Wes George > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover
In message <cal9qcx5izu6sdbgkuc+q_msezayhrb4owxeiamst1msuvls...@mail.gmail.com>, Tom Beecher writes: > "But if provider 1 has its 1 fibre on the CN line and provider 2 has its > 1 fibre along CP line (or road), then you can get diversity by getting > bandwidth from both." > > That's not diversity. That's just a matter of time before the same backhoe > catches them both. :) It depends on how the lines "cross" each other. Two tunnels and you have physical seperation. Crossing at the same level then you don't. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: MTU to CDN's
CDN’s (or anyone using a load balancer to multiple server instances) needs to assume that traffic may be encapsulated (4in6, 6in4, 464XLAT) and lower the interface MTU’s so that all traffic generated can be encapsulated without fragmentation or PTB’s being generated. This is only going to get worse as more and more eyeballs are being forced into using IPv4 as a service scenarios. > On 9 Jan 2018, at 11:54 am, Jared Mauch <ja...@puck.nether.net> wrote: > > On Mon, Jan 08, 2018 at 05:55:55PM -0500, Dovid Bender wrote: >> Hi, >> >> N00b here trying to understand why certain CDN's such as Cloudfare have >> issues where my MTU is low. For instance if I am using pptp and the MTU is >> at 1300 it wont work. If I increase to 1478 it may or may not work. > > I've done some measurements over the internet in the past year or > so and 1400 byte packets with DF bit seem to make it just fine. > > - Jared > > -- > Jared Mauch | pgp key available via finger from ja...@puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: MTU to CDN's
Because the CDN delivers to your customers not you. It’s your customers link requirements that are the ones you need to worry about. If you support jumbo frames to all of your customers and their gear also supports jumbo frame then sure go ahead and use jumbo frames otherwise use the lowest common denominator MTU when transmitting. This is less than 1500 on today Internet and encapsulated traffic is reasonable common. embedded CND <--> NAT64 <--> CLAT <--> client 1500 14XX 1500 embedded CDN <--> B4 <— > 6RD <— > client 1500. 14XX 1500 Now you can increase the first 1500 easily. The rest of the path not so easily. > On 19 Jan 2018, at 9:53 am, George Michaelson <g...@algebras.org> wrote: > > if I was an ISP (Im not) and a CDN came and said "we want to be inside > you" (ewww) why wouldn't I say "sure: lets jumbo" > > not even "asking for a friend" I genuinely don't understand why a CDN > who colocates and is not using public exchange, but is inside your > transit boundary (which I am told is actually a bit thing now) would > not drive to the packet size which works in your switching gear. > > I understand that CDN/DC praxis now drives to cheap dumb switches, but > even dumb switches like bigger packets dont they? less forwarding > decision cost, for more throughput? > > On Fri, Jan 19, 2018 at 6:21 AM, Dovid Bender <do...@telecurve.com> wrote: >> Vincent, >> >> Thanks. That URL explained a lot. >> >> On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat <ber...@luffy.cx> wrote: >> >>> ❦ 8 janvier 2018 15:08 -0800, joel jaeggli <joe...@bogus.com> : >>> >>>>> N00b here trying to understand why certain CDN's such as Cloudfare have >>>>> issues where my MTU is low. For instance if I am using pptp and the MTU >>> is >>>>> at 1300 it wont work. If I increase to 1478 it may or may not work. >>>> PMTUD has a lot of trouble working reliability when the destination of >>>> the PTB is a stateless load-balancer. >>> >>> More explanations are available here: >>> https://blog.cloudflare.com/path-mtu-discovery-in-practice/ >>> -- >>> Don't comment bad code - rewrite it. >>>- The Elements of Programming Style (Kernighan & Plauger) >>> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Waste will kill ipv6 too
And /48 was chosen as the site size so that we didn’t have to think about that either. It’s large enough to cover almost all sites with additional /48s to be provided if you run out of /64s. Nothing in the last 20+ years has lead me to believe that these decisions were wrong. In fact NOT following these rules has consequences for everybody else as you can’t policy filter at the /48 boundary without collateral damage. I would recommend that all ISP’s using longer prefixes for customer assignment shorten them to /48s. Mark > On 29 Dec 2017, at 8:35 am, Owen DeLong <o...@delong.com> wrote: > > Sigh… Let’s stop with the IPv4-think. > > Wasting 2^64 addresses was intentional because the original plan was for a > 64-bit total > address and the additional 64 bits was added to make universal 64-bit subnets > a no-brainer. > > Owen > >> On Dec 28, 2017, at 09:55 , Michael Crapse <mich...@wi-fiber.io> wrote: >> >> Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp. >> If that was ipv4 you could recreate the entire internet with that many >> addresses. >> >> On 28 December 2017 at 10:39, Owen DeLong <o...@delong.com >> <mailto:o...@delong.com>> wrote: >> >>> On Dec 28, 2017, at 09:23 , Octavio Alvarez <octalna...@alvarezp.org >>> <mailto:octalna...@alvarezp.org>> wrote: >>> >>> On 12/20/2017 12:23 PM, Mike wrote: >>>> On 12/17/2017 08:31 PM, Eric Kuhnke wrote: >>>> Call this the 'shavings', in IPv4 for example, when you assign a P2P >>>> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6, >>>> due to ping-pong and just so many technical manuals and other advices, >>>> you are told to "just use a /64' for your point to points. >>> >>> Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the >>> exception would be if a router does not support it. >>> >>> Best regards, >>> Octavio. >> >> Best practice used most places is to assign a /64 and put a /127 on the >> interfaces. >> >> Owen >> >> >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Waste will kill ipv6 too
> On 29 Dec 2017, at 9:31 am, Thomas Bellman <bell...@nsc.liu.se> wrote: > > On 2017-12-28 22:31, Owen DeLong wrote: > >> Sure, but that’s intended in the design of IPv6. There’s really no need >> to think beyond 2^64 because the intent is that a /64 is a single subnet >> no matter how many or how few machines you want to put on it. > >> Before anyone rolls out the argument about the waste of a /64 for a point >> to point link with two hosts on it, please consider that the relative >> difference in waste between a /64 with 10,000 hosts on it and a /64 with >> 2 hosts on it is less than the rounding error in claiming that a /64 is >> roughly 18 quintillion addresses. In fact, it’s orders of magnitude less. > > [...] > >> We may, someday, wish we had gone to some value of N larger than 128, >> but I seriously doubt it will occur in my lifetime. > > My problem with the IPv6 addressing scheme is not the waste of 64 bits > for the interface identifier, but the lack of bits for the subnet id. > 16 bits (as you normally get a /48) is not much for a semi-large organi- > zation, and will force many to have a dense address plan, handing out > just one or a few subnets at a time, resulting in a patch-work of > allocations. 24 bits for subnet id would be more usable. What’s wrong with a dense allocation? That’s what we have routers for. Thats why we have a protocol for prefix delegation. You can do on demand subnet allocation without involving humans. > Consider e.g. a university or company campus. There are probably at > least 16 departments, so I would like to use 8 bits as department id. > Several departments are likely to have offices on more than one floor, > or in more than one building, so I would like to let them have 4 bits > to specify location, and then 8 bits to specify office/workplace within > each location. And allow them to hand out 16 subnets per workplace. > That adds up to 24 bits. So a /40 would be nice, not a /48. Stop with the IPv4 think. This is all driven by humans allocating addresses. Use the features of IPv6. You have on demand prefix allocation. you have ULA addresses where every student can have their own /48 play space by randomly selecting a ULA /48 prefix. > Similarly, an ISP that wants a structured address plan, e.g. to encode > prefecture, city and part of city in the address, will quickly use up > bits in the customer id part of the address. > > > /Bellman > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Waste will kill ipv6 too
> On 29 Dec 2017, at 11:24 am, Ricky Beam <jfb...@gmail.com> wrote: > > On Thu, 28 Dec 2017 16:35:08 -0500, Owen DeLong <o...@delong.com> wrote: >> Wasting 2^64 addresses was intentional because the original plan was for a >> 64-bit total >> address and the additional 64 bits was added to make universal 64-bit >> subnets a no-brainer. > > Incorrect. The original 128 address space was split 80+48. That *LATER* > became 64+64 to support EUI-64 (vs. 48bit ethernet MACs) > > A 64bit LAN is, and always will be, an infinitely stupid idea. The reason for > that over-optimization in SLAAC never materialized -- the 8bit > micro-controlers from the 80s will never run IPv6, so the ability to form > your address in 4 lines of ASM is meaningless, even more so when IPSec was > bolted on. (later marked optional, but was originally required) > > SLAAC is still, to this day, THE. ONLY. THING. demanding your LANs be 64bits. > I've run LANs with longer prefixes for decades. And they work. (the original > intent was to keep android devices from using IPv6, as there's no f'ing way > to turn it off, or even see it anywhere.) Yes, there are various RFCs saying > you need to use /64's, but they're all bunk. SLAAC is the only thing that > REQUIRES a /64, and few modifications to your IPv6 source and privacy > extensions function just fine with longer prefixes. (don't go nuts and use > /120's, unless you like seeing address collisions; DAD is designed to handle > that -- and does, but it can take a few rounds to find a free address. I've > used /96 on a LAN with ~100 machines without issue.) > > Back to the main theme... artificially cutting the address space in half, > just makes the point even stronger. IPv6 address space is, in fact, half as > big as people think it is, because we've drawn a line at /64 -- and the > catastrophic part is people *ARE* wiring that into hardware. Every example > I've seen people bat around about just how big 2^128 is, ignores the reality > of Real World Networking(tm). They ignore infrastructure. The ignore route > table size. They ignore the sparse nature of hierarchical address assignment. > In the "10B people === 10B /48's" example, that's a dense PI allocation > scheme that will lead to a global routing table approaching 10B routes -- you > can't aggregate a random selection of /48s -- with zero consideration for how > those 10B networks will interconnect. > > The simple truth is, we're doing the exact same thing with IPv6 that we did > with IPv4: "The address space is so mind alteringly large we'll never use > even a fraction of it." *pause* "Umm, wait a minute, we're carving this > turkey up alarmingly fast." Will we use up the entire thing? Of course we > will; it's not, in fact, *infinite*, so we *will* eventually assign all of > it. It's going to happen a lot faster than most people think, as we're so > cavalier with handing out vast amounts of space for which most people will > never use more than (a) one LAN, and (b) a few dozen addresses within that > single LAN. Will it happen in 5, 10, 100 years? The later is a safer bet. > (not that I'll be around to collect) But just like IPv4, some decades down > the road, people will see how stupid our allocation scheme really is, and > begin a new "classless" era for IPv6. The short of it is, we got here first, > so we don't have to give a shit about being efficient or frugal. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Waste will kill ipv6 too
> On 29 Dec 2017, at 2:51 pm, valdis.kletni...@vt.edu wrote: > > On Thu, 28 Dec 2017 20:26:46 -0700, Brock Tice said: > >> I will again say I am indeed no expert, I am happy to get feedback. Is >> there some kind of allocation scheme where a residential user or even a >> small or medium business will have any chance of using 4096 /64s? > > They won't burn 4096 consecutive addresses. They'll do what you said - your > gear supplies their head-end router a /52. That then starts handing out a > half-dozen or so /64s for hardware interfaces, and hands a DHCP-PD /56 to the > expansion router at the other end of the house, which then hands out a > half-dozen /64s for subnets at that end, and *it* then hands a /60 PD to the > garage and barn routers, so they can each set up a half-dozen /64s. PD is designed so that a device (router) can request multiple PD requests upstream. The interior router just needs to make a upstream request on behalf of the downstream device and any prefixes it will be allocating itself. There is zero need to maintain a pool of prefixes to answer prefix requests. If you get back a bigger (e.g. /48 sized response) you just use those until they have all been handed out. > So yeah, they need a /52, even though we've only burned through 2 or 3 dozen > /64s. But this is the way it's *supposed* to work - note that careful choice > of > subnet numbers for the PD and local subnets means that even if other stuff > shows up and starts asking for a PD, there will be plenty left for them to > use. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Waste will kill ipv6 too
> On 29 Dec 2017, at 4:21 pm, valdis.kletni...@vt.edu wrote: > > On Fri, 29 Dec 2017 15:36:51 +1100, Mark Andrews said: >> PD is designed so that a device (router) can request multiple PD requests >> upstream. The interior router just needs to make a upstream request on behalf >> of the downstream device and any prefixes it will be allocating itself. > > OK, I obviously missed that part of the RFC, I was under the impression that a > "middle" router would be carving out of its own PD, rather than relaying the > downstream request upstream. Mostly this is because RFC describe what goes over the wire, not what happens internally to a node. There isn’t a RFC that says populate the DHCP DNS servers advertised downstream with those learnt by DHCP from upstream but CPE routers do this all the time. You could also just turn on DHCPv6 relay when you detect you are a interior router or have a check box next to the enable DHCP checkbox which says use relay mode. Device vendors need more and more spoon feeding these days. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Waste will kill ipv6 too
> On 29 Dec 2017, at 1:54 pm, Ricky Beam <jfb...@gmail.com> wrote: > > On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong <o...@delong.com> wrote: >> If you want to make that argument, that we shouldn’t have SLAAC and we >> should use /96 prefixes, that wouldn’t double the space, it would multiply >> it by roughly 4 billion. > > I'm saying I should be able to use whatever size LAN I want. Go ahead and do it. No one is stopping you. Just don’t force it on other including your customers. >> The routing problem might be real if everyone goes to PI, but I think that’s >> an unlikely scenario. > > Every scenario everyone has come up with is "unlikely". Home networks with > multiple LANs??? Never going to happen; people don't know how to set them up, > and there's little technical need for it. It already happens and it isn’t just geeks that have such home networks. People do daisy chain routers today and have been for years. HOMENET routers will auto configure if you just plug them together. >> Your definition of “amazingly fast is pretty odd... we’ve allocated tiny >> fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, >> unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space >> for distribution to the RIRs. Of that /3, IANA has delegated a little more >> than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving >> and constitutes well under 1/8th of the address space. Issued. By that >> measure, we’ve got well over 160 years to worry about runout. > > After 20 years of not using IPv6, that's actually A LOT of carving. And if > you look at what's been assigned vs. what's being announced vs. what's > actually being used, there's a fantastic amount of waste. But nobody cares > because there's plenty of space, and "we'll never use it all." (history says > otherwise.) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Geolocation: IPv4 Subnet blocked by HULU, and others
Talk to your lawyers. They should be able to advise you if there is legal remedy or not and if so what the chances of success are and some estimate of the costs of pursuing action. Mark -- Mark Andrews > On 27 Dec 2017, at 06:41, Michael Crapse <mich...@wi-fiber.io> wrote: > > I would like to know, Is there any legal recourse we can take against such > a company consistently ignoring whitelist requests? > Currently, the only way my customers can connect to hulu without getting a > vpn error is by using a vpn. On my end, i have just started NATing all > requests to HULU through the few good IPs that I have. > >> On 26 December 2017 at 11:12, Sam Norris <s...@sandiegobroadband.com> wrote: >> >> Anyone figure this out? I need to get our prefixes updated as well as >> they are >> detecting our customers in the wrong city. >> >> Sam >> >> >>> -Original Message- >>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of >>> li...@silverlakeinternet.com >>> Sent: Wednesday, December 20, 2017 1:28 PM >>> To: Mike Hammett >>> Cc: nanog@nanog.org >>> Subject: Re: Geolocation: IPv4 Subnet blocked by HULU, and others >>> >>> I could use a contact for all of these as well. I have been trying to >>> get my subnet unblocked with all of these providers and have reached out >>> in many ways to all of them over the past few months, but never get a >>> response. >>> >>> Thank you, >>> Brett A Mansfield >>> >>>> On 2017-12-15 19:57, Mike Hammett wrote: >>>> Bump for Hulu. >>>> >>>> >>>> >>>> >>>> - >>>> Mike Hammett >>>> Intelligent Computing Solutions >>>> >>>> Midwest Internet Exchange >>>> >>>> The Brothers WISP >>>> >>>> - Original Message - >>>> >>>> From: "Michael Crapse" <mich...@wi-fiber.io> >>>> To: nanog@nanog.org >>>> Sent: Wednesday, December 6, 2017 3:38:20 PM >>>> Subject: Geolocation: IPv4 Subnet blocked by HULU, and others >>>> >>>> I am a local WISP. And my customers have trouble reaching Hulu, Disney >>>> now, >>>> and previously netflix and amazon prime(both resolved). >>>> I have emailed, mailed, and called both HULU and Disney now to get my >>>> 196.53.96.0/22 subnet unblacklisted as a VPN provider(no longer so) >>>> from >>>> their services. They have replied saying it takes 3-5 days to resolve >>>> the >>>> issue, that was several weeks ago. Can i get contact from those two >>>> services that can help my customers reach their services, thank you. >>>> >>>> >>>> Thank you for the help. >>>> -Michael >> >>
Re: Geolocation: IPv4 Subnet blocked by HULU, and others
> On 28 Dec 2017, at 9:38 am, Jima <na...@jima.us> wrote: > > On 2017-12-27 14:10, Jared Mauch wrote: >> On Dec 27, 2017, at 3:50 PM, Grant Taylor via NANOG <nanog@nanog.org> wrote: >>> Doesn't Hulu (et al) have an obligation to provide service to their paying >>> customers? >>> >>> Does this obligation extend to providing service independent of the carrier >>> that paying customers uses? >>> >>> Or if Hulu choose to exclude known problem carriers (i.e. VPN providers) >>> don't they have an obligation to confirm that their exclusions are >>> accurate? Further, to correct problems if their data is shown to be >>> inaccurate? >> I have a suspicion that these folks acquired IP space that was previously >> marked as part of a VPN provider, or Hulu is detecting it wrongly as VPN >> provider IP space. > > I was sitting on this, but what the heck. > > I personally am curious as to what bug and/or feature allowed a random WISP > in Utah (or the parent-ish ISP in New Jersey) to have IP space allocated from > AfriNIC. > > One might consider Hulu et al not so at-fault with that fact in consideration. > > - Jima If you need IPv4 address space you get it where you can. There are lots of addresses used outside of the original RIR service regions. This will occur more and more often. What it does require is the State AG to come into bat for the customer to make HULU correct their business practices as that are obviously broken. You should be able to buy you internet service from anyone in the state and it should work equally well subject to bandwidth limitations. This is a consumer rights issue and it needs to be driven that way. inetnum:196.53.96.0 - 196.53.99.255 netname:LogicWeb descr: Wi-Fiber, Inc. descr: 775 S Main St. descr: Logan, UT 84321 country:US admin-c:CA12-AFRINIC tech-c: CA12-AFRINIC status: ASSIGNED PA mnt-by: LOGICWEB-MNT source: AFRINIC # Filtered parent: 196.52.0.0 - 196.55.255.255 person: Chad Abizeid address:LogicWeb Inc. address:4509 Steeplechase Dr. address:Easton, PA 18040 address:USA phone: +1 866 611 1556 org:ORG-LWI1-AFRINIC nic-hdl:CA12-AFRINIC mnt-by: LOGICWEB-MNT source: AFRINIC # Filtered -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Implementing 464XLAT at a small WISP
> On 28 Dec 2017, at 11:45 am, Brock Tice <br...@bmwl.co> wrote: > > We recently deployed our first half-dozen IPv6-only customers after 6+ months > of testing, using 464XLAT. > > It took me ages to sort all this out, so I hope someone finds this helpful. > Feedback very much welcome. > > https://blog.brocktice.com/2017/12/27/deploying-464xlat-for-ipv6-only-clients-on-a-small-wisp-network-with-mikrotik-routers/ If all you want to do is 464XLAT you don’t need a nameserver that supports DNS64. Just add a ipv4only.arpa zone with the appropriate records to your recursive servers. The following provides the 464XLAT translation with the well known NAT64 prefix. ipv4only.arpa. SOA . . 0 0 0 0 0 ipv4only.arpa. NS . ipv4only.arpa. 64:ff9b::192.0.0.170 ipv4only.arpa. 64:ff9b::192.0.0.171 ipv4only.arpa. A 192.0.0.170 ipv4only.arpa. A 192.0.0.171 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Waste will kill ipv6 too
When the IETF decided on 128 bit addresses it was taking into consideration /80 sized subnet. Prior to that it was looking at a 64 bit address size and allocating addresses the IPv4 way with lots of variable sized networks. This was changed to /64 subnets to accomodate 64 bit MAC. After that there was discussion about how many subnet should be enough for 99.99% of sites which gave /48 per site using /64 sized network. That 281474976710656 sites or 35184372088832 out of the /3 we are currently allocating from. Now there are very few sites that need 65536 subnets and those that do can request additional /48’s. Now if you assume the earth’s population will get to 25B, and every person is a site, that still leaves 35159372088832 sites. And if each of those people also has a home and a vehicle, that still leaves 35109372088832 sites. Handing out /48’s to homes was never ever going to cause us to run out of IPv6 space. Even if the homes are are connected to multiple providers there isn’t a issue. Mark > On 21 Dec 2017, at 7:57 am, William Herrin <b...@herrin.us> wrote: > > On Wed, Dec 20, 2017 at 1:48 PM, Mel Beckman <m...@beckman.org> wrote: > >> I won’t do the math for you, but you’re circumcising the mosquito here. We >> didn’t just increase our usable space by 2 orders of magnitude. It’s >> increased more than 35 orders of magnitude. >> > > Hi Mel, > > The gain is just shy of 29 orders of magnitude. 2^128 / 2^32 = 7.9*10^28. > > There are 2^128 = 3.4*10^38 IPv6 addresses, but that isn't 38 "orders of > magnitude." Orders of magnitude describes a difference between one thing > and another, in this case the IPv4 and IPv6 address spaces. > > > Using a /64 for P2P links is no problem, really. Worrying about that is >> like a scuba diver worrying about how many air molecules are surrounding >> the boat on the way out to sea. >> > > It's not a problem, exactly, but it cuts the gain vs. IPv4 from ~29 orders > of magnitude to just 9 orders of magnitude. Your link which needed at most > 2 bits of IPv4 address space now consumes 64 bits of IPv6 address space. > > Then we do /48s from which the /64s are assigned and we lose another 3 or > so orders of magnitude... Sparsely allocate those /48s for another order of > magnitude. From sparsely allocated ISP blocks for another order of > magnitude. It slips away faster than you might think. > > Regards, > Bill Herrin > > > -- > William Herrin her...@dirtside.com b...@herrin.us > Dirtside Systems . Web: <http://www.dirtside.com/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Companies using public IP space owned by others for internal routing
DNS64 “works” if you ignore what it breaks. MAP-T does NAT46 to the NAT64 and doesn’t have the side effects of DNS64. Why people insist that DNS64 is a “good" way to direct traffic to the NAT 64 I don’t understand. MAP-T directs the traffic to the NAT64 without the side effects. DNS64 was only ever a stop gap mechanism with lots of know side effects. Mark > On 21 Dec 2017, at 10:01 am, Ca By <cb.li...@gmail.com> wrote: > > > On Wed, Dec 20, 2017 at 5:54 PM Mark Andrews <ma...@isc.org> wrote: > As someone who has written a DNS64 implementation - DO NOT USE DNS64. DNS64 > breaks stuff. > > Use MAP-T. For those of you using DNS64 on the cellar side MAP-T can use the > NAT64 you already have. > > Mark > > > That’s just your opinion, man. Works for me and my 70 million customers. > > Anything that is broken by DNS64 can be properly fixed by eliminating the > need for it — by deploying ipv6. DNS64 only appears when the far end resource > is single stacked (!) > > We won’t be held hostage by folks who refuse to deploy ipv6, those days are > over > > Happy holidays! > > > > > On 21 Dec 2017, at 9:33 am, Jens Link <li...@quux.de> wrote: > > > > Ca By <cb.li...@gmail.com> writes: > > > >> http://jool.mx/en/index.html > >> > >> Free open source nat64 > > > > And the DNS64 part can be done with powerdns (recursor), unbound, bind, > > ... All OpenSource > > > > Jens > > -- > > > > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | > > | http://blog.quux.de | jabber: jensl...@quux.de| --- | > > -------- > > -- > 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: Companies using public IP space owned by others for internal routing
As someone who has written a DNS64 implementation - DO NOT USE DNS64. DNS64 breaks stuff. Use MAP-T. For those of you using DNS64 on the cellar side MAP-T can use the NAT64 you already have. Mark > On 21 Dec 2017, at 9:33 am, Jens Link <li...@quux.de> wrote: > > Ca By <cb.li...@gmail.com> writes: > >> http://jool.mx/en/index.html >> >> Free open source nat64 > > And the DNS64 part can be done with powerdns (recursor), unbound, bind, > ... All OpenSource > > Jens > -- > > | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | > | http://blog.quux.de | jabber: jensl...@quux.de| --- | > -------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Waste will kill ipv6 too
> On 22 Dec 2017, at 3:48 am, Christopher Morrow <morrowc.li...@gmail.com> > wrote: > > 2) For the transition technology discussion I believe it centered around > attempting to get a /48 to each 'site' (home/customer) and doing ds-lite as > the transition technology in use. > (map the customer to not a /128 in the ds-lite, but a /48) I think you mean 6rd. DS-Lite doesn’t use any extra IPv6 addresses. 6rd can be poorly done by embedding the entire IPv4 address in the IPv6 address. Doing that does waste space. 6rd deployment should not require much more IPv6 /48’s than a native IPv6 deployment would. That does require properly configuring your DHCPv4 servers with DIFFERENT 6rd DHCPv4 Option values on a per IPv4 DHCP pool basis which I’m sure every ISP here is capable of doing as there is nothing really new here to do. You have all carved up IPv4 assignments into IPv4 pools. This is no different. You carve up a IPv6 assignments into similar sized pools of /48’s then set the 6rd DHCPv4 Option to the appropriate values for that IPv4 to IPv6 pool mapping. Add the mapping to the BRs and you are done. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Waste will kill ipv6 too
The RIR’s assignment to ISPs assume relatively dense assignment of /48 to customers. ISPs still have to justify the allocation based on the number of customers sites for shorter than a /32. RIR assignments to non ISPs are also relatively dense. If you have multiple sites you don’t need contiguous addresses. Automatic assignment in homenet does dense assignment. > On 21 Dec 2017, at 12:27 pm, William Herrin <b...@herrin.us> wrote: > > On Wed, Dec 20, 2017 at 4:57 PM, Mark Andrews <ma...@isc.org> wrote: > Handing out /48’s to homes was never ever going to cause us to run out of > IPv6 space. Even if the homes are are connected to multiple providers there > isn’t a issue. > > Hi Mark, > > No single assignment practice would. Sadly no IPv6 addresses reach your > computer directly from IANA. Multiple layers of assignment practices are > happen along the way, each with > it's own cumulative consumption. Most of those layers were designed with the > independent assumption that "we have so many IPv6 addresses, let's just not > worry about how many bits are consumed at this step." With a cumulative > effect on the consumption of IPv6 space. > > Regards, > Bill Herrin > > > > -- > William Herrin her...@dirtside.com b...@herrin.us > Dirtside Systems . Web: <http://www.dirtside.com/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: AS Numbers unused/sitting for long periods of time
Just because a number is NOT VISIBLE on the global Internet, it does NOT mean that it is not IN USE. This applies to IPv4 addresses, IPv6 addresses and AS numbers. Apart from legacy IPv4 addresses and legacy AS, these resources require annual payments to maintain the assignment from the RIR. Mark > On 3 Jan 2018, at 9:46 am, James Breeden <ja...@arenalgroup.co> wrote: > > Before I take this to the ARIN PPML, wanted to get NANOG's thoughts. > > > I'm amazed at the number of AS numbers that are assigned, but not actively > being used. I'm not talking just like they are offline for a week or month, > this is complete non-use of the AS in the global routing table within > *years*. They are completely abandoned resources - Whois data is inaccurate > by 5-10 years, no routeviews data in the same time period, the owning > organization (if you can find it) scratches their heads about responding > whether they use it or not, etc. > > > I know we're currently not in a push to get AS numbers or close to > exhaustion, but I do believe that people who have global AS numbers should > have a requirement to use them or return them to the global pool. Am I the > only one thinking this? > > > And before you come back with "Well they may be using it internally where it > doesn't need to be in the GRT" - that's why we have Private AS numbers. > > > I.e. some form of ARIN or global policy that basically says "If AS number not > routed or whois updated or used in 24 months, said AS number can be public > noticed via mailing list and website and then revoked and reissued to a > pending, approved AS request" > > > Just thinking aloud. Happy New Year all! > > > James W. Breeden > > Managing Partner > > > > [logo_transparent_background] > > Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media > > PO Box 1063 | Smithville, TX 78957 > > Email: ja...@arenalgroup.co<mailto:ja...@arenalgroup.co> | office > 512.360. | cell 512.304.0745 | > www.arenalgroup.co<http://www.arenalgroup.co/> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Xbox Live and Teredo
Given that you have IPv6 I would be looking at why the XBOXs are attempting Teredo at all. I would expect them to use the IPv6 addresses that you are assigning your customers. Mark > On 3 Jan 2018, at 9:25 am, Justin Wilson <li...@mtin.net> wrote: > > Figured the collective here might have an answer. All of a sudden a network > I manage started getting complaints from XBOX live users are getting error > messages about “Can’t get Teredo IP address” on their consoles. Is anyone > else seeing this wide spread? The Microsoft support default answer is “Your > ISP is blocking ports” when I can do an nmap on each of these customers and > all of the xbox live ports are open. As an FYI these are not netted > customers, but have true publics. > > We have tried disabling IPV6 on their interfaces and that does not seem to > have helped. We have had some customers power cycle everything in their home > (CPE, router, xbox) and still no go. > > Anyone else running into this? Does Microsoft have a higher level support for > talking with ISPs at all? > > > Justin Wilson > j...@mtin.net > > www.mtin.net > www.midwest-ix.com > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Xbox Live and Teredo
Time to buy a Xbox for the NOC so you can trouble shoot. All puns intended. Mark > On 3 Jan 2018, at 10:15 am, Justin Wilson <li...@mtin.net> wrote: > > These are all Xbox one clients. We don’t hand out IPv6 on this network yet, > so I made sure to disable any sort of IPV6 on the interfaces just to be sure > because I figured Teredo is tied to v6. The only thing we have not done yet > is disable any IPV6 stuff on the customer routers. Everyone has been getting > link local addresses for the longest time. We just disabled ipv6 totally on > the interfaces just to be safe. > > > Justin Wilson > j...@mtin.net > > www.mtin.net > www.midwest-ix.com > >> On Jan 2, 2018, at 6:06 PM, Chris Adams <c...@cmadams.net> wrote: >> >> Once upon a time, Mark Andrews <ma...@isc.org> said: >>> Given that you have IPv6 I would be looking at why the XBOXs are attempting >>> Teredo at all. I would expect them to use the IPv6 addresses that you are >>> assigning your customers. >> >> The OP didn't say what type of Xbox. IIRC the Xbox 360 does not support >> IPv6, while the Xbox One does (but neither would explain the Teredo). >> -- >> Chris Adams <c...@cmadams.net> >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
QWEST you have broken DNS servers
I know it takes some time to upgrade DNS servers to ones that are actually
protocol compliant but 4+ years is ridiculous. Your servers are the only
ones serving the Alexa top 1M sites or the GOV zone that still return BADVERS
to EDNS queries with a EDNS option present. This was behaviour made up by
your DNS vendor. The correct response to EDNS options that are not understood
is to IGNORE them. This allows clients and servers to deploy support for
new options independently of each other.
Additionally this is breaking DNSSEC validation of the signed zones your clients
have you serving. They expect you to be using EDNS compliant name servers for
this role which you are not. No, we are not working around this breakage in the
resolver.
Mark
% dig soa frc.gov. @208.44.130.121 +norec
; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 59707
;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; Query time: 66 msec
;; SERVER: 208.44.130.121#53(208.44.130.121)
;; WHEN: Tue Sep 11 06:08:41 UTC 2018
;; MSG SIZE rcvd: 23
% dig soa frc.gov. @208.44.130.121 +norec +nocookie
; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16876
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;frc.gov. IN SOA
;; ANSWER SECTION:
frc.gov.86400 IN SOA sauthns2.qwest.net.
dns-admin.qwestip.net. 2180320527 10800 3600 604800 86400
;; AUTHORITY SECTION:
frc.gov.86400 IN NS sauthns1.qwest.net.
frc.gov.86400 IN NS sauthns2.qwest.net.
;; Query time: 66 msec
;; SERVER: 208.44.130.121#53(208.44.130.121)
;; WHEN: Tue Sep 11 06:19:33 UTC 2018
;; MSG SIZE rcvd: 145
% grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok |
awk '{print $3}' | sort -u
(sauthns1.qwest.net.):
(sauthns2.qwest.net.):
% grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z | grep
edns=ok | awk '{print $3}' | sort -u
(sauthns1.qwest.net.):
(sauthns2.qwest.net.):
%
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Microsoft your DNS servers are broken
While we are talking about DNS server that are broken, Microsoft your servers are as well. As none of the zones you serve are DNSSEC signed there isn’t as much breakage possible but there are still interoperability problems and unnecessary additional traffic. It’s not like the EDNS specification is complicated. The microsoftonline servers will cause DNSSEC validation to fail if they ever serve a DNSSEC signed zone in this state. The FORMERR will cause EDNS servers to fallback to plain DNS and the validators won’t get the records they need. The azure servers cause problems for anyone deploying a new EDNS options as they have to cope with your servers incorrectly echoing back the option. Additionally if EDNS(1) is ever deployed there is a good chance that resolvers will assume the broken answers indicate that there is no data at the name. Mark cityofharrison-mi.gov. @207.46.15.59 (ns1.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @2a01:111:f406:1804::59 (ns1.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @191.232.83.138 (ns3.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @2a01:111:f406:b400::22 (ns3.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @157.56.81.41 (ns2.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok cityofharrison-mi.gov. @2a01:111:f406:3403::41 (ns2.bdm.microsoftonline.com.): dns=ok edns=ok edns1=ok edns@512=ok ednsopt=formerr,echoed edns1opt=formerr,version-not-zero,echoed do=ok ednsflags=ok optlist=formerr,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @13.107.24.7 (ns3-07.azure-dns.org.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2a01:111:4000::7 (ns3-07.azure-dns.org.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @13.107.160.7 (ns4-07.azure-dns.info.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2620:1ec:bda::7 (ns4-07.azure-dns.info.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @64.4.48.7 (ns2-07.azure-dns.net.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2620:1ec:8ec::7 (ns2-07.azure-dns.net.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @40.90.4.7 (ns1-07.azure-dns.com.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok clintoncounty-ia.gov. @2603:1061::7 (ns1-07.azure-dns.com.): dns=ok edns=ok edns1=noerror,badversion edns@512=ok ednsopt=echoed edns1opt=noerror,badversion do=ok ednsflags=ok optlist=ok,subnet signed=ok ednstcp=ok -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: MTU to CDN's
Which doesn’t work with IPv6 as UDP doesn’t have the field to clamp. -- Mark Andrews > On 20 Jan 2018, at 03:35, Radu-Adrian Feurdean > <na...@radu-adrian.feurdean.net> wrote: > >> On Fri, Jan 19, 2018, at 01:14, Jared Mauch wrote: >> If you’re then doing DSL + PPPoE and your customers really see a MTU >> of 1492 or less, then another device has to fragment 5x again. > > In this part of the world we have even worse stuff around: PPP over L2TP over > over IP with 1500 MTU interconnection. Remove another 40 bytes. Add some more > headers for various tunneling scenarios and you may get into a situation > where even 1400 is too much. But it usually works with MSS clamping to the > correct value. Some small ISPs don't even make the effort to check if the > transport supports "more than 1500" in order to give the 1500 bytes to the > customer - they just clamp down MSS.
Re: Leasing /22
Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that reaches its limit at ~4M customers. Native IPv4 with a GUA to customers is essentially unavailable for new ISPs. It’s a matter of picking which flavour of NAT you and your customers are going to use. The sooner ALL ISP’s provide IPv6 to their customers the sooner we restore delivering the Internet to the customers. Mark > On 23 Jan 2018, at 9:05 am, Lee Howard <l...@asgard.org> wrote: > > IPv6 still solves your problem if you add any of NAT64, DS-Lite, 464xlat, > MAP-T, MAP-E. > > Yes, you’re NATing, but only the traffic to places like Hulu, and it will > decrease over time. And while you need addresses for the outside of the > translator, you don’t need as many (or to get more as frequently). > > Lee > > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" > <nanog-boun...@nanog.org on behalf of na...@ics-il.net> wrote: > >> It's not really scraping the bottom of the barrel if your customers are >> using Hulu and they're complaining because Hulu isn't responsive to >> fixing their problems (geo-location, v6, etc.). >> >> >> >> >> - >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com >> >> - Original Message - >> >> From: "Ca By" <cb.li...@gmail.com> >> To: "Michael Crapse" <mich...@wi-fiber.io> >> Cc: "NANOG list" <nanog@nanog.org> >> Sent: Friday, January 19, 2018 9:54:23 PM >> Subject: Re: Leasing /22 >> >> On Fri, Jan 19, 2018 at 5:48 PM Michael Crapse <mich...@wi-fiber.io> >> wrote: >> >>> Has Hulu, or a thousand other content distributors considered IPv6? >>> Because >>> you can't even tunnel to ipv4 without setting off VPN alarms with HULU. >>> >> >> Hulu? Really scraping the bottom of the barrel of content providers that >> dont use ipv6 these days. >> >> Netflix and Youtube support v6 ... and thousand of others (thousands just >> on Cloudflare where v6 is default on) >> >> About 80% of my traffic is native e2e v6, mostly google / youtube / fb / >> netflix / apple / amazon — but your mix may vary. >> >> >> >>> >>> >>> On 19 January 2018 at 18:38, Andrew Kirch <trel...@trelane.net> wrote: >>> >>>> On Fri, Jan 19, 2018 at 4:59 PM Ryan Gard <ryang...@gmail.com> wrote: >>>> >>>>> We're on the hunt yet again for an additional /22 to lease, and are >>>>> wondering what the best options are out there? >>>>> >>>>> Our usual suspects that we've reached out to in the past seem to be >>> plum >>>>> out... Any recommendations? >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> Ryan Gard >>>>> >>>> Have you considered IPv6? >>>> >>> >> >> > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Leasing /22
Which is where MAP-T and MAP-E help as they reduce the amount of logging required. > On 24 Jan 2018, at 3:59 am, Michael Crapse <mich...@wi-fiber.io> wrote: > > The funnest part is telling DMCA/RIAA that an IP address means nothing, not > without a port and exact time, someitmes down to a 10 minute mark. CGNAT + > NAT64/464 xlat using the fewest ipv4s as possible(as suggested) also requires > a large database to retain all records of every port and ipv4 address > connected with every new connection. > > On 23 January 2018 at 09:56, Ryan Gard <ryang...@gmail.com> wrote: > The biggest problems that start to run with cases of CGN or any other v4 > aggregation method are services that still continue to treat single IP > addresses as a single entity (a certain event ticket vendor comes to mind). > Until these organizations either start opening a line of communications with > ISPs, changing their methodology when handling traffic from v4 addresses, > and/or deploying v6, the song and dance for v4 addressing will continue. > > On Mon, Jan 22, 2018 at 7:57 PM, Lee Howard <l...@asgard.org> wrote: > > > From: Michael Crapse <mich...@wi-fiber.io> > Date: Monday, January 22, 2018 at 5:27 PM > To: Mark Andrews <ma...@isc.org> > Cc: Lee Howard <l...@asgard.org>, NANOG list <nanog@nanog.org> > Subject: Re: Leasing /22 > > > Customers on ps4s and xboxes will hate you. They will always get "strict" > > nat, > > and it's your fault not mega corporation X's fault for not releasing IPv4s > > Maybe. You don’t have to configure strict NAT on your translator (DS-Lite’s > pretty good at this, and although I’m a few weeks away from testing consoles > through 464xlat and MAP, they should work, too). And their NAT workarounds > are pretty sophisticated now. > > There comes a point when winning your customers’ love isn’t profitable. I > don’t know if that point is $16/address for you, or $30, or $40, or $90. > Maybe it varies, depending on the customer. > > That’s why I suggested in “TCO of CGN”[1] that everyone figure out for > themselves how much money you might lose to unhappy customers via CGN, and > compare it to how much addresses cost, and at what price point you might > turn around and sell addresses. My findings then, based on assumptions that > almost certainly are not true for any particular network, and which may have > changed, suggest that buying addresses still makes sense. > > > Lee > > [1] http://ipv6.nanog.org/meetings/abstract?id=2025 > > > > > > On 22 January 2018 at 15:23, Mark Andrews <ma...@isc.org> wrote: > >> Add to that CGN from RFC 6598 addresses (100.64/10) + IPv6 though that > >> reaches its limit at ~4M customers. > >> > >> Native IPv4 with a GUA to customers is essentially unavailable for new > >> ISPs. It’s a matter of picking which flavour of NAT you and your > >> customers are going to use. The sooner ALL ISP’s provide IPv6 to their > >> customers the sooner we restore delivering the Internet to the customers. > >> > >> Mark > >> > >>> > On 23 Jan 2018, at 9:05 am, Lee Howard <l...@asgard.org> wrote: > >>> > > >>> > IPv6 still solves your problem if you add any of NAT64, DS-Lite, > >>> > 464xlat, > >>> > MAP-T, MAP-E. > >>> > > >>> > Yes, you’re NATing, but only the traffic to places like Hulu, and it > >>> > will > >>> > decrease over time. And while you need addresses for the outside of the > >>> > translator, you don’t need as many (or to get more as frequently). > >>> > > >>> > Lee > >>> > > >>> > On 1/20/18, 10:20 AM, "NANOG on behalf of Mike Hammett" > >>> > <nanog-boun...@nanog.org on behalf of na...@ics-il.net> wrote: > >>> > > >>>> >> It's not really scraping the bottom of the barrel if your customers > >>>> >> are > >>>> >> using Hulu and they're complaining because Hulu isn't responsive to > >>>> >> fixing their problems (geo-location, v6, etc.). > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> - > >>>> >> Mike Hammett > >>>> >> Intelligent Computing Solutions > >>>> >> http://www.ics-il.com > >>>> >> > >>>> >> Midwest-IX > >>>> >> http://www.midwest-i
Re: OpenDNS CGNAT Issues
> On 11 Sep 2018, at 11:07 pm, Aled Morris via NANOG wrote: > > On Tue, 11 Sep 2018 at 13:56, Ca By wrote: > You should provide your users ipv6, opendns supports ipv6 and likely will not > have this issue you see > > OpenDNS does not support IPv6 for their customisable services "Home" etc. > which I believe is the service the OP is using as he refers to the end-user > wanting to register their IP address. We really should get away from using IP addresses for identifying anything. At the DNS level you can use a EDNS option to identify the client rather than the IP address. I believe their Umbrella product does this. You can also use TSIG to identify clients independent of IP address. We added TSIG support to libresolv right at the beginning of the century. Mark > Incidentally, I hope OpenDNS considers 100.64.0.0/10 as space that can't be > registered to any end-user. > > Aled -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Is WHOIS going to go away?
Whois contact details need to work so you can contact the zone owner when the DNS is broken for the zone. Publishing Whois data in the zone does not work for this purpose. This is not to discount other reasons for having a independent communications channel. -- Mark Andrews > On 21 Apr 2018, at 08:17, Brian Kantor <br...@ampr.org> wrote: > > Steve, > > I believe you are mistaken as to current law in the USA: > > The Supreme Court has ruled repeatedly that the right to anonymous > free speech is protected by the First Amendment. A frequently cited > 1995 Supreme Court ruling in McIntyre v. Ohio Elections Commission > reads: Anonymity is a shield from the tyranny of the majority... > > Google for that phrase "anonymity is a shield from the tyranny of > the majority" to see more references. > > I'll drop the discussion here, as it's likely to only continue down > the rathole and I've said my piece. >- Brian
Re: Is WHOIS going to go away?
You have a logic fail. This fails because it STILL depends on the DNS for the zone working. -- Mark Andrews > On 22 Apr 2018, at 07:27, Lyndon Nerenberg <lyn...@orthanc.ca> wrote: > > >> On Apr 21, 2018, at 1:58 PM, b...@theworld.com wrote: >> >> That's actually an excellent point and counterpoint to my suggestion >> to move the WHOIS information into DNS RRs. >> >> But backup and failover are reasonably well understood technologies >> where one cares. Registrars could for example cache copies of those >> zone records and act as failover whois servers. > > Instead of putting the contact info directly into the DNS, put pointers to > the locations of the data instead. I.e. whois moves off dedicated ports and > hardwired servers and into zone-controlled SRV records: > > _whois._tcp.orthanc.ca SRV 0 0 43 orthanc.ca. > SRV 5 0 43 backup.otherdomain.example.com. > > This gives each zone control of the information they want to export (by > directing whois(1) to what they consider to be authoritative servers). > > The domain owners themselves could control the information they chose to > expose to the public, through the SRV records, and the information they chose > to publish in the whois servers those records point at. If the domain owner > is happy with their (say) registrar providing that information, they would > just point the appropriate SRV record at the registrar. This is no different > from how people handle email outsourcing via MX records. > > The idea that whois is in any way authoritative is long gone. Those who want > to hide have been able to do that for ages. (I think I pay $15/year to mask > some of the domains I control.) But for law enforcement, a warrant will > always turn up the payment information used to register a domain, should the > constabulary want to find that information out. And for court proceedings, > whois data is useless. (I speak from $WORK experience.) > > --lyndon >
Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE
> On 3 Apr 2018, at 1:39 am, Seth Mattinen <se...@rollernet.us> wrote: > > On 4/2/18 8:35 AM, Simon Lockhart wrote: >> This looks like a willy-waving exercise by Cloudflare coming up with the >> lowest >> quad-digit IP. They must have known that this would cause routing issues, and >> now suddenly it's our responsibility to make significant changes to live >> infrastructures just so they can continue to look clever with the IP address. > > > To be fair, nobody should have been using 1/8 for anything. Stop living in the 1900’s. Parts to 1/8 have be allocated to people for years now. 1.0.0/24 and 1.2.3/24 have been used for various experiments but the rest of 1/8 is being allocated for normal use (there may be a couple of more exceptions). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)
> On 2 Mar 2018, at 9:28 am, Owen DeLong <o...@delong.com> wrote: > > >> On Mar 1, 2018, at 1:20 PM, Harald Koch <c...@pobox.com> wrote: >> >> On 1 March 2018 at 15:18, Owen DeLong <o...@delong.com >> <mailto:o...@delong.com>> wrote: >> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly >> anyone >> uses ULA (the IPv6 analogue to RFC-1918). >> >> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there >> something new? > > No particular objection, but I don’t see the point. > > What can you do with ULA that GUA isn’t suitable for? > > Owen ULA provide stable internal addresses which survive changing ISP for the average home user. Now, I know you can do the same thing by going to a RIR and getting a prefix but the RIR’s aren’t setup to supply prefixes like that to 10 billion of us. They are also in a specific range which makes setting filtering rules easier for everyone else. Now I would love it if we could support 100 billion routes in the DFZ but we aren’t anywhere near being able to do that which would be a requirement for abandoning ULA. Until them they have there place. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)
> On 2 Mar 2018, at 11:48 am, Matt Erculiani <merculi...@gmail.com> wrote: > > Not sure if this is the common thought, but if anyone has a network > which requires static IP assignments, they can probably justify a > request for a /48 from an RIR. After all, ARIN's requirement for an > end-user IPv6 block is, at minimum: "Justify why IPv6 addresses from > an ISP or other LIR are unsuitable". I would think that ISP > portability would satisfy this requirement, but If I'm wrong, I'm > absolutely open to being corrected on this. But most home users have > no need for static IPs, so the dynamic ISP assignment is perfectly > fine. ISP assigned addresses are perfectly fine for TALKING TO THE REST OF THE WORLD. ISP assigned addresses are not perfectly fine for internal communication. With IPv6 you use ULA along side ISP assigned addresses. With IPv4 RFC 1918 address + NAT the home user has STATIC local addresses for devices that need them. Go look at your home router’s web pages. You will be able to assign static addresses to your internal machines via DHCP. Are YOU going to tell everyone that sets values there that they no longer can do the same thing for IPv6. That they need to fully renumber all their devices just because the ISP gave them a different prefix this morning? > I think the tech will advance fast enough that keeping up with an IPv6 > route table will be a non-issue. IPv6 adoption is, unfortunately, slow > enough that there will be no issues keeping up, even assuming a "slow" > hardware refresh cycle. > > -M > > On Thu, Mar 1, 2018 at 5:48 PM, Mark Andrews <ma...@isc.org> wrote: >> >>> On 2 Mar 2018, at 9:28 am, Owen DeLong <o...@delong.com> wrote: >>> >>> >>>> On Mar 1, 2018, at 1:20 PM, Harald Koch <c...@pobox.com> wrote: >>>> >>>> On 1 March 2018 at 15:18, Owen DeLong <o...@delong.com >>>> <mailto:o...@delong.com>> wrote: >>>> Second, RFC-1918 doesn’t apply to IPv6 at all, and (fortunately) hardly >>>> anyone >>>> uses ULA (the IPv6 analogue to RFC-1918). >>>> >>>> Wait. What's the objection to ULA? Is it just that NAT is bad, or is there >>>> something new? >>> >>> No particular objection, but I don’t see the point. >>> >>> What can you do with ULA that GUA isn’t suitable for? >>> >>> Owen >> >> ULA provide stable internal addresses which survive changing ISP >> for the average home user. Now, I know you can do the same thing >> by going to a RIR and getting a prefix but the RIR’s aren’t setup >> to supply prefixes like that to 10 billion of us. >> >> They are also in a specific range which makes setting filtering >> rules easier for everyone else. >> >> Now I would love it if we could support 100 billion routes in the >> DFZ but we aren’t anywhere near being able to do that which would >> be a requirement for abandoning ULA. Until them they have there >> place. >> >> Mark >> -- >> 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: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks
Are you insane. ISPs should never use RFC 1918 addresses for stuff that talks to their customers. They have no way of knowing which addresses the customers are using. Traffic from RFC 1918 addresses should be dropped by any sane border router which all routers connecting to a ISP are. -- Mark Andrews > On 2 Mar 2018, at 22:49, Bjørn Mork <bj...@mork.no> wrote: > > Owen DeLong <o...@delong.com> writes: > >> I don’t agree that making RFC-1918 limitations a default in any daemon makes >> any >> sense whatsoever. > > +1 > > One of the more annoying anti-features I know of in this regard is the > dnsmasq rebind "protection". It claims to protect web browsers on the > LAN against DNS rebind attacks. But the implementation does not > consider which adresses are used on the LAN at all. It simply blocks > any A record pointing to an RFC1918 address, making a few bogus > assumptions: > - IPv4 LAN addresses are selected from RFC1918 > - RFC1918 addresses are never used on the WAN side of a CPE > - Noone use IPv6 on their LAN > > It's hard to know how many users have been bitten by the first > one. You'd have to depend on this rebind "protection" in the first > place, and that would be stupid. > > But the second assumption regularily bites end users when their ISP > provides some ISP internal service using RFC1918 addresses. Which of course > is fine. > > The anti-feature has been enabled by default in OpenWrt for a long time, > ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that > there is a large user base having this enabled without knowing. > >> First, there are plenty of LANs out there that don’t use RFC-1918. >> >> Second, RFC-1918 doesn’t apply to IPv6 at all, > > Could you try to explain that to the OpenWrt guys? Thanks > > > > Bjørn
Re: WIndows Updates Fail Via IPv6
Which just shows content providers and tunnel end point problems.
* load balancers that don’t properly handle ICMP{v6}
* stupid firewalls that block PTB
* tunnel end points that don’t generate PTB for EVERY oversize packet
(you wouldn’t drop TCP ACKS and PTBs are just as important)
PMTD requires PTBs to be generated.
Report the problems so they can get fixed.
Mark
> On 13 Nov 2018, at 6:08 am, John Von Essen wrote:
>
> I recently go a Linksys home wifi router, by default it enables ipv6 on the
> LAN. If there is no native IPv6 on the WAN side (which is my case since FiOS
> doesnt do v6 yet) the Linksys defaults to a v6 tunnel.
>
> For the first few weeks of using the router, I had no idea alot of my traffic
> was going out via the v6 tunnel.
>
> Then I started getting random reachability and availability issues. Google
> would not load, but Bing and Yahoo would, and so on. I thought it was a FiOS
> issue, but after digging, I discovered the v6 tunnel, disabled it and all my
> issues went away.
> I dont know what Linksys uses for the v6 tunnel because its buried in the
> firmware, but any tunnel service is vulnerable to a variety of issues that
> could effect access. Its odd that it always effects Windows update all the
> time, but who knows.
>
> -John
>
> On 11/12/18 1:18 PM, Mark Tinka wrote:
>>
>>
>> On 11/Nov/18 18:51, Lavanauts wrote:
>>
>>> I’m on native IPv6 via Spectrum and have no problems with Windows Updates.
>>> Could this be a tunneling issue?
>>
>> I do run 6-in-4 from my backbone to my house as my FTTH provider does not do
>> IPv6.
>>
>> I can't imagine this to specifically be the issue, as all other IPv6 traffic
>> is fine, but at this point, I'm open to suggestion.
>>
>> Mark.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: v6 DNSSEC fail, was Buying IPv4 blocks
> On 5 Oct 2018, at 3:12 pm, Mark Tinka wrote:
>
>
>
> On 5/Oct/18 03:07, John Levine wrote:
>
>> Yeah, V6 UDP fragmentation and anycast are bad news. You can sort of
>> fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot
>> easier to stick to v4.
>>
>> Geoff Huston has written about this a lot and it's a well known problem
>> in the DNS community. I'm surprised if it's news to anyone here.
>>
>>
>> https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/
>
> In BIND, I think this can be solved by using the "minimal-responses" knob.
>
> Mark.
If you don’t want fragmented IPv6 UDP responses use
server ::/0 { edns-udp-size 1232; };
That’s 1280 - IPv6 header - UDP header. Anything bigger than that can
theoretically
be fragmented. You will then have to deal with PMTUD failures as the servers
switch
over to TCP.
What I find ridiculous is firewall vendor that claim to support adding stateful
rules
on demand but don’t add “from to frag offset != 0” when they add
“from to proto xxx src-port dst-port ” or
don’t do packet reassembly to
work around the lack of passing fragments. This is IP and fragments are part
and parcel of IP whether it is IPv4 or IPv6.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: v6 DNSSEC fail, was Buying IPv4 blocks
> On 5 Oct 2018, at 4:22 pm, Brandon Martin wrote:
>
> On 10/5/18 1:53 AM, Mark Andrews wrote:
>> If you don’t want fragmented IPv6 UDP responses use
>> server ::/0 { edns-udp-size 1232; };
>> That’s 1280 - IPv6 header - UDP header. Anything bigger than that can
>> theoretically
>> be fragmented. You will then have to deal with PMTUD failures as the
>> servers switch
>> over to TCP.
>
> Speaking of, anyone have any good reports similar to that which was the
> genesis of this discussion but regarding PMTUD broken-ness on IPv6? Perhaps
> specifically focusing on its impact w.r.t DNS over TCP?
>
> My understanding is that this is quite common on IPv4 but not as evident due
> to in-transit transparent fragmentation.
>
>> What I find ridiculous is firewall vendor that claim to support adding
>> stateful rules
>> on demand but don’t add “from to frag offset != 0” when they add
>> “from to proto xxx src-port dst-port ” or
>> don’t do packet reassembly to
>> work around the lack of passing fragments. This is IP and fragments are part
>> and parcel of IP whether it is IPv4 or IPv6.
>
> I think the "justification" for not allowing fragments is that they can be
> crafted specifically to evade filter policies.
So require frag 0 to have what you require to do the filtering. Most stacks
send maximal sized initial fragments up to 1280 bytes. For DNS the UDP header
will be there as there is at least 8 bytes of fragmented packet. Additionally
reassembly attacks are much harder as there is 32 bits of fragmentation
identifier rather than 16 in IPv4.
IPv6 fragmentation was designed with knowledge of the IPv4 reassembly attacks
in mind.
> Now, I'd argue that, if you want to not be a broken device, you then need to
> do reassembly so that you can inspect. At minimum, do so for the typical
> attack case which uses very small fragments and/or large L3 headers to split
> up application data since the result is presumably something that fits within
> the MTU of your LAN. Or statefully track whether fragments are expected for
> a conversation. Or drop fragments that could be used to evade policies but
> permit fragments that couldn't. Or...something other than breaking things
> horribly and whining that the protocol is broken.
>
> Of course, a lot of these are also the same boxes that, through design or
> misconfiguration, break PMTUD, too, I suspect.
> --
> Brandon Martin
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Deploying IPv6 XLAT64
> On 27 Sep 2018, at 4:22 am, Matt Hoppes > wrote: > > Thanks... that is what I don't understand: Why is NAT64 such a difficult > concept to put into routers and firewalls? We already do NAT with IPv4 just > fine. It’s not s difficult concept but you need to remember NAT44 breaks stuff and NAT64/NAT46 breaks more stuff. > I feel like IPv6 adoption would be much faster if there was a transition > mechanism other than dual stacking. Dual stacking is SIMPLE. REALLY. Turn on IPv6 with the M bit set and configure the DHCPv6 server. If you don’t need that level of control of address assignments leave the M bit off. 99.99% of your machines will just add a second address to the interface without you having to do anything more. > Think: Corporate offices. Rather than renumbering everything inside, they > just turn on NAT64 and now they can begin a slow and controlled transition. Getting to IPv6 resources from IPv4 address is a *much* harder problem that getting to IPv4 resources from IPv6 which is what you are describing here with the “no renumber everything as they already have a IPv4 address” requirement. NAT64 allows IPv6 devices to get to legacy IPv4 servers. To allow IPv4 devices to get to IPv6 servers you need to map the IPv6 addresses you want to talk to in to a pool of IPv4 addresses and push that mapping to a NAT46 (not NAT64) device. Go dual stack then, once IPv6 is stable, turn off IPv4 if you want to be single stacked. You are then no longer dependent on the services you want want to access continuing to be offered over IPv4. 464XLAT will only work as a stop gap for IPv4 clients while services are offered over IPv4. After ~20 years of IPv6 being available (Windows XP had IPv6 support and it was not the first major OS to have it) just turn on IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
ECN, DNS and Firewalls
There are major operators that still have STUPID firewall settings in front of DNS servers that drop SYN packets with ECE and CWR set 17 years after ECN was specified. Do you really want to add a second to EVERY DNS lookup that needs to use TCP? Modern OS actually attempt to use ECN by default. DNS is time critical enough without introducing unnecessary delays. If you have signed zones then TCP requests are almost certainly being made to your servers. EVERYONE TEST YOUR SERVERS FROM OUTSIDE YOUR NETWORK AND FIX THE BROKEN FIREWALLS THAT ARE FOUND. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ECN, DNS and Firewalls
> On 28 Dec 2018, at 2:49 pm, valdis.kletni...@vt.edu wrote: > > On Fri, 28 Dec 2018 13:35:04 +1100, Mark Andrews said: >> There are major operators that still have STUPID firewall settings >> in front of DNS servers that drop SYN packets with ECE and CWR set >> 17 years after ECN was specified. > > Time to name-n-shame? No yet. Let people test and fix their firewalls first. A test machine should be sending [SEW] and getting back [S.E] or [S.] in the TCP flags using tcpdump depending upon whether the DNS server’s TCP stack supports ECN or not. e.g. 11:35:50.335713 IP6 2001:470:a001:3:f1f2:b12d:4b18:d934.50670 > 2001:7fe::53.53: Flags [SEW], seq 3764146938, win 65535, options [mss 1220,nop,wscale 5,nop,nop,TS val 522561237 ecr 0,sackOK,eol], length 0 11:35:50.745472 IP6 2001:7fe::53.53 > 2001:470:a001:3:f1f2:b12d:4b18:d934.50670: Flags [S.E], seq 1542147586, ack 3764146939, win 14280, options [mss 1440,sackOK,TS val 1392826170 ecr 522561237,nop,wscale 7], length 0 or 11:40:35.360655 IP6 2001:470:a001:3:f1f2:b12d:4b18:d934.50697 > 2001:502:8cc::30.53: Flags [SEW], seq 81498720, win 65535, options [mss 1220,nop,wscale 5,nop,nop,TS val 522845405 ecr 0,sackOK,eol], length 0 11:40:35.589420 IP6 2001:502:8cc::30.53 > 2001:470:a001:3:f1f2:b12d:4b18:d934.50697: Flags [S.], seq 987294478, ack 81498721, win 1220, options [mss 1220], length 0 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues
> On 12 Jan 2019, at 6:36 am, Töma Gavrichenkov wrote: > > 11 Jan. 2019 г., 22:33 Rob McEwen : > > but if done right, fwiw,, wouldn't that > > be sent over SMTP using TLS encryption > > So STARTTLS strip is not a problem anymore? If you deploy DANE (client and server sides) then stripping STARTTLS is ineffective for the target domain. We (isc.org) have but gmail.com hasn’t (server side at least). On could be asking why you are using gmail.com when they don’t care enough to signal to the world that STARTTLS is supported and should be there in the EHLO. % dig mx isc.org +dnssec ;; BADCOOKIE, retrying. ; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4910 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 13 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: bfabca20a2ed6fe032fae4e75c38f7eecca21769def0a3e3 (good) ;; QUESTION SECTION: ;isc.org. IN MX ;; ANSWER SECTION: isc.org.7140IN MX 20 mx.ams1.isc.org. isc.org.7140IN MX 10 mx.pao1.isc.org. isc.org.7140IN RRSIG MX 5 2 7200 20190206233314 20190107233314 19923 isc.org. UBu26XwokUyCwZvBzp5+kajy686RF4cdA/Un3Z3vtEARG8qx0hQfHoTk lGfGPkt21QdZmqX+ZJcdO3LfA+qU9A3aEJMXZi9aMZkPDWu1aPsJBu6U 3U3Tj9j+DsqL2Uk780TAqQQQWFUwIHF+y0hcRIWPaqUuvygl/5jxdVDN Mls= ;; ADDITIONAL SECTION: mx.pao1.isc.org.3541IN A 149.20.64.53 mx.ams1.isc.org.3544IN A 199.6.1.65 mx.pao1.isc.org.3541IN 2001:4f8:0:2::2b mx.ams1.isc.org.3544IN 2001:500:60::65 mx.pao1.isc.org.3541IN RRSIG A 5 4 3600 2019020623 2019010723 13902 pao1.isc.org. WrDcCGC0SmNUSh+DBxogVXWU2PQVpJ/6S/WJxpU4fLDpI+0J85aep+e1 NwZRUuw9N5RRuslQSz0y+aiwB0RACq2wbPUxDem21KpzKE8rlrAlf0U9 k9sT1PeCkWu7QOiWgEksnoJijyCVY41Q/GB0HnWzaO4jUtay6e/PBj4c IiA= mx.pao1.isc.org.3541IN RRSIG 5 4 3600 2019020623 2019010723 13902 pao1.isc.org. EaYgxAGrmJ9oiX4u2DfIcHKCqen3RNGylmWT0VjJ8VWY5e/c5TA1eI5U evGsvYhvLD4WvR8hzvKxp4Pc5EYKLoB+YRI4ttUgnTydsEI0xFCcgB4+ dFb+89h8e6tHSPhUa1wa7ObriKm1O5FzplEXLfNFbgEUN6oJOIMw7q8w cC8= _25._tcp.mx.pao1.isc.org. 3543 IN RRSIG TLSA 5 6 3600 2019020623 2019010723 13902 pao1.isc.org. liSDcLgGpDXqgTxkv2sQBI3OsACPflpxoZxcrgSge4yTe5gA97NOPe0l ECmDBPzUkhcRI6Mwv+uBCmm5FBvgh0leNxLXzACdkCX8EscE3v74wd5o ReCRGFAhV6TBjycwejkGARVTYF23RyRflq2/fRV2hoOdH2ImcW7/SMqA 8Jg= mx.ams1.isc.org.3544IN RRSIG A 5 4 3600 20190206233315 20190107233315 5730 ams1.isc.org. E+6nzEbFAcftlr3UTaCcw0LAHYIdVe5TNfyIwVwU71AzZB22jiif/BrQ KxemOrR7LT7ukfDRjnEzfV1/s0Wwfxh0b79otxrDwssKzNKz9XhaIhVf j17oyuQBkYjYv5RBuwsrmKQmSbu56Zu7G35xp2qbKi6E+3lpXPghnrnJ DBk= mx.ams1.isc.org.3544IN RRSIG 5 4 3600 20190206233315 20190107233315 5730 ams1.isc.org. ov/6HUTx8v7t31KBYVgDy02Bpe8rJX431vPDdRZvKKhffFrYmUOIXEqD Q/3+DNV1axSJCTONJ1NwzoSC8LDwQQFUcAsXnhcW/C/Z3rbaEthetmmP TERuRGjF3QdA+qFM8RCc83s+hp1RXo5cU+9wA8OTPT5nTmfthkDs/cUi 0o8= _25._tcp.mx.ams1.isc.org. 3545 IN RRSIG TLSA 5 6 3600 20190206233315 20190107233315 5730 ams1.isc.org. qdzOyIbkPhufqw6/B5bwpxJ0pfVeUay2v8O5spUa+xgHdLQFNS851vlW KOYrNfZALDomXkOyfAVTEZXQ1g3xf0gzIcRCy0PHcgDtgl5a56AilFGB n6LZVkh6lbAkQ8lSmlKWmOvAmJnXh6L6dX8/CQzpWT7G0EEL1EcvLW6p uZ0= _25._tcp.mx.pao1.isc.org. 3543 IN TLSA3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0 _25._tcp.mx.ams1.isc.org. 3545 IN TLSA3 0 1 5EF9B10DA21B2711522982EAD699FBABE77FD07FF07AC810608A85DA 66AFE916 ;; Query time: 7 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jan 12 07:09:18 AEDT 2019 ;; MSG SIZE rcvd: 1555 % > -- > Töma -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: QWEST you have broken DNS servers
Yes please.
> On 13 Sep 2018, at 2:45 am, Anne P. Mitchell, Esq.
> wrote:
>
>
> Would you like us to send this to our Qwest/CenturyLink contact?
>
> Anne P. Mitchell,
> Attorney at Law
> GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Legislative Consultant
> CEO/President, Institute for Social Internet Public Policy
> Legal Counsel: The CyberGreen Institute
> Legal Counsel: The Earth Law Center
> Member, California Bar Association
> Member, Cal. Bar Cyberspace Law Committee
> Member, Colorado Cyber Committee
> Member, Board of Directors, Asilomar Microcomputer Workshop
> Ret. Professor of Law, Lincoln Law School of San Jose
> Ret. Chair, Asilomar Microcomputer Workshop
>
>
>
>>
>> I know it takes some time to upgrade DNS servers to ones that are actually
>> protocol compliant but 4+ years is ridiculous. Your servers are the only
>> ones serving the Alexa top 1M sites or the GOV zone that still return BADVERS
>> to EDNS queries with a EDNS option present. This was behaviour made up by
>> your DNS vendor. The correct response to EDNS options that are not
>> understood
>> is to IGNORE them. This allows clients and servers to deploy support for
>> new options independently of each other.
>>
>> Additionally this is breaking DNSSEC validation of the signed zones your
>> clients
>> have you serving. They expect you to be using EDNS compliant name servers
>> for
>> this role which you are not. No, we are not working around this breakage in
>> the
>> resolver.
>>
>> Mark
>>
>> % dig soa frc.gov. @208.44.130.121 +norec
>>
>> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 59707
>> ;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; Query time: 66 msec
>> ;; SERVER: 208.44.130.121#53(208.44.130.121)
>> ;; WHEN: Tue Sep 11 06:08:41 UTC 2018
>> ;; MSG SIZE rcvd: 23
>>
>> % dig soa frc.gov. @208.44.130.121 +norec +nocookie
>>
>> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec +nocookie
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16876
>> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;frc.gov.IN SOA
>>
>> ;; ANSWER SECTION:
>> frc.gov. 86400 IN SOA sauthns2.qwest.net.
>> dns-admin.qwestip.net. 2180320527 10800 3600 604800 86400
>>
>> ;; AUTHORITY SECTION:
>> frc.gov. 86400 IN NS sauthns1.qwest.net.
>> frc.gov. 86400 IN NS sauthns2.qwest.net.
>>
>> ;; Query time: 66 msec
>> ;; SERVER: 208.44.130.121#53(208.44.130.121)
>> ;; WHEN: Tue Sep 11 06:19:33 UTC 2018
>> ;; MSG SIZE rcvd: 145
>>
>> % grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok |
>> awk '{print $3}' | sort -u
>> (sauthns1.qwest.net.):
>> (sauthns2.qwest.net.):
>> % grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z | grep
>> edns=ok | awk '{print $3}' | sort -u
>> (sauthns1.qwest.net.):
>> (sauthns2.qwest.net.):
>> %
>>
>> --
>> 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: DNS Flag Day, Friday, Feb 1st, 2019
> On 25 Jan 2019, at 12:50 am, Bjørn Mork wrote: > > Mark Andrews writes: > >> I’ve been complaining for YEARS about lack of EDNS compliance. > > Didn't help. Perfect vs incremental improvement. Please go look at the graphs on ednscomp.isc.org. You will see the fixes being applied. You can see firewalls being removed. You can seen IPv6 being deployed on DNS server farms with broken DNS servers. You can see when name servers are fixed to remove implementation flaws. > bjorn@miraculix:~$ dig +edns=42 +noednsnegotiation @1.1 > > ; <<>> DiG 9.11.5-P1-1-Debian <<>> +edns=42 +noednsnegotiation @1.1 > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40525 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1452 > ;; QUESTION SECTION: > ;. IN NS > > ;; ANSWER SECTION: > . 9060IN NS d.root-servers.net. > . 9060IN NS e.root-servers.net. > . 9060IN NS f.root-servers.net. > . 9060IN NS g.root-servers.net. > . 9060IN NS h.root-servers.net. > . 9060IN NS i.root-servers.net. > . 9060IN NS j.root-servers.net. > . 9060IN NS k.root-servers.net. > . 9060IN NS l.root-servers.net. > . 9060IN NS m.root-servers.net. > . 9060IN NS a.root-servers.net. > . 9060IN NS b.root-servers.net. > . 9060IN NS c.root-servers.net. > > ;; Query time: 3 msec > ;; SERVER: 1.0.0.1#53(1.0.0.1) > ;; WHEN: Thu Jan 24 14:40:00 CET 2019 > ;; MSG SIZE rcvd: 431 > > > > Bjørn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
> On 25 Jan 2019, at 2:14 am, Stephen Satchell wrote: > > On 1/23/19 8:44 PM, Mark Andrews wrote: >> and they your firewalls don’t block well formed DNS queries (lots of >> them do by default). > > My edge routers block *all* inbound DNS requests -- I was being hit by a > ton of them at one point. Cavaet: I don't run a DNS server that is a > domain zone master -- I use a DNS service for that. I do have a DNS > server inside, but only to handle recursive requests from inside my network. > > Outbound DNS requests? Lets them through, and responses too. Well does your DNS service properly manage the firewall in front of their servers? Does the anti DoS scrubbing service they are using also pass the well formed packets to the DNS server they are advertising? This was about testing the servers YOU directly or indirectly advertise to the world. It also applies to any recursive servers. They too need properly handle EDNS queries in all their forms. The test tool has a recursive mode for testing them (genreport -R). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: GPS rollover
Sounds like something that should be reported to the FDA. -- Mark Andrews > On 6 Apr 2019, at 10:47, Eric Parsonage wrote: > > > I personally fell foul of this last night. My CPAP machine switched itself > off. It has an internal cellular modem which it uses to exchange usage data > but since I never have to set the date and time I assume it gets this from my > cellular network. Its hardly a graceful fail when the air supply turns > itself off. > > > > > >
Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking
> On 28 Feb 2019, at 7:28 am, Måns Nilsson wrote: > > Subject: Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS > Hijacking Date: Wed, Feb 27, 2019 at 01:07:09PM -0500 Quoting John Levine > (jo...@iecc.com): >> In article <20190227161327.ga27...@besserwisser.org> you write: >>> that is RFC 7208.[0] >> >>> [0] This document tries to deprecate RRTYPE 99 for SPF. By stating that >>> only TXT records can be trusted. ... >> >> This must be a very different RFC 7208 from the one that the IETF published. >> >> The IETF one says that nobody used type 99, and some of the few >> implementations >> we saw were broken, so we deprecated it. > > We will never agree on that. Because I think you were, and are, > wrong. Mostly out of eagerness and lack of patience. Agreed. Additionally it suddenly went from something being done along with a experiment to being “a experiment on can you transition to a new type”. The transition to type99 was well underway. The libraries that supported it where being deployed. New MTAs where using using them. Type99 was being published. There was BS about not interoperating with old libraries that only looked for TXT records. The only response to that should have been “doh, go update the code” and maybe set a date for stopping falling back to TXT. > I'm fairly certain you think I have no idea what I'm talking about. But, > to rehash, a little less subtle: > > My point was that the general state of criminal ignorance about the > finer nuances of DNS is so wide spread that around 2038 we'll have an > abstraction layer entirely built out of mile-long CNAME chains, because > nobody remembers any other record type. CNAMEs we tried to forget too, > replacing them with something out of the olde annals of Compuserve, but > since the golden standard of resiliency and load balancing is a chain > of them pointing into a bookstore's spare servers, we really can't do > without them. > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE SA0XLR+46 705 989668 > Don't worry, nobody really LISTENS to lectures in MOSCOW, either! ... > FRENCH, HISTORY, ADVANCED CALCULUS, COMPUTER PROGRAMMING, BLACK > STUDIES, SOCIOBIOLOGY! ... Are there any QUESTIONS?? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: > > > > On 5/Mar/19 00:25, Mark Andrews wrote: > >> >> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >> they have installed broken ECMP devices. The simplest way to do that >> is to set the interface MTUs to 1280 on all the servers. Why should >> the rest of the world have to put up with their inability to purchase >> devices that work with RFC compliant data streams. > > I've had this issue with cdnjs.cloudflare.com for the longest time at my > house. But as some of you may recall, my little unwanted TCP MSS hack > for IPv6 last weekend fixed that issue for me. > > Not ideal, and I so wish IPv6 would work as designed, but… It does work as designed except when crap middleware is added. ECMP should be using the flow label with IPv6. It has the advantage that it works for non-0-offset fragments as well as 0-offset fragments and also works for transports other than TCP and UDP. This isn’t a protocol failure. It is shitty implementations. > Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: WIndows Updates Fail Via IPv6 - Update!
> On 6 Mar 2019, at 3:37 pm, Fernando Gont wrote: > > On 6/3/19 01:09, Mark Andrews wrote: >> >> >>> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: >>> >>> On 3/3/19 18:04, Mark Andrews wrote: >>>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB >>>> getting >>>> back to the TCP servers. There are also IDIOTS that deploy load balancers >>>> that >>>> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the >>>> correct >>>> back end. There are also IDOITS that rate limit PTB generation to >>>> ridiculously >>>> low rates. One should be able to generate PTB at line rate. >>>> >>>> Everyone that has configured mss-fix-up has contributed to >>>> misunderstanding that >>>> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up >>>> from all >>>> the boxes you control. We need to get PTB working and unfortunately that >>>> means >>>> that we need to stop pandering to admins who don’t know how IP is supposed >>>> to >>>> work. ICMP is NOT optional. >>> >>> It would seem IETF's intention is to actually move away from >>> ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). >> >> Which is not a reason to not fix broken equipment and misconfigured >> firewalls. >> The workarounds are basically there because people deploy broken equipment. > > Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have > hopes it will be different with IPv6? Make a big enough stink and it will get fixed. People just don’t make enough of a stink. Use social media. None of the companies with broken firewalls really want their idiotic practices pointed out in public. Start doing so every time you see it #STUPIDFIREWALL. > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A Deep Dive on the Recent Widespread DNS Hijacking
ack,” he said. “If they had been more skilled they would > have removed DNSSEC on the domain, which they could have done.” > """ > > If you manage to get access to the change the dns delegation at the > parent you can also turn DNSSEC off. Clearly the scripties managed to do > this once but "forgot" to do it the second time around ... That they also > "forgot" to disable DNSSEC on PCH is not particularly relevant. It only goes > to prove my point that DNSSEC is irrelevant and only gives a false sense of > security (for this particular attack vector). I suppose you could have > really long timeouts on your DS records, but that would merely "complicate" > matters for the scripties and would not be protective ... > > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven > says a lot about anticipated traffic volume. > > >-Original Message- > >From: Montgomery, Douglas (Fed) [mailto:do...@nist.gov] > >Sent: Sunday, 24 February, 2019 15:38 > >To: nanog@nanog.org > >Cc: kmedc...@dessus.com > >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > > > >You might have missed reading the very article you cite. > > > >"Woodcock said PCH’s reliance on DNSSEC almost completely blocked > >that attack, but that it managed to snare email credentials for two > >employees who were traveling at the time. > > > >Aside from that, DNSSEC saved us from being really, thoroughly > >owned.” > > > > > > > >Or maybe ACME .. > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-acme-acme-data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264sdata=%2B6dEhg63cXX3MiBx8tWgFY6zoGmqqSxC1aE3RfOLVqc%3Dreserved=0 > >12#section-11.2 > > > >"It is therefore RECOMMENDED that ACME-based CAs make all DNS queries > >via DNSSEC-validating stub or recursive resolvers. This provides > >additional protection to domains which choose to make use of DNSSEC.” > > > >I am not sure how many of the domains listed as being hijacked are > >DNSSEC signed, but it seems if they were, and had a reasonable long > >TTL on a DS record at their parent, many if not most of these could > >have been prevented/detected. > > > >ICANN seems to think that is the case: ICANN Calls for Full DNSSEC > >Deployment > > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fnews%2Fannouncement-2019-02-22-endata=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264sdata=WoLoqR%2BPBRd1dKChGSK%2BZpvP15wAZvezmPatgElG8hY%3Dreserved=0 > > > >Of course, DNSSEC is often blamed for not protecting those who did > >not deploy/use it. Not sure what can be said about that line of > >reasoning. > > > >Dougm > >-- > >Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST > > > > > > > > > >Date: Sat, 23 Feb 2019 12:13:41 -0700 > >From: "Keith Medcalf" > >To: "nanog@nanog.org" > >Subject: RE: A Deep Dive on the Recent Widespread DNS Hijacking > > Attacks > >Message-ID: <6e31d305aee69c4d85116e6a81d0c...@mail.dessus.com> > >Content-Type: text/plain; charset="us-ascii" > > > >On Saturday, 23 February, 2019 10:03, Stephane Bortzmeyer wrote: > > > >>Very good article, very detailed, with a lot of technical > >precisions, > >>about the recent domain name hijackings (not using the DNS, just > >good > >>old hijackings at registrar or hoster). > > > > > >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkrebsonsecurity.com%2F2019%2F02%2Fa-deep-dive-on-the-recent-data=02%7C01%7Cdougm%40nist.gov%7C83bd930ed9fd46f3bf9a08d69ac3d867%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636866563276432264sdata=A0j0UwTN566qmIwxHeX5FROC6JaMDuccp3ykJSCl8%2Fk%3Dreserved=0 > >widespread-dns-hijacking-attacks/ > > > >So in other words this was just an old school script kiddie > >taking advantage of DNS registrars, the only difference being this > >was a whole whack of script kiddies acting in concert directed
Re: A Deep Dive on the Recent Widespread DNS Hijacking
> On 25 Feb 2019, at 4:34 pm, Bill Woodcock wrote: > > > >> On Feb 24, 2019, at 5:51 PM, Keith Medcalf wrote: >> >> That they also "forgot" to disable DNSSEC on PCH is not particularly >> relevant. It only goes to prove my point that DNSSEC is irrelevant and only >> gives a false sense of security (for this particular attack vector). > > For those watching from the sidelines, This guy is perfectly encapsulating > one of the arguments that seem to pop up in the wake of attacks: “What > actually happened is irrelevant, because I can imagine other things that > could hypothetically have happened, but didn’t, which would have reinforced > my view of the world.” > > I can’t say that I understand the psychology behind people thinking this way, > but as we’re choosing to be transparent about our experience for the benefit > of others, I thought I’d highlight this particular quirk, as Mr. Medcalf is > far from alone (not about DNSSEC specifically, but apparently attacks bring > people with all manner of chips on their shoulders out of the woodwork). > It’s a particularly self-defeating logical fallacy, so being aware of it is > the first step to recognizing it and avoiding it. > >-Bill I would also note that a organisation can deploy RFC 5011 for their own zones and have their own equipment use DNSKEYs managed using RFC 5011 for their own zones. This isolates the organisation’s equipment from the parent zone’s management practices. I would also note that you can configure validating resolvers to expect secure responses for parts of the namespace and to reject insecure responses even when they validate as insecure. An organisation can also deploy DLV for their own zones using their own registry. While the current code DLV validating code is only invoked when the response validates as insecure, there is nothing preventing a policy which says that DLV trumps or must also validate for entries in a registry. At this stage is would be a minor code change to add such policy knobs. DLV is a just a in-band way of distributing trust anchors. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
> On 5 Mar 2019, at 6:06 am, Saku Ytti wrote: > > Hey Jean, > >>I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" >> service >>of the concerned operator doesn't handle IPv6 yet. >> >>as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" >> (rfc 4443) >>seem to be ignored or filtered at ~60% of ClouFlare's http farms > > Might be related to this: > https://blog.cloudflare.com/path-mtu-discovery-in-practice/ > > If you run ECMP then the hash algorithms make no guarantees ICMP > messages generated by transit devices reach the correct host. Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if they have installed broken ECMP devices. The simplest way to do that is to set the interface MTUs to 1280 on all the servers. Why should the rest of the world have to put up with their inability to purchase devices that work with RFC compliant data streams. Mark > -- > ++ytti -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: WIndows Updates Fail Via IPv6 - Update!
> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: > > On 3/3/19 18:04, Mark Andrews wrote: >> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB >> getting >> back to the TCP servers. There are also IDIOTS that deploy load balancers >> that >> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct >> back end. There are also IDOITS that rate limit PTB generation to >> ridiculously >> low rates. One should be able to generate PTB at line rate. >> >> Everyone that has configured mss-fix-up has contributed to misunderstanding >> that >> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from >> all >> the boxes you control. We need to get PTB working and unfortunately that >> means >> that we need to stop pandering to admins who don’t know how IP is supposed to >> work. ICMP is NOT optional. > > It would seem IETF's intention is to actually move away from > ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). Which is not a reason to not fix broken equipment and misconfigured firewalls. The workarounds are basically there because people deploy broken equipment. Additionally everything isn’t TCP. > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
> On 6 Mar 2019, at 1:36 pm, Fernando Gont wrote: > > On 5/3/19 03:26, Mark Andrews wrote: >> >> >>> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: >>> >>> >>> >>> On 5/Mar/19 00:25, Mark Andrews wrote: >>> >>>> >>>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >>>> they have installed broken ECMP devices. The simplest way to do that >>>> is to set the interface MTUs to 1280 on all the servers. Why should >>>> the rest of the world have to put up with their inability to purchase >>>> devices that work with RFC compliant data streams. >>> >>> I've had this issue with cdnjs.cloudflare.com for the longest time at my >>> house. But as some of you may recall, my little unwanted TCP MSS hack >>> for IPv6 last weekend fixed that issue for me. >>> >>> Not ideal, and I so wish IPv6 would work as designed, but… >> >> It does work as designed except when crap middleware is added. ECMP >> should be using the flow label with IPv6. It has the advantage that >> it works for non-0-offset fragments as well as 0-offset fragments and >> also works for transports other than TCP and UDP. This isn’t a protocol >> failure. It is shitty implementations. > > Not to play devil's advocate but the IETF fot to publish a spec for ECMP > use of Flow Labels only a few years ago. > > For quite a while, they were unasable... and might still be, for some > implementations. And if it is still using the quintuple the PTB has all the necessary information for unfragmented and 0 offset fragment packets (which there shouldn’t be with a working TCP stack) to be passed through. > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: WIndows Updates Fail Via IPv6 - Update!
There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting back to the TCP servers. There are also IDIOTS that deploy load balancers that DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct back end. There are also IDOITS that rate limit PTB generation to ridiculously low rates. One should be able to generate PTB at line rate. Everyone that has configured mss-fix-up has contributed to misunderstanding that you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all the boxes you control. We need to get PTB working and unfortunately that means that we need to stop pandering to admins who don’t know how IP is supposed to work. ICMP is NOT optional. If you don’t want to do PMTUD then DO NOT SEND packet bigger than the network MTU. For IPv6 set IPV6_USE_MIN_MTU 1 on the socket. On a properly written IP stack this will result in TCP MSS negotiation to the same value. Yes, it is a requirement of TCP to pay attention to this as it becomes the effective MTU of the outgoing interface even if it wasn’t explicitly written into the RFC that defined IPV6_USE_MIN_MTU. Mark > On 4 Mar 2019, at 6:13 am, Mark Tinka wrote: > > > > On 3/Mar/19 18:05, Jeroen Massar wrote: > >> IPv6 requires a minimum MTU of 1280. >> >> If you cannot transport it, then the transport (the tunnel in this case) >> needs to handle the fragmentation of packets of 1280 down to whatever does >> fit in the tunnel. > > As you know, IPv6 does not support fragmentation in transit. So that's > not an option. > > Host fragmentation is per standard, but signaling of that was not so > successful in IPv4. Real world scenarios for IPv6 (reasonably) apply here. > > >> Have fun with all your UDP traffic that does not care about your TCP MSS >> adjustment. You just hid the problem... > > I considered this issue, but as with all things UDP re: fragmentation, > it depends. > > Testing I've been doing all day shows previously (mostly-TCP) issues > have resolved, and I've not run into any major problems that are > impacting UDP. Nonetheless, I'm keeping an eye out. > > >> >> And a correctly configured MTU is especially going to be fun with "HTTP/3" >> that is being pushed through, even though the predecessor QUIC does not care >> about MTU at all... good that it is all in the hands of a company that can >> fix it themselves ;) > > Is it an ideal situation? About as ideal as flying in the cargo bay. But > my reality is that until my FTTH provider can deliver native IPv6, this > is what I have. > > Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: WIndows Updates Fail Via IPv6 - Update!
> On 4 Mar 2019, at 9:33 am, Stephen Satchell wrote: > > On 3/3/19 1:04 PM, Mark Andrews wrote: >> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB >> getting >> back to the TCP servers. > > For those of us who are in the dark, "PTB" appears to refer to "Packet > Too Big" responses in ICMPv6. > > Yes, some admins don't have fine-enough grain tools to block or throttle > specific types of ICMP, but that's the fault of the vendors, not the admins. No, it is the fault of the admins. They should be making it part of the purchasing decision if they want to filter ICMP. It’s not like selective filtering is a new idea. It is well over 20 years old at this stage. The amount of +20 year old equipment on the net is minimal. That said modern OS’s don’t need other equipment to “protect" them from ICMP of any form. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking
> On 28 Feb 2019, at 9:03 am, John R. Levine wrote: > > On Thu, 28 Feb 2019, Mark Andrews wrote: >> Agreed. Additionally it suddenly went from something being done along >> with a experiment to being “a experiment on can you transition to a new >> type”. The transition to type99 was well underway. ... > > No, really, we had numbers. Approximately nobody was using it, and of the > few that were, they were querying just one or just the other and getting > wrong results thereby. > > In general I completely agree that new applications should have new rrtypes. > That's why I wrote my extension language, to help add new types to the > provisioning crudware that is the actual blocking factor on new types. (The > actual servers are all updated pretty quickly.) But trying to retrofit a new > type to an application that was already (albeit unwisely) using TXT was a > losing battle. Actually it was a battle that could have easily been won. People just gave up way too soon. Doing stuff like synthesising SPF records from spf style TXT records in the primary server and setting a end date for transition would have worked. We didn’t do that because we didn’t think of it as a battle. We were also blindsided by the decision to treat the change as a experiment in how to migrate types when it was never intended to be. If one was after a fast transition there was lots more that could have been done. DLV transitioned types (we started out with a user assigned type). DNS COOKIE transitioned EDNS code points (started out with a user assigned code point). It’s perfectly do able. SMTP transitioned from A to MX. We no longer publish A records just in case some MTA doesn’t support MX anymore. I can remember having to do that. SPF could have been the same except people were impatient and had unrealistic expectations of how long it would take. > Regards, > John Levine, jo...@iecc.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: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking
> On 28 Feb 2019, at 1:13 pm, John R. Levine wrote: > > FYI: > >> SMTP transitioned from A to MX. > > No, it didn't. A surprising number of real mail hosts only publish an A, and > I lost the battle to say that MX shouldn't fall back to . It does. You have missed the point. No one publishes A’s (or ’s) because they think MX is not supported by other MTAs. If one wanted to stop all fallback to A (and ) then there needed to be a RFC that said so and set a date for fallback to no longer be performed. >> SPF could have been the same except people were impatient and had >> unrealistic expectations of how long it would take. > > Perhaps it's a generational thing. I'm not very interested in transitions > that won't happen until after I'm dead. It required libraries to be written and for MTAs to use those new libraries. That had started to happen. We had name servers at the end that were synthesising SPF records from TXT records. One just had to wait for the OS refreshes to occur which would got the new MTA’s deployed. That would have mostly been done by now and I’m happy that you are not dead. Unfortunately I can’t prove that this would have been the course of events because it got aborted. > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: A Deep Dive on the Recent Widespread DNS Hijacking
> On 27 Feb 2019, at 6:46 am, Bill Woodcock wrote: > > > >> On Feb 26, 2019, at 9:15 AM, Jacques Latour wrote: >> DNSSEC should of never been part of the domain registration process, it was >> because we didn’t have the CDS/CDNSKEY channel to automated the DS >> maintenance and bootstrap. But if you keep DNSSEC maintenance outside the >> registrar control then it can be effective tool (amongst other) in >> identifying hijacks. Taking away he ability of the bad actors to disable >> DNSSEC via registrar control panel. >> This is what happens when you have all your eggs in one basket and you loose >> the keys to your kingdom. > > Agreed. There’s absolutely no reason for registrars to be involved with DS > records of zones they’re not signing. And, for the same reason, there’s no > reason for them to be involved with NS records, either, after an initial > bootstrap. > >-Bill Using https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/ with TSIG or SIG(0) would have prevented this with TFA for updating the credentials required to authenticate the updates. The method works with either TSIG or SIG(0) and you can have specific keys to update DS records or NS records and glue records. You can’t MITM TSIG or SIG(0). TSIG and SIG(0) have time limited replay windows. This is just bolting together tried and proven technology with database lookups to determine which registrar authenticates the update. Nameservers already forward UPDATE messages to the primary server for processing using TSIG and SIG(0) between the UPDATE client and the primary server. The key name is in the clear so it is easy to use that to select how to redirect the update. This also works with existing DNS servers when EPP is not thrown into the mix. It also doesn’t require DNSSEC to be deployed. Tools to do this have been shipped with nameservers since UPDATE, TSIG and SIG(0) were invented. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Security Frequently Asked Questions (FAQ)
"Generation of IPv6 fragments in response to ICMPv6 PTB messages has been deprecated in the revised IPv6 specification" IS INCORRECT generation of fragments is “discouraged". Discouraged and deprecated mean different thing. However, the use of such fragmentation is discouraged in any application that is able to adjust its packets to fit the measured path MTU (i.e., down to 1280 octets). the whole of 4.4 is very badly worded and states things as fact which don’t appear in RFC’s at all. The adding of a fragmentation header for PTB <1280 has gone. Fragmentation down to 1280 is still supposed to happen in response to a PTB. Packets still have to flow through paths that narrow down to 1280. > On 8 Mar 2019, at 5:42 pm, Fernando Gont wrote: > > Folks, > > The Internet Society has posted the "IPv6 Security Frequently Asked > Questions (FAQ)" I authored. > > The document is available (in HTML, and also easy-to-print PDF) at: > > https://www.internetsociety.org/deploy360/ipv6/security/faq/ > > If you think there are other questions that should be added, or have > comments on the answers, please do let me know -- the document can > eventually be revised. > > Thanks! > > Cheers, > -- > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: IPv6 Security Frequently Asked Questions (FAQ)
> On 8 Mar 2019, at 6:30 pm, Fernando Gont wrote: > > Hello, Mark, > > Thanks for your feedback! Please see in-line > > On 8/3/19 04:10, Mark Andrews wrote: >> "Generation of IPv6 fragments in response to ICMPv6 PTB messages has been >> deprecated in the revised IPv6 specification" >> >> IS INCORRECT >> >> generation of fragments is “discouraged". Discouraged and deprecated mean >> different thing. > > There is a writeo here. The text should have said "generation of IPv6 > atomic fragments", or, > > "Generation of IPv6 fragments in response to ICMPv6 PTB messages > advertising an MTU smaller than 1280" > > > The whole section refers to "atomic fragments" which might be generated > even for protocols that are not supposed to employ fragmentation. > > I will clarify this in the next rev. Thanks >> However, the use of such >> fragmentation is discouraged in any application that is able to >> adjust its packets to fit the measured path MTU (i.e., down to 1280 >> octets). >> >> the whole of 4.4 is very badly worded and states things as fact which don’t >> appear in RFC’s at all. > > Please let me know if, considering the writeo I referred to above, you > still feel the same. I think I’ll reserve judgement until I have seen the re-write. >> The adding of a fragmentation header for PTB <1280 has gone. Fragmentation >> down to 1280 is still supposed to happen in response to a PTB. Packets still >> have to flow through paths that narrow down to 1280. > > Agreed. > > This section is referred to this scenario: > > Say two nodes only mean to employ a TCP-based application (say two BGP > peers). Say they filter fragments directed to them, since the TCP > connections will avoid fragmentation. > > In such cases, what would seem as a "safe practice" may be not: if the > involved systems employ a legacy IPv6 implementation, then an attacker > can trigger the generation of IPv6 fragments (even for TCP conenctions) > by spoofing an ICMPv6 PTB claiming an MTU < 1280. > > This is what this section is about: If you are going to drop fragments, > make sure you also take care of ICMPv6 PTBs, since they may trigger > fragmentation even for protocols that you'd assume would never emply > fragmentation. > > Thanks! > > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
Well you can go to https://ednscomp.isc.org and click on "Test Your Servers Here” which is what https://dnsflagday.net calls behind the scenes. You will just need to interpret the results as they apply to DNS flag day. If you don’t want to go there you can go to https://gitlab.isc.org and down load and compile the DNS compliance tester and then run “genreport -i bind11 -e”. which is the actual test code being run. But hey you did do proper acceptance testing when you installed your DNS servers and firewalls to ensure that they implemented the DNS protocol correctly and they your firewalls don’t block well formed DNS queries (lots of them do by default). Mark > On 24 Jan 2019, at 3:35 pm, Christopher Morrow > wrote: > > > > On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: > Quoting from the web site at https://dnsflagday.net/ > > > huh, from the 'dns illuminati' eh" > > DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in > github's ip space, routed by fastly.com ... > I'm sure glad the whois data for that domain is sensible too... :( > > none of that particularly leaves me feeling like I should go put any data at > all into the site. > > -chris -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
I’ve been complaining for YEARS about lack of EDNS compliance. If you run really old Windows DNS servers you are broken. If you run a firewall in front of your DNS server you may be broken. If you are QWEST you are broken. Mark > On 24 Jan 2019, at 11:10 am, Brian Kantor wrote: > > Quoting from the web site at https://dnsflagday.net/ > > What is happening? > > The current DNS is unnecessarily slow and suffers from inability > to deploy new features. To remediate these problems, vendors of > DNS software and also big public DNS providers are going to > remove certain workarounds on February 1st, 2019. > > This change affects only sites which operate software which is > not following published standards. Are you affected? > > On that web page, there is a Domain Owner's test. You can enter > a domain name and click 'test' and shortly receive a report of > what was found regarding your domain's DNS servers. > > I somehow managed to miss the announcement of this upcoming event, > even though I read this mailing list fairly closely. Perhaps it > was announced somewhere else instead. I think it needs to be > mentioned here if it hasn't already been. > - Brian > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
Also as a lot of you use F5 servers here is information about DNS flag day fixes. https://support.f5.com/csp/article/K07808381?sf206085287=1 > On 24 Jan 2019, at 3:51 pm, Christopher Morrow > wrote: > > > > On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote: > Well you can go to https://ednscomp.isc.org and click on "Test Your Servers > Here” > which is what https://dnsflagday.net calls behind the scenes. You will just > need > to interpret the results as they apply to DNS flag day. If you don’t want to > go > there you can go to https://gitlab.isc.org and down load and compile the DNS > compliance tester and then run “genreport -i bind11 -e”. which is the actual > test > code being run. > > > oh excellent, I'll do this version. thanks. > > But hey you did do proper acceptance testing when you installed your DNS > servers > and firewalls to ensure that they implemented the DNS protocol correctly and > they > your firewalls don’t block well formed DNS queries (lots of them do by > default). > > > I did, yes. > > Mark > > > On 24 Jan 2019, at 3:35 pm, Christopher Morrow > > wrote: > > > > > > > > On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: > > Quoting from the web site at https://dnsflagday.net/ > > > > > > huh, from the 'dns illuminati' eh" > > > > DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in > > github's ip space, routed by fastly.com ... > > I'm sure glad the whois data for that domain is sensible too... :( > > > > none of that particularly leaves me feeling like I should go put any data > > at all into the site. > > > > -chris > > -- > 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: DNS Flag Day, Friday, Feb 1st, 2019
> On 24 Jan 2019, at 4:45 pm, Christopher Morrow > wrote: > > > > On Thu, Jan 24, 2019 at 12:35 AM Mark Andrews wrote: > And if you don’t want to go to the web site you can still see the content here > > https://github.com/dns-violations/dnsflagday > > > I think part of my snark was lost as snark here... > So, we're asking 'everyone' to do 'something' on behalf of their domains, > their users and the rest of the internet... we can't seem to do that in a > fashion that's traceable, clearly has ownership and doesn't look like every > halfbaked spam campaign in the world. > > Yes I could go digging for the right starting point at ISC or github or .. > what?? > Why wasn't this pretty clearly owned by 'ICANN' or some organization like > that? Well the IETF doesn’t want to be “Protocol Police”. ICANN has enforced this on gTLD operators as they are contractually obligated to run protocol compliant servers. Almost all of the ccTLD servers are fixed as well. https://ednscomp.isc.org/compliance/ts/tld-graphs.html https://ednscomp.isc.org/compliance/tld-report.html I’ve argued for years that TLD operators should be doing tests like this on all delegated domains and delisting them until they have fixed the server after a initial grace period with multiple warnings. They are in a position to send warning to operators and owners of delegated zones. They just say “this is not our job” despite RFC 1033 actually listing removal of delegation as something that should be done by the parent zone (TLD) if other methods of fixing servers that don’t follow the specification fail. No one wanted own this. This is Open Source DNS vendors saying "Enough is Enough”. We are tired of having to write workarounds for all the broken servers out there especially as those workarounds impacts on sites that have protocol compliant servers. None of use could move alone as we would get “But it works with …”. This needed to be a collective move. The public DNS resolver operators are also on board. No system works if there are not checks and balances in place. The DNS still doesn’t have checks and balances in place. Mark > It's lovely that github, fastly, gandi and ISC want to help, but... somewhere > here some legitimacy could have been injected into the process, right? > > "HI, we're ICANN we do dns thingies, and we'd like to help make you make > things better. Please use the website (provided by our partner(s) X, Y, Z to > do the following A, B, C things, and get guidance on repair for problems at > site FOO, BAR or BAZ. If there are questions please see our FAQ > (https://www.icann.org/dnsfixin/faq) or email . Thanks for > taking the time to make the world better?" > > it's not super hard to do this, it's also apparently super easy to look like > a spam/malware campaign. > > > On 24 Jan 2019, at 4:32 pm, Mark Andrews wrote: > > > > Also as a lot of you use F5 servers here is information about DNS flag day > > fixes. > > > > https://support.f5.com/csp/article/K07808381?sf206085287=1 > > > >> On 24 Jan 2019, at 3:51 pm, Christopher Morrow > >> wrote: > >> > >> > >> > >> On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote: > >> Well you can go to https://ednscomp.isc.org and click on "Test Your > >> Servers Here” > >> which is what https://dnsflagday.net calls behind the scenes. You will > >> just need > >> to interpret the results as they apply to DNS flag day. If you don’t want > >> to go > >> there you can go to https://gitlab.isc.org and down load and compile the > >> DNS > >> compliance tester and then run “genreport -i bind11 -e”. which is the > >> actual test > >> code being run. > >> > >> > >> oh excellent, I'll do this version. thanks. > >> > >> But hey you did do proper acceptance testing when you installed your DNS > >> servers > >> and firewalls to ensure that they implemented the DNS protocol correctly > >> and they > >> your firewalls don’t block well formed DNS queries (lots of them do by > >> default). > >> > >> > >> I did, yes. > >> > >> Mark > >> > >>> On 24 Jan 2019, at 3:35 pm, Christopher Morrow > >>> wrote: > >>> > >>> > >>> > >>> On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: > >>> Quoting from the web site at https://dnsflagday.net/ > >>> > >>> > >>> huh, from the 'dns illuminati' eh" > >>> > >>> DNS hosted by gandi.net? resolves to
Re: DNS Flag Day, Friday, Feb 1st, 2019
And if you don’t want to go to the web site you can still see the content here https://github.com/dns-violations/dnsflagday > On 24 Jan 2019, at 4:32 pm, Mark Andrews wrote: > > Also as a lot of you use F5 servers here is information about DNS flag day > fixes. > > https://support.f5.com/csp/article/K07808381?sf206085287=1 > >> On 24 Jan 2019, at 3:51 pm, Christopher Morrow >> wrote: >> >> >> >> On Wed, Jan 23, 2019 at 11:45 PM Mark Andrews wrote: >> Well you can go to https://ednscomp.isc.org and click on "Test Your Servers >> Here” >> which is what https://dnsflagday.net calls behind the scenes. You will just >> need >> to interpret the results as they apply to DNS flag day. If you don’t want >> to go >> there you can go to https://gitlab.isc.org and down load and compile the DNS >> compliance tester and then run “genreport -i bind11 -e”. which is the actual >> test >> code being run. >> >> >> oh excellent, I'll do this version. thanks. >> >> But hey you did do proper acceptance testing when you installed your DNS >> servers >> and firewalls to ensure that they implemented the DNS protocol correctly and >> they >> your firewalls don’t block well formed DNS queries (lots of them do by >> default). >> >> >> I did, yes. >> >> Mark >> >>> On 24 Jan 2019, at 3:35 pm, Christopher Morrow >>> wrote: >>> >>> >>> >>> On Wed, Jan 23, 2019 at 7:11 PM Brian Kantor wrote: >>> Quoting from the web site at https://dnsflagday.net/ >>> >>> >>> huh, from the 'dns illuminati' eh" >>> >>> DNS hosted by gandi.net? resolves to 3 /32's on 3 adjacent /24's.. in >>> github's ip space, routed by fastly.com ... >>> I'm sure glad the whois data for that domain is sensible too... :( >>> >>> none of that particularly leaves me feeling like I should go put any data >>> at all into the site. >>> >>> -chris >> >> -- >> 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 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
We see Juniper firewalls blocking EDNS(1) and NSID by default. We see Checkpoint firewalls blocking EDNS(1) and EDNS flags by default. There is a another vendor that blocks EDNS(1). Juniper and Checkpoint have newer code that doesn’t do this. The old firewalls are still out there however. You can see them easily when you are doing bulk testing and mark timeouts in a different colour. Please go look at the reports on https://ednscomp.isc.org to see how obvious they are. There were times in the last 4 years where over 50% of the tested servers were dropping EDNS(1) queries. With drop rates like that you limited the ability of the IETF to use EDNS(1) to fix issues with EDNS correctly. The RFC 6891 would have included a version bump except for these stupid firewalls. The clarification of unknown EDNS option behaviour warranted a version bump. Blocking any of the extension mechanisms (version, flag or option) isn’t doing anyone any benefit. If you have a firewall that does it please FIX IT. > On 24 Jan 2019, at 10:13 pm, Mark Andrews wrote: > > > >> On 24 Jan 2019, at 9:02 pm, Mike Meredith wrote: >> >> On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews may have >> written: >>> If you run a firewall in front of your DNS server you may be broken. >> >> If you run a firewall in front of your DNS server and the firewall breaks >> EDNS, then your firewall is broken. And has been a long, long time. I put a >> firewall in place back in 2004, and EDNS compliance was one of the tests >> back then. > > EDNS usage has changed since them. Back in 2004 there was zero use of EDNS > options in queries. That is no longer true. NSID (RFC 5001) the first option > to make it into main stream code was allocated in 2007 and that saw occasional > use. DNS COOKIE has been in every query named has emitted since BIND 9.11.0 > and > in late BIND 9.10 versions. Lots of firewalls still reject it. > >> -- >> Mike Meredith, University of Portsmouth >> Chief Systems Engineer, Hostmaster, Security, and Timelord! >> > > -- > 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: DNS Flag Day, Friday, Feb 1st, 2019
> On 24 Jan 2019, at 9:02 pm, Mike Meredith wrote: > > On Thu, 24 Jan 2019 11:22:44 +1100, Mark Andrews may have > written: >> If you run a firewall in front of your DNS server you may be broken. > > If you run a firewall in front of your DNS server and the firewall breaks > EDNS, then your firewall is broken. And has been a long, long time. I put a > firewall in place back in 2004, and EDNS compliance was one of the tests > back then. EDNS usage has changed since them. Back in 2004 there was zero use of EDNS options in queries. That is no longer true. NSID (RFC 5001) the first option to make it into main stream code was allocated in 2007 and that saw occasional use. DNS COOKIE has been in every query named has emitted since BIND 9.11.0 and in late BIND 9.10 versions. Lots of firewalls still reject it. > -- > Mike Meredith, University of Portsmouth > Chief Systems Engineer, Hostmaster, Security, and Timelord! > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
TIMEOUT is TIMEOUT. The whole point of flag day is that you can’t tell whether TIMEOUT is broken routing, packet loss or badly configured firewall. The DNS flag day site assumes the latter as does the old resolver code. We are moving to a state where resolvers assume the former. You get a report with Red or Orange. Red reports have things which need to be fixed NOW be it a routing issue or packet loss or a badly configured firewall. Mark > On 1 Feb 2019, at 4:04 am, Mark Tinka wrote: > > > > On 31/Jan/19 18:32, James Stahr wrote: > >> >> I think the advertised testing tool may be flawed as blocking TCP/53 >> is enough to receive a STOP from the dnsflagday web site. It's been >> my (possibly flawed) understanding that TCP/53 is an option for >> clients but primarily it is a mechanism for the *server* to request >> the client communicate using TCP/53 instead - this could be due to UDP >> response size, anti-spoofing controls, etc... > > On a similar note, we tested for all our self-hosted zones OK 2 weeks > ago. However, in previous days, the summary result said "NO GOOD, THINGS > WILL BE SLOW COME FLAG DAY". The detailed test showed IPv4 tested > perfect, but IPv6 probes timed out. > > The issue turned out to be an internal IPv6 routing/forwarding issue for > our service within Century Link's (Level(3)'s) network. CL finally fixed > that issue today and the flag day test tool is happy again. > > Some of our partners/customers were concerned our name servers were not > ready, based purely on the summary result of the test tool. Perhaps > adding some intelligence about whether the issue is the name server or > the transport may be helpful. > > Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
> On 1 Feb 2019, at 3:32 am, James Stahr wrote: > > On 2019-01-31 08:15, Mark Andrews wrote: > >> We actually have a hard time finding zones where all the servers are >> broken enough to not work with servers that don’t fallback to plain >> DNS on timeout. We can find zones where some of the servers are like >> that, but there is usually one or more servers that do respond >> correctly. >> Of the datasets I’ve looked at that 1 in 10,000 to 1 in 100,000 zones >> will have problems with updated servers. > > I think the advertised testing tool may be flawed as blocking TCP/53 is > enough to receive a STOP from the dnsflagday web site. It's been my > (possibly flawed) understanding that TCP/53 is an option for clients but > primarily it is a mechanism for the *server* to request the client > communicate using TCP/53 instead - this could be due to UDP response size, > anti-spoofing controls, etc… DNS is defined to be both TCP and UDP. Blocking TCP has no real security benefit and comes from the MYTH that TCP is ONLY used for zone transfers. Way too many times people have blocked TCP then have those same servers return TC=1 which say USE TCP as the answer is TOO LARGE TO FIT IN UDP. Foot, Gun, Shoot. If you have a DNSSEC zone then TCP is effectively MANDATORY as clients still need to be able to get answers from behind a firewall that is enforcing a 512 byte limit. If you are running a recursive server TCP is effectively MANDATORY as you have no control over the RRset size. Lots of referrals REQUIRE TCP as the GLUE records are not OPTIONAL in a referral. Yes, BIND has been setting TC=1 on referrals for MANY years now when it is required, it should be setting it on many more. So if you want WORKING DNS you do not block TCP. Other DNS vendors also set TC=1 on some referrals. This means if you are hosting third party content then TCP is effectively MANDATORY as you have no content control. RFC 1123 said that DNS/TCP is a SHOULD where SHOULD is defined as *"SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. I’ve yet to see anyone who has TCP blocked actually know all the places in the DNS protocol where doing so will cause things to break. None of them have done the necessary homework to actually exercise the SHOULD. There are lots of lemmings when it comes to DNS practices. All implementations of DNS are REQUIRED to support DNS/TCP. The DNS flag day site flags servers without TCP as broken which they *are*. Whether it should be red or orange is a matter for debate. A referral that in bigger than 512 bytes without involving DNSSEC. [beetle:~/git/bind9] marka% dig example.net @a.root-servers.net ; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> example.net @a.root-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54567 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;example.net. IN A ;; AUTHORITY SECTION: net.172800 IN NS a.gtld-servers.net. net.172800 IN NS b.gtld-servers.net. net.172800 IN NS c.gtld-servers.net. net.172800 IN NS d.gtld-servers.net. net.172800 IN NS e.gtld-servers.net. net.172800 IN NS f.gtld-servers.net. net.172800 IN NS g.gtld-servers.net. net.172800 IN NS h.gtld-servers.net. net.172800 IN NS i.gtld-servers.net. net.172800 IN NS j.gtld-servers.net. net.172800 IN NS k.gtld-servers.net. net.172800 IN NS l.gtld-servers.net. net.172800 IN NS m.gtld-servers.net. ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 b.gtld-servers.net. 172800 IN A 192.33.14.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 i.gtld-servers.net.
Google you have a problem.
[beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi looking up www.google.com connecting to www.google.com:443 SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 Certificate subject: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com Certificate issuer: /C=US/O=Google Trust Services/CN=Google Internet Authority G3 requesting https://www.google.com/jsapi fetch: https://www.google.com/jsapi: Bad Gateway [beetle:~/git/bind9] marka% curl -v https://www.google.com/jsapi * Trying 2607:f8b0:4007:80e::2004... * TCP_NODELAY set * Trying 172.217.14.100... * TCP_NODELAY set * Connected to www.google.com (2607:f8b0:4007:80e::2004) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com * start date: Jan 15 13:15:00 2019 GMT * expire date: Apr 9 13:15:00 2019 GMT * subjectAltName: host "www.google.com" matched cert's "www.google.com" * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 * SSL certificate verify ok. > GET /jsapi HTTP/1.1 > Host: www.google.com > User-Agent: curl/7.63.0 > Accept: */* > < HTTP/1.1 502 Bad Gateway < Content-Length: 0 < Date: Thu, 31 Jan 2019 22:20:34 GMT < Content-Type: text/html; charset=UTF-8 < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" < * Connection #0 to host www.google.com left intact [beetle:~/git/bind9] marka% curl -4 -v https://www.google.com/jsapi * Trying 172.217.14.100... * TCP_NODELAY set * Connected to www.google.com (172.217.14.100) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com * start date: Jan 15 13:15:00 2019 GMT * expire date: Apr 9 13:15:00 2019 GMT * subjectAltName: host "www.google.com" matched cert's "www.google.com" * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 * SSL certificate verify ok. > GET /jsapi HTTP/1.1 > Host: www.google.com > User-Agent: curl/7.63.0 > Accept: */* > < HTTP/1.1 502 Bad Gateway < Content-Length: 0 < Date: Thu, 31 Jan 2019 22:24:43 GMT < Content-Type: text/html; charset=UTF-8 < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" < * Connection #0 to host www.google.com left intact [beetle:~/git/bind9] marka% traceroute 172.217.14.100 traceroute to 172.217.14.100 (172.217.14.100), 64 hops max, 52 byte packets 1 172.30.42.65 (172.30.42.65) 1.340 ms 3.278 ms 1.673 ms 2 * * * 3 * * * 4 59.154.18.232 (59.154.18.232) 13.710 ms hu0-5-0-0.22btpr01.optus.net.au (59.154.18.234) 24.311 ms 13.662 ms 5 72.14.219.128 (72.14.219.128) 12.445 ms 43.781 ms 10.760 ms 6 108.170.247.74 (108.170.247.74) 12.743 ms 12.797 ms 108.170.247.59 (108.170.247.59) 14.167 ms 7 216.239.50.172 (216.239.50.172) 159.864 ms 162.324 ms 157.546 ms 8 108.170.230.130 (108.170.230.130) 147.234 ms 151.094 ms 152.088 ms 9 108.170.247.129 (108.170.247.129) 152.073 ms 149.194 ms 149.055 ms 10 108.170.230.137 (108.170.230.137) 149.697 ms 150.042 ms 74.125.252.75 (74.125.252
Re: Google you have a problem.
George Michaelson forwarded me Google’s notice which said there would be a temporary outage along with a new home. Time to update the code to use the new home. > On 1 Feb 2019, at 11:31 am, Christopher Morrow > wrote: > > just in case.. .this appears to be working now. > -chris > > On Thu, Jan 31, 2019 at 2:30 PM Mark Andrews wrote: > [beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi > looking up www.google.com > connecting to www.google.com:443 > SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 > Certificate subject: /C=US/ST=California/L=Mountain View/O=Google > LLC/CN=www.google.com > Certificate issuer: /C=US/O=Google Trust Services/CN=Google Internet > Authority G3 > requesting https://www.google.com/jsapi > fetch: https://www.google.com/jsapi: Bad Gateway > [beetle:~/git/bind9] marka% curl -v https://www.google.com/jsapi > * Trying 2607:f8b0:4007:80e::2004... > * TCP_NODELAY set > * Trying 172.217.14.100... > * TCP_NODELAY set > * Connected to www.google.com (2607:f8b0:4007:80e::2004) port 443 (#0) > * ALPN, offering http/1.1 > * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > * successfully set certificate verify locations: > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > CApath: none > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > * TLSv1.2 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > * TLSv1.2 (IN), TLS handshake, Server finished (14): > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (OUT), TLS handshake, Finished (20): > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (IN), TLS handshake, Finished (20): > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > * ALPN, server accepted to use http/1.1 > * Server certificate: > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; > CN=www.google.com > * start date: Jan 15 13:15:00 2019 GMT > * expire date: Apr 9 13:15:00 2019 GMT > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > * SSL certificate verify ok. > > GET /jsapi HTTP/1.1 > > Host: www.google.com > > User-Agent: curl/7.63.0 > > Accept: */* > > > < HTTP/1.1 502 Bad Gateway > < Content-Length: 0 > < Date: Thu, 31 Jan 2019 22:20:34 GMT > < Content-Type: text/html; charset=UTF-8 > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > < > * Connection #0 to host www.google.com left intact > [beetle:~/git/bind9] marka% curl -4 -v https://www.google.com/jsapi > * Trying 172.217.14.100... > * TCP_NODELAY set > * Connected to www.google.com (172.217.14.100) port 443 (#0) > * ALPN, offering http/1.1 > * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > * successfully set certificate verify locations: > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > CApath: none > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > * TLSv1.2 (IN), TLS handshake, Server hello (2): > * TLSv1.2 (IN), TLS handshake, Certificate (11): > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > * TLSv1.2 (IN), TLS handshake, Server finished (14): > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (OUT), TLS handshake, Finished (20): > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > * TLSv1.2 (IN), TLS handshake, Finished (20): > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > * ALPN, server accepted to use http/1.1 > * Server certificate: > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; > CN=www.google.com > * start date: Jan 15 13:15:00 2019 GMT > * expire date: Apr 9 13:15:00 2019 GMT > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > * SSL certificate verify ok. > > GET /jsapi HTTP/1.1 > > Host: www.google.com > > User-Agent: curl/7.63.0 > > Accept: */* > > > < HTTP/1.1 502 Bad Gateway > < Content-Length: 0 > < Date: Thu, 31 Jan 2019 22:24:43 GMT > < Content-Type: text/html; charset=UTF-8 > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > < > * Connection #
Re: Google you have a problem.
It was 9:29 AM Feb 1 AEST when I reported this so yes it was FRIDAY. > On 1 Feb 2019, at 3:15 pm, Christopher Morrow wrote: > > > > On Thu, Jan 31, 2019 at 4:34 PM Mark Andrews wrote: > George Michaelson forwarded me Google’s notice which said there would be a > temporary outage along with a new home. Time to update the code to use the > new home. > > > oh hey neato! :) > Also, hey! this change didn't happen on a friday! w00t! > > > On 1 Feb 2019, at 11:31 am, Christopher Morrow > > wrote: > > > > just in case.. .this appears to be working now. > > -chris > > > > On Thu, Jan 31, 2019 at 2:30 PM Mark Andrews wrote: > > [beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi > > looking up www.google.com > > connecting to www.google.com:443 > > SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 > > Certificate subject: /C=US/ST=California/L=Mountain View/O=Google > > LLC/CN=www.google.com > > Certificate issuer: /C=US/O=Google Trust Services/CN=Google Internet > > Authority G3 > > requesting https://www.google.com/jsapi > > fetch: https://www.google.com/jsapi: Bad Gateway > > [beetle:~/git/bind9] marka% curl -v https://www.google.com/jsapi > > * Trying 2607:f8b0:4007:80e::2004... > > * TCP_NODELAY set > > * Trying 172.217.14.100... > > * TCP_NODELAY set > > * Connected to www.google.com (2607:f8b0:4007:80e::2004) port 443 (#0) > > * ALPN, offering http/1.1 > > * Cipher selection: > > ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > > * successfully set certificate verify locations: > > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > > CApath: none > > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > > * TLSv1.2 (IN), TLS handshake, Server hello (2): > > * TLSv1.2 (IN), TLS handshake, Certificate (11): > > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > > * TLSv1.2 (IN), TLS handshake, Server finished (14): > > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (OUT), TLS handshake, Finished (20): > > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (IN), TLS handshake, Finished (20): > > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > > * ALPN, server accepted to use http/1.1 > > * Server certificate: > > * subject: C=US; ST=California; L=Mountain View; O=Google LLC; > > CN=www.google.com > > * start date: Jan 15 13:15:00 2019 GMT > > * expire date: Apr 9 13:15:00 2019 GMT > > * subjectAltName: host "www.google.com" matched cert's "www.google.com" > > * issuer: C=US; O=Google Trust Services; CN=Google Internet Authority G3 > > * SSL certificate verify ok. > > > GET /jsapi HTTP/1.1 > > > Host: www.google.com > > > User-Agent: curl/7.63.0 > > > Accept: */* > > > > > < HTTP/1.1 502 Bad Gateway > > < Content-Length: 0 > > < Date: Thu, 31 Jan 2019 22:20:34 GMT > > < Content-Type: text/html; charset=UTF-8 > > < Alt-Svc: quic=":443"; ma=2592000; v="44,43,39" > > < > > * Connection #0 to host www.google.com left intact > > [beetle:~/git/bind9] marka% curl -4 -v https://www.google.com/jsapi > > * Trying 172.217.14.100... > > * TCP_NODELAY set > > * Connected to www.google.com (172.217.14.100) port 443 (#0) > > * ALPN, offering http/1.1 > > * Cipher selection: > > ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH > > * successfully set certificate verify locations: > > * CAfile: /opt/local/share/curl/curl-ca-bundle.crt > > CApath: none > > * TLSv1.2 (OUT), TLS header, Certificate Status (22): > > * TLSv1.2 (OUT), TLS handshake, Client hello (1): > > * TLSv1.2 (IN), TLS handshake, Server hello (2): > > * TLSv1.2 (IN), TLS handshake, Certificate (11): > > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > > * TLSv1.2 (IN), TLS handshake, Server finished (14): > > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (OUT), TLS handshake, Finished (20): > > * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): > > * TLSv1.2 (IN), TLS handshake, Finished (20): > > * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256 > > * ALPN, server accepted to use http/1.1 > > * Server certificate: > > * subject: C=US; ST=C
Re: DNS Flag Day, Friday, Feb 1st, 2019
Google has started their rollout. https://groups.google.com/forum/#!msg/public-dns-announce/-qaRKDV9InA/tExCFrppAgAJ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
> On 3 Feb 2019, at 2:01 am, Stephen Satchell wrote: > > On 2/1/19 1:23 PM, Mark Andrews wrote: >> Google has started their rollout. > > So has Red Hat (RHEL and Centos). I woke up to a rather large update > this morning. RedHat or third party RPM’s you have chosen to run on RedHat? RedHat is notorious for not updating packages they include in the base system and to the best of my knowledge they haven’t dug these changes out of BIND 9.13 (which is a development series) and back ported them. BIND 9.14 is yet to be released. Now PowerDNS have released their new recursive server and if you happen to have installed that on RedHat it may have been what you saw. https://blog.powerdns.com/2019/02/01/changes-in-the-powerdns-recursor-4-2-0/ Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
-- Mark Andrews > On 31 Jan 2019, at 20:25, Radu-Adrian Feurdean > wrote: > > > >> On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: >> You do realise that when the day was chosen it was just the date after >> which new versions of name servers by the original group of Open Source >> DNS developers would not have the work arounds incorporated? > > I think it's pretty safe to say that the "DNS Flag day" is more like a date > of "end of support" rather than an "service termination". My guess is that > some uncompliant servers will be still running long after that date... > > -- > R-A.F.
Re: DNS Flag Day, Friday, Feb 1st, 2019
The only ones that could potentially make a “breaking change” on the Feb 1 are Google, Cloudflare and Quad9. They are the public DNS recursive server operators that have committed to removing work arounds. Google has already stated publicly that it will be introducing changes gradually and I expect the other to also do so. Name server developers DO NOT have that power. Google, Cloudflare and Quad9 are needed so the collectively we don’t need to deal with “but it works with …”. That also the reason for the rest of the vendors doing it in unison. What is needed next is for infrastructure zone operators to down load the compliance tools and run them on the servers listed in their zones daily and then inform the owners of those delegations that their zones are on non-compliant servers and give them a dead line to fix them (120 days should be enough time). If the servers aren’t fixed by the dead line the delegation is removed until the servers are fixed or replaced with compliant ones. This will catch operators who install out-of-compliance servers and firewalls. The reaction so far by DNS server operators to DNS flag day shows that this is not actually unreasonable to require. The fixed code is out there for both name servers and firewalls. Mark > On 31 Jan 2019, at 2:49 pm, Christopher Morrow > wrote: > > > > On Wed, Jan 30, 2019 at 6:23 PM Mark Andrews wrote: > You do realise that when the day was chosen it was just the date after which > new versions of name servers by the original group of Open Source DNS > > you do realize you are proposing to make a breaking change (breaking change > to a global system) on a friday. > delaying until the following monday would not have mattered to you, I'm sure > it's going to matter to other folks though. > > thanks, > -chris > > developers would not have the work arounds incorporated? > > For ISC that will be BIND 9.14.0 and no that will not be available Feb 1 but > you can use the development version 9.13 which has had the code for a while > now. > > Individual operators of resolvers will make their own decisions about when to > deploy. > -- > Mark Andrews > > On 31 Jan 2019, at 12:55, Christopher Morrow wrote: > >> >> >> On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG >> wrote: >> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: >> > Any chance this could wait until say the Tuesday >> > *after* the Superbowl, when we aren't cutting an >> > entire religion's worth of potential workers out of >> > the workforce available to fix issues in case it >> > turns out to be a bigger problem than is expected, >> > and when we have less chance of annoying the >> > vast army of football-loving fans of every sort? >> >> IIRC, DNS Flag Day was announce way before last years Super Bowl... >> what did the people who aren't ready for DNS Flag Day do in the past >> 364 days that they need a few more days to get ready for? >> >> >> Oh, so they had 365 days to plan the time of the event and still picked a >> friday for that event? >> >> https://www.opsview.com/resources/system-administrator/blog/three-reasons-why-not-make-major-it-changes-fridays >> >> I see. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
Don’t forget the reverse tree as well. > On 31 Jan 2019, at 5:40 pm, Hank Nussbacher wrote: > > On 31/01/2019 07:18, Mark Andrews wrote: > > There is some secret, silent block on my postings to NANOG that the admins > have not yet discovered. In the interim can one of you please proxy to the > list that people should not forget about testing their inverse as well - > *.in-addr.arpa via https://ednscomp.isc.org/ednscomp > > Regards, > Hank -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: DNS Flag Day, Friday, Feb 1st, 2019
This basically affects sites using really old Windows DNS servers (Microsoft decided to make them only respond once with FORMERR so if that message is lost they appear to be dead until the timer clears) and those using firewalls that block EDNS queries. If you use such firewalls they are really doing nothing useful. Most of the other errors reported are benign as far as DNS flag day is concerned. Also apart from the public DNS resolvers people need to install updated software that has the work arounds removed. Mark -- Mark Andrews > On 31 Jan 2019, at 12:22, Matthew Petach wrote: > > > >> On Wed, Jan 23, 2019 at 4:12 PM Brian Kantor wrote: >> Quoting from the web site at https://dnsflagday.net/ > [...] >> The current DNS is unnecessarily slow and suffers from inability >> to deploy new features. To remediate these problems, vendors of >> DNS software and also big public DNS providers are going to >> remove certain workarounds on February 1st, 2019. > > > I would like to note that there is an entire > segment of the population that does not > interact with technology between sundown > on Friday, all the way through Sunday > morning. > > Choosing Friday as a day to carry out an > operational change of this sort does not > seem to have given thought that if things > break, there is a possibility they will have > to stay broken for at least a full day before > the right people can be engaged to work on > the issue. > > In the future, can we try to schedule such events > with more consideration on which day the change > will take place? > > I will also note that this weekend is the Superbowl > in the US; one of the bigger advertising events of the > year. Potentially breaking advertising systems that > rely on DNS two days before a major, once-a-year > advertising event is *also* somewhat inconsiderate. > > While I understand that no day will work for everyone, > and at some point you just have to pick a day and go > for it, I will note that picking the Friday before the > Superbowl does seem like a very unfortunate random > pick for a day on which to do it. > > Any chance this could wait until say the Tuesday > *after* the Superbowl, when we aren't cutting an > entire religion's worth of potential workers out of > the workforce available to fix issues in case it > turns out to be a bigger problem than is expected, > and when we have less chance of annoying the > vast army of football-loving fans of every sort? > > Thanks! > > Matt >
Re: DNS Flag Day, Friday, Feb 1st, 2019
You do realise that when the day was chosen it was just the date after which new versions of name servers by the original group of Open Source DNS developers would not have the work arounds incorporated? For ISC that will be BIND 9.14.0 and no that will not be available Feb 1 but you can use the development version 9.13 which has had the code for a while now. Individual operators of resolvers will make their own decisions about when to deploy. -- Mark Andrews > On 31 Jan 2019, at 12:55, Christopher Morrow wrote: > > > >> On Wed, Jan 30, 2019 at 5:41 PM Jim Popovitch via NANOG >> wrote: >> On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: >> > Any chance this could wait until say the Tuesday >> > *after* the Superbowl, when we aren't cutting an >> > entire religion's worth of potential workers out of >> > the workforce available to fix issues in case it >> > turns out to be a bigger problem than is expected, >> > and when we have less chance of annoying the >> > vast army of football-loving fans of every sort? >> >> IIRC, DNS Flag Day was announce way before last years Super Bowl... >> what did the people who aren't ready for DNS Flag Day do in the past >> 364 days that they need a few more days to get ready for? >> > > Oh, so they had 365 days to plan the time of the event and still picked a > friday for that event? > > https://www.opsview.com/resources/system-administrator/blog/three-reasons-why-not-make-major-it-changes-fridays > > I see.
Re: DNS Flag Day, Friday, Feb 1st, 2019
> On 1 Feb 2019, at 1:21 am, Stephen Satchell wrote: > > After reading through the thread, this reminds me of the Y2K flap, that > turned into a non-event. My checks of authoritative DNS servers for my > domains show no issues now. As did I, but if we didn’t try and give lots of notice people would have complained. That said a lot of servers have been fixed that where not fully compliant and firewalls that unnecessarily blocked well formed EDNS packets with one or more of the extension mechanism present have been turned off. The authoritative DNS server space is much cleaner now and we the data to show it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
