Re: SA Internet security issues
Daniel Schroder <[email protected]> Wed, 5 Jul 2017 22:19:08 +0200
| Newsgroups | gmane.org.operators.ioz |
|---|---|
| Message-ID | <CAMvWrAu4KeAzJirMSwe8dy9EUr7MMQxnMHMB243CL0aj-Z1wAA@mail.gmail.com> |
--===============1069737527== Content-Type: multipart/alternative; boundary="94eb2c1b50c6c77b3b055397b85b" --94eb2c1b50c6c77b3b055397b85b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You very talkative :) The routing I was refering to is both isnet and tenet, as published via London ix, if both of them have routing issues, then it's likely they route to each other in a way that would explain your routes. As I aslo mentioned, all local routes are fine, other than the two of them, as I also mentioned, it's not up to clients to have to figure this out, the routing is via he.ne= t, and as I mentioned, they don't often make mistakes. (Can't, running the largest ipv6 address space). I am really not interested in helping ISPs sorting out routing issues, it's a hard and crap job for the admins involved and they need clear concise and logical assistance in resolving such issues and having to read through ppls email exchanges is the quickest way to have it not resolved. (I used to just loose interest and have a beer). I've administered for for a long time, and since bind has been rewritten and called unbound, and "legacy" tools rewritten (dig becomes drill), I'll go with what admins in that regards prefer, chained simply means replying with a request from a list of relevant root servers, seems to me logical, and .... it works. Your reply to dnsec replies, as I mentioned, if you know there is a problem, replies not being in sync, then it's (for me) a simple procedure to track (via chains) where the source of insertions are, I just assumed I would not need to go into detail how to do this. I've just sat a while looking through all the looking glasses, and this routing issue is fairly obvious, and it's between he.net and jinx to sort out. In reference, I'm just unwisely replying to (to be frank needs more work) your intercourse, in recourse however I'm returning it in dire hope of no return, hoping you take everything I say and retype twice with some sodium chloride :) Daniel On Wed, Jul 5, 2017 at 7:59 PM, Nishal Goburdhan <[email protected]= > wrote: > > > On 05 Jul 2017, at 13:20, Daniel Schroder <[email protected]> > wrote: > > > > Really don't want to reply to this :/ > > well, you made an assertion about broken routing. that=E2=80=99s bound t= o pick up > interest =E2=80=A6 :-) > > > > Point: You can't have a root dns server routed locally on Ipv4, route= d > > internationally on Ipv6, with no easy way of checking if they are the > > same machine, one with aroundA Ipv4 - 40ms (max) other ipv6 - 170 ms > > (round trip internationally). > > to be clear, from the data you posted below, your results shows the > difference that you describe above, to a single host - disa.tenet.ac.za. > my dig output from two disparate networks does *not* show this. > it is reasonable to infer that there=E2=80=99s a (IPv4 vs IPv6) routing a= nomaly > between your network, and the network that hosts disa.tenet.ac.za > > i=E2=80=99m curious; have you reported this to either network, and are y= ou in a > position to share their response(s)? > > > > Point: dnsec enables you to _detect_ spoofing, then you just need to > > find the source. If a query (drill -TD) returns a different address > > than a non dnsec query, you know you have a problem. > > conceded. however, it does not, however, help you track where the > =E2=80=9Cdifferent=E2=80=9D, or =E2=80=9Cwrong=E2=80=9D address would hav= e been inserted, which is how i > read your initial response of "DNSEC helps finding sources=E2=80=9D. > > > > Point: Isps have been known to redirect dns requests, if you want > > citations, google "dns hijacking=E2=80=9D > > um, yes thanks. i=E2=80=99m quite familiar with this. > however, i don=E2=80=99t see the context when i read the entire sentence = in your > original message: > =E2=80=9C.. DNSEC helps finding sources of DNS spoofing, which is often u= sed by > high tier ISPs to redirect traffic, or on compromised hardware.=E2=80=9D= =E2=80=9D > > > > > Point: Tenet do not route via jinx for ipv6, on the same address give= n > > over dns for [1]disa.tenet.ac.za, > > hrm. i can see bgp data that says otherwise. from a public resource: > https://lg.inx.net.za/klg/index.php?server=3DJINX-RC& > action=3Dshow+bgp+ipv6&args=3D2001%3A4200%3Affff%3Aa%3A%3A1 > > and for good measure: > nishal@jnb:~$ mtr disa.tenet.ac.za --report > Start: Wed Jul 5 19:23:09 2017 > HOST: jnb Loss% Snt Last Avg Best Wrst > StDev > 1.|-- vl52-gw.inx.net.za 0.0% 10 0.5 0.5 0.4 0.6 > 0.0 > 2.|-- 2c0f:fc00:5000:35::1 80.0% 10 2.5 1.9 1.3 2.5 > 0.0 > 3.|-- pr1-rba-te2-2-0.ipv6.isne 0.0% 10 0.5 0.9 0.5 2.1 > 0.3 > 4.|-- tenet.jinx.net.za 0.0% 10 1.1 1.1 1.1 1.1 > 0.0 > 5.|-- ae0-isd1-pe1.tenet.ac.za 0.0% 10 1.1 1.1 1.0 1.4 > 0.0 > 6.|-- 2001:4200::155:232:1:35 0.0% 10 16.8 16.8 16.7 16.9 > 0.0 > 7.|-- 2001:4200::155:232:64:64 0.0% 10 16.9 16.9 16.8 16.9 > 0.0 > 8.|-- 2001:4200::155:232:64:59 0.0% 10 17.7 17.7 17.5 17.8 > 0.0 > 9.|-- 2001:4200:ffff:a::1 0.0% 10 17.2 17.1 17.0 17.2 > 0.0 > nishal@jnb:~$ > > but, as we established above, your network might be not adequately peered > with tenet. > i=E2=80=99m pretty certain that this can be easily fixed, which is why i = was > curious about the networks' respective responses above. > > > > HOWEVER it > > could also be a simple routing issue, out via international, in > > locally, but it's not easy to check all this, and that is a problem. > > Should have been picked up and understood and sorted out. > > you=E2=80=99re right! > the Internet Police should have picked the routing problem between these > two networks much earlier!! :-) > (hi bje!) > > in my experience, routing anomalies are generally fixed only when they=E2= =80=99re > *noticed* to be an actual anomaly. and generally, that means that this i= s > noticed, or reported by someone that spotted the problem. > which goes back to: did you report this, and did you get a response? > > there is no self-correcting, self-healing Internet, no matter what the > sticker on the box said... > > > > Point: All Ipv6 routed root dns servers go via jinx just fine, except > > for tenet, this could be a simple BGP announcement issue, easy to > > solve, but does not answer the 175 ms response if [3]disa.tenet.ac.za= A > > is routed internationally. (See above point) > > i think we=E2=80=99ve safely established that there=E2=80=99s a problem h= ere. routing is > a bi-directional process though. > out of curiousity, what=E2=80=99s your source ASN, btw? > > > > Point: If I know how to hijack, spoof and otherwise cause DNS problem= s > > (I fix them), then there are many other who do, WHY is a dnsec sighne= d > > DNS reply an issue, just to be sure of responses. Even if a root anch= or > > is established, it can be used, it can be changed, unless there are > > control issues. > > Point: running a dns server that runs queries chained, is a lot quick= er > > and secure than trusting your ISPs supplied cache servers. This also > > allows a lot more efficient and quicker CDN source reply, as well as > > making it more difficult to reroute queries. > > i=E2=80=99m guessing by "chained=E2=80=9D you mean some sort of heirachia= l dns resolver > service? > being able to use a larger, cache that you trust, certainly helps, so > nothing wrong with that. > i think the argument about efficiency and quicker CDN replies are > difficult to qualify, since many operators (not just CDNs) rely on really > small TTLs which may negate heirachial caching. > > none of that is related in any way to DNSSEC though. > > > > Point: Most server operating systems that are new try ipv6 first unle= ss > > specified, and I know desktop machines always try ipv6 first > > unconfigured, so I'm hoping you understand the potential problems her= e. > > actually, that=E2=80=99s not necessarily true. use your favourite search= engine, > and lookup =E2=80=9Chappy eyeballs=E2=80=9D. > then, lookup some of the problems that =E2=80=9Chappy eyeballs=E2=80=9D c= reated; not the > least of which is making it more difficult to spot problems like the one > above. > > > > Don't get me wrong, but I really do like to get to the root of > > problems, and don't enjoy debates that waste everyones time, but I do > > read everything, including the fine print and things need to add up, > > otherwise everything based on the those basics suffers. > > your inital statement was " Also I have a feeling Ipv6 is also going to > become a problem=E2=80=9D. > i don=E2=80=99t agree. at least, i don=E2=80=99t see IPv6 as a bigger pr= oblem than IPv4. > and, i=E2=80=99ve shown you that, at least from two different networks, t= here isn=E2=80=99t > a problem. > > does that mean that all networks have congruent peering policies? no, o= f > course not. > but that=E2=80=99s *not* an issue that=E2=80=99s caused by IPv6, more tha= n networks having > a consistent network peering policy. > if you=E2=80=99re interested in data that supports my assertion that this= is not > limited to IPv6, particularly relating to DNS response times, RIPE ATLAS > has lots of great data from ZA networks, particularly on performance to t= he > different DNS Roots. (for reference, F,I,E,L,D,J,K, *should* all be loca= l > to a well connected domestic network). > tl;dr - it=E2=80=99s easy to spot, that the routing inconsistencies that = you hint > at for IPv6, exist for IPv4 too. > > =E2=80=94n. > > ps. oh, and if nothing else, if your_src_as reports that they have a > peering issue to tenet, and gets that fixed, then *some* good has come ou= t > of this > > _______________________________________________ > IOZ mailing list > [email protected] > http://lists.internet.org.za/mailman/listinfo/ioz > --94eb2c1b50c6c77b3b055397b85b MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" You very talkative :) The routing I was refering to is both isnet and tenet, as published via London ix, if both of them have routing issues, then it's likely they route to each other in a way that would explain your routes. As I aslo mentioned, all local routes are fine, other than the two of them, as I also mentioned, it's not up to clients to have to figure this out, the routing is via [1]he.net, and as I mentioned, they don't often make mistakes. (Can't, running the largest ipv6 address space). I am really not interested in helping ISPs sorting out routing issues, it's a hard and crap job for the admins involved and they need clear concise and logical assistance in resolving such issues and having to read through ppls email exchanges is the quickest way to have it not resolved. (I used to just loose interest and have a beer). I've administered for for a long time, and since bind has been rewritten and called unbound, and "legacy" tools rewritten (dig becomes drill), I'll go with what admins in that regards prefer, chained simply means replying with a request from a list of relevant root servers, seems to me logical, and .... it works. Your reply to dnsec replies, as I mentioned, if you know there is a problem, replies not being in sync, then it's (for me) a simple procedure to track (via chains) where the source of insertions are, I just assumed I would not need to go into detail how to do this. I've just sat a while looking through all the looking glasses, and this routing issue is fairly obvious, and it's between [2]he.net and jinx to sort out. In reference, I'm just unwisely replying to (to be frank needs more work) your intercourse, in recourse however I'm returning it in dire hope of no return, hoping you take everything I say and retype twice with some sodium chloride :) Daniel On Wed, Jul 5, 2017 at 7:59 PM, Nishal Goburdhan <[3][email protected]> wrote: > On 05 Jul 2017, at 13:20, Daniel Schroder <[4][email protected]> wrote: > >A A Really don't want to reply to this :/ well, you made an assertion about broken routing.A thatas bound to pick up interest a|A :-) >A A Point: You can't have a root dns server routed locally on Ipv4, routed >A A internationally on Ipv6, with no easy way of checking if they are the >A A same machine, one with aroundAA Ipv4 - 40ms (max) other ipv6 - 170 ms >A A (round trip internationally). to be clear, from the data you posted below, your results shows the difference that you describe above, to a single host - [5]disa.tenet.ac.za. my dig output from two disparate networks doesA *not* show this. it is reasonable to infer that thereas a (IPv4 vs IPv6) routing anomaly between your network, and the network that hosts [6]disa.tenet.ac.za iam curious;A have you reported this to either network, and are you in a position to share their response(s)? >A A Point: dnsec enables you to _detect_ spoofing, then you just need to >A A find the source. If a query (drill -TD) returns a different address >A A than a non dnsec query, you know you have a problem. conceded.A however, it does not, however, help you track where the adifferenta, or awronga address would have been inserted, which is how i read your initial response of "DNSEC helps finding sourcesa. >A A Point: Isps have been known to redirect dns requests, if you want >A A citations, google "dns hijackinga um, yes thanks.A iam quite familiar with this. however, i donat see the context when i read the entire sentence in your original message: a.. DNSEC helps finding sources of DNS spoofing, which is often used by high tier ISPs to redirect traffic, or on compromised hardware.aa >A A Point: Tenet do not route via jinx for ipv6, on the same address given >A A over dns for [1][7]disa.tenet.ac.za, hrm.A iA can see bgp data that says otherwise.A from a public resource: [8]https://lg.inx.net.za/klg/index.php?server=JINX-RC& action=show+bgp+ipv6&args=2001%3A4200%3Affff%3Aa%3A%3A1 and for good measure: nishal@jnb:~$ mtr [9]disa.tenet.ac.za --report Start: Wed JulA 5 19:23:09 2017 HOST: jnbA A A A A A A A A A A A A Loss%A A SntA A LastA A AvgA BestA Wrst StDev A 1.|-- [10]vl52-gw.inx.net.zaA A A A A 0.0%A A 10A A 0.5A A 0.5A A 0.4A A 0.6A A 0.0 A 2.|-- 2c0f:fc00:5000:35::1A A A 80.0%A A 10A A 2.5A A 1.9A A 1.3A A 2.5A A 0.0 A 3.|-- pr1-rba-te2-2-0.ipv6.isneA 0.0%A A 10A A 0.5A A 0.9A A 0.5A A 2.1A A 0.3 A 4.|-- [11]tenet.jinx.net.zaA A A A A 0.0%A A 10A A 1.1A A 1.1A A 1.1A A 1.1A A 0.0 A 5.|-- [12]ae0-isd1-pe1.tenet.ac.zaA A 0.0%A A 10A A 1.1A A 1.1A A 1.0A A 1.4A A 0.0 A 6.|-- 2001:4200::155:232:1:35A A 0.0%A A 10A A 16.8A 16.8A 16.7A 16.9A A 0.0 A 7.|-- 2001:4200::155:232:64:64A A 0.0%A A 10A A 16.9A 16.9A 16.8A 16.9A A 0.0 A 8.|-- 2001:4200::155:232:64:59A A 0.0%A A 10A A 17.7A 17.7A 17.5A 17.8A A 0.0 A 9.|-- 2001:4200:ffff:a::1A A A A 0.0%A A 10A A 17.2A 17.1A 17.0A 17.2A A 0.0 nishal@jnb:~$ but, as we established above, your network might be not adequately peered with tenet. iam pretty certain that this can be easily fixed, which is why i was curious about the networks' respective responses above. >A A HOWEVER it >A A could also be a simple routing issue, out via international, in >A A locally, but it's not easy to check all this, and that is a problem. >A A Should have been picked up and understood and sorted out. youare right! the Internet Police should have picked the routing problem between these two networks much earlier!!A :-) (hi bje!) in my experience, routing anomalies are generally fixed only when theyare *noticed* to be an actual anomaly.A and generally, that means that this is noticed, or reported by someone that spotted the problem. which goes back to:A did you report this, and did you get a response? there is no self-correcting, self-healing Internet, no matter what the sticker on the box said... >A A Point: All Ipv6 routed root dns servers go via jinx just fine, except >A A for tenet, this could be a simple BGP announcement issue, easy to >A A solve, but does not answer the 175 ms response if [3]disa.tenet.ac.zaA >A A is routed internationally. (See above point) i think weave safely established that thereas a problem here.A routing is a bi-directional process though. out of curiousity, whatas your source ASN, btw? >A A Point: If I know how to hijack, spoof and otherwise cause DNS problems >A A (I fix them), then there are many other who do, WHY is a dnsec sighned >A A DNS reply an issue, just to be sure of responses. Even if a root anchor >A A is established, it can be used, it can be changed, unless there are >A A control issues. >A A Point: running a dns server that runs queries chained, is a lot quicker >A A and secure than trusting your ISPs supplied cache servers. This also >A A allows a lot more efficient and quicker CDN source reply, as well as >A A making it more difficult to reroute queries. iam guessing by "chaineda you mean some sort of heirachial dns resolver service? being able to use a larger, cache that you trust, certainly helps, so nothing wrong with that. i think the argument about efficiency and quicker CDN replies are difficult to qualify, since many operators (not just CDNs) rely on really small TTLs which may negate heirachial caching. none of that is related in any way to DNSSEC though. >A A Point: Most server operating systems that are new try ipv6 first unless >A A specified, and I know desktop machines always try ipv6 first >A A unconfigured, so I'm hoping you understand the potential problems here. actually, thatas not necessarily true.A use your favourite search engine, and lookup ahappy eyeballsa. then, lookup some of the problems that ahappy eyeballsa created;A not the least of which is making it more difficult to spot problems like the one above. >A A Don't get me wrong, but I really do like to get to the root of >A A problems, and don't enjoy debates that waste everyones time, but I do >A A read everything, including the fine print and things need to add up, >A A otherwise everything based on the those basics suffers. your inital statement was " Also I have a feeling Ipv6 is also going to become a problema. i donat agree.A at least, i donat see IPv6 as a bigger problem than IPv4.A and, iave shown you that, at least from two different networks, there isnat a problem. does that mean that all networks have congruent peering policies?A A no, of course not. but thatas *not* an issue thatas caused by IPv6, more than networks having a consistent network peering policy. if youare interested in data that supports my assertion that this is not limited to IPv6, particularly relating to DNS response times, RIPE ATLAS has lots of great data from ZA networks, particularly on performance to the different DNS Roots.A (for reference, F,I,E,L,D,J,K, *should* all be local to a well connected domestic network). tl;dr - itas easy to spot, that the routing inconsistencies that you hint at for IPv6, exist for IPv4 too. an. ps.A oh, and if nothing else, if your_src_as reports that they have a peering issue to tenet, and gets that fixed, then *some* good has come out of this _______________________________________________ IOZ mailing list [13][email protected] [14]http://lists.internet.org.za/mailman/listinfo/ioz References 1. http://he.net/ 2. http://he.net/ 3. mailto:[email protected] 4. mailto:[email protected] 5. http://disa.tenet.ac.za/ 6. http://disa.tenet.ac.za/ 7. http://disa.tenet.ac.za/ 8. https://lg.inx.net.za/klg/index.php?server=JINX-RC&action=show+bgp+ipv6&args=2001%3A4200%3Affff%3Aa%3A%3A1 9. http://disa.tenet.ac.za/ 10. http://vl52-gw.inx.net.za/ 11. http://tenet.jinx.net.za/ 12. http://ae0-isd1-pe1.tenet.ac.za/ 13. mailto:[email protected] 14. http://lists.internet.org.za/mailman/listinfo/ioz --94eb2c1b50c6c77b3b055397b85b-- --===============1069737527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IOZ mailing list [email protected] http://lists.internet.org.za/mailman/listinfo/ioz --===============1069737527==--