Does anyone have any intel on bandwidth trading in the usa? [carl gough] founder and CEO +61 425 266 764
mobsource .com defined by benefits not by technology Skype mobsource Follow @mobsource Facebook mobsource On 29/05/12 7:52 PM, "nanog-requ...@nanog.org" <nanog-requ...@nanog.org> wrote: >Send NANOG mailing list submissions to > nanog@nanog.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog >or, via email, send a message with subject or body 'help' to > nanog-requ...@nanog.org > >You can reach the person managing the list at > nanog-ow...@nanog.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of NANOG digest..." > > >Today's Topics: > > 1. IPv6 security: New IETF I-Ds, slideware and videos of recent > presentations, trainings, etc... (Fernando Gont) > 2. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews) > 3. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews) > 4. Re: DNS anycasting - multiple DNS servers on same subnet Vs > registrar/registry policies (Jimmy Hess) > 5. Re: NXDomain remapping, DNSSEC, Layer 9, and you. > (bmann...@vacation.karoshi.com) > 6. Re: DNS anycasting - multiple DNS servers on same subnet Vs > registrar/registry policies (Randy Bush) > 7. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Mark Andrews) > 8. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (George Herbert) > 9. Re: NXDomain remapping, DNSSEC, Layer 9, and you. (Tony Finch) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 28 May 2012 22:17:33 -0300 >From: Fernando Gont <ferna...@gont.com.ar> >To: NANOG <nanog@nanog.org> >Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent > presentations, trainings, etc... >Message-ID: <4fc423ad.5000...@gont.com.ar> >Content-Type: text/plain; charset=ISO-8859-1 > >Folks, > >* We've published a new IETF I-D entitled "DHCPv6-Shield: Protecting >Against Rogue DHCPv6 Servers", which is meant to provide RA-Guard-like >protection against rogue DHCPv6 servers. The I-D is available at: ><http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt> >Other IPv6 security I-Ds (such as, >draft-ietf-v6ops-ra-guard-implementation) have been revised. Please >check them out at: ><http://www.si6networks.com/publications/ietf.html> > >* The slideware (and some videos!) of some of our recent presentations >about IPv6 security are now available online. You can find them at: ><http://www.si6networks.com/presentations/index.html> > >* We have also scheduled IPv6 hacking trainings in Paris (France) and >Ghent (Belgium). You can find more details at: ><http://www.si6networks.com/index.html#conferences> > >Our Twitter: @SI6Networks >ipv6hackers mailing-list: ><http://lists.si6networks.com/listinfo/ipv6hackers/> > >Thanks! > >Best regards, >-- >Fernando Gont >SI6 Networks >e-mail: fg...@si6networks.com >PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > >-- >Fernando Gont >e-mail: ferna...@gont.com.ar || fg...@si6networks.com >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > >------------------------------ > >Message: 2 >Date: Tue, 29 May 2012 12:38:23 +1000 >From: Mark Andrews <ma...@isc.org> >To: Jay Ashworth <j...@baylink.com> >Cc: NANOG <nanog@nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <20120529023823.c2b5220fe...@drugs.dv.isc.org> > > >In message ><23491623.6382.1338256344974.javamail.r...@benjamin.baylink.com>, Jay >Ashworth writ >es: >> ----- Original Message ----- >> > From: "Mark Andrews" <ma...@isc.org> >> >> [ vix: ] >> > > > meanwhile isc continues to push for ubiquitous dnssec, through to >> > > > the stub, >> > > > to take this issue off the table for all people and all time. >> > > > (that's "the >> > > > real fix" for nxdomain remapping.) >> > > >> > > You really believe that the outcome of that will be "we can't make >> > > some >> > > extra revenue off NXDOMAIN remapping because of DNSSEC? Well, the >> > > hell >> > > with DNSSEC, then"? >> > >> > People will route around ISP that do stupid things. They do so >> > today. When your browers supports DANE there will be more incentive >> > to ensure that DNSSEC does not break and more incentive to route >> > around ISP's that do break DNSSEC. >> >> My personal reaction to that, Mark, is to say that you *badly* >>overestimate >> the average Internet end-user (who make up, roughly, 80% of the >>endpoints, >> in my jackleg estimation). > >Google's recursive nameservers see plenty of traffic. > >> > Even a ISP that is redirecting on NXDOMAIN wants to be sure that >> > it is a real NXDOMAIN not one that is spoofed do the path to the >> > ISP's resolver will be DNSSEC clean and they will be validating. >> >> I'm not sure I understood that... > > Authoritative server > ^ > secure > (DO=1 queries) > v > ISP's validating recursive server > ^ > insecure, redirect possible > (DO=0 queries) > v > Stub clients. > >Putting it another way, the ISP doesn't want to be fooled even if >it is fooling its customers. The ISP can't allow it's recursive >servers to get the wrong answers for irs.gov, picking a signed >domain, as they would look silly for not validating when there is >a simple way for them to be sure that they are not being spoofed. > >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't >> > be a problem for ISP's that want to do nxdomain redirection. There >> > still plenty of crappy DNS proxies in CPE routers to be replaced >> > before you can just set DO=1 as a default without worrying about >> > breaking DNS lookups. Even setting EDNS as a default is a issue. >> >> ...but that's probably because I don't understand DNSSEC well enough. > >The ISP <-> stub client path often has a additional piece in the >path that is often a heap of steaming !@$! that doesn't do basic >DNS let alone EDNS and DNSSEC. For example the Netgear router at >home doesn't support DNS over TCP which is basic DNS (I'm using it >as a access point not a router because of this). It's this sort >of breakage that is stopping OS vendors changing defaults. This >can often be bypassed by forcing the resolver to use the ISP's >nameservers directly but you need to know to do that. > > ISP's validating recursive server > ^ > v > CPE Router (broken DNS proxy code) > ^ > v > Stub clients. > >You can also replace CPE Router with a broken firewall that is a >steaming heap of !@#% when it comes to DNS packet inspection. These >are harder to bypass and require someone to fix the configuration >to replace/upgrade the box. > >> > That said we are starting down the long path to making it EDNS a >> > default. DiG in BIND 9 defaults to using EDNS and "dig +trace" >> > turns set DO=1 as well. You don't get things fixed if the breakage >> > is not visible. >> >> We may be talking about different breakage here... >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >>j...@baylink.com >> Designer The Things I Think >>RFC 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >>Rover DII >> St Petersburg FL USA http://photo.imageinc.us +1 727 >>647 1274 >> >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > >------------------------------ > >Message: 3 >Date: Tue, 29 May 2012 12:47:10 +1000 >From: Mark Andrews <ma...@isc.org> >To: Jimmy Hess <mysi...@gmail.com> >Cc: NANOG <nanog@nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <20120529024710.8971d20fe...@drugs.dv.isc.org> > > >In message ><CAAAwwbWRGcGcxhJ7G4XcFTr=6q--eowkbgnoqhwba1o0bb+...@mail.gmail.com> >, Jimmy Hess writes: >> On 5/28/12, Mark Andrews <ma...@isc.org> wrote: >> > Until stub resolvers set DO=1 pretty much ubiquitously this won't >> > be a problem for ISP's that want to do nxdomain redirection. There >> >> Yeah............. >> Right now current _server_ implementations don't even have it right, >> for properly implementing DNSSEC validation down to that level, let >> alone the stubs below the server. >> >> Many SME LANs utilize Windows-based endpoints, and commonly have >> Windows-based DNS servers on the LAN, used by endpoints, where the >> Windows DNS servers are set to forward queries to ISP recursive >> servers. Current Windows' DNS server in 2008 "supports" DNSSEC. >> When Windows DNS server is configured to forward DNS queries to a >> list of reasonable recursive DNS servers, the server sets CD (Check >> disabled) bit set, and the DO bit set for all queries it sends; >> there is no option to "support dnssec queries from smart stubs but >> don't send queries from dumb stubs with CD". > >Well I'm trying to get this fixed at the protocol level for other >reasons as explained in >http://www.ietf.org/mail-archive/web/dnsext/current/msg12495.html > >draft-ietf-dnsext-dnssec-bis-updates-18.txt is still in IETF last >call and if you think always setting CD=1 when forwarding is bad for >whatever reason I could do with some support. > >> Also, there are by default no trust anchors, and _Every_ response is >> treated as valid. (In other words, CD bit and DO bits are set in >> forwarded queries, but no validation occurs). >> It's kind of like having a SSL implementation that treats ALL SSL >> certificates as valid, until and unless you take manual steps to >> configure a CA list. >> >> If you don't like this default and want to configure Windows DNS with >> the root trust anchor.... Sorry, Algorithm #5 RSA/SHA-1 is the only >> supported key type, and the current root signing key is not of a >> compatible format. >> >> Your "smart" stub can send a query to this broken DNSSEC >> implementation with the DO bit set, for sure. >> >> >> >> >> > still plenty of crappy DNS proxies in CPE routers to be replaced >> > before you can just set DO=1 as a default without worrying about >> > breaking DNS lookups. Even setting EDNS as a default is a issue. >> [snip] >> >> I'm all for smart stubs as long as (1) They can get the data to them >> (2) They can get the proper logging/reporting to them, E.g. No >> "silent" upstream validate/discard; No upstream silent "ignore >> the stub's requested CD bit and validate/discard anyways" >> and >> >> (3) The validation path is intact for _dumb_ non-validating stubs too. >> >> -- >> -JH >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > >------------------------------ > >Message: 4 >Date: Mon, 28 May 2012 23:58:00 -0500 >From: Jimmy Hess <mysi...@gmail.com> >To: David Conrad <d...@virtualized.org> >Cc: NANOG Mailing List <nanog@nanog.org> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs > registrar/registry policies >Message-ID: > <CAAAwwbX8h=3mbuwvo3bpvijqndmmcrrzmnxi5xf5vicc2qd...@mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >On 5/28/12, David Conrad <d...@virtualized.org> wrote: >> On May 28, 2012, at 11:51 AM, Anurag Bhatia wrote: >>> I know few registry/registrars >>> which do not accept both (or all) name servers of domain name on same >>> subnet. They demand at least 1 DNS server should be on different >>>subnet for >>> failover reasons (old thoughts). >> IMHO appropriately so. The fact that anycast allows for multiple >> (potentially) geographically distributed machines to respond to DNS >>queries >> does not remove the value of having multiple prefixes for DNS servers. >[snip] >It dramatically reduces the value, and meets the basic RFC requirement >for geographically distributed DNS servers, although there are still >routing issues that will impact all DNS servers to share a prefix >It is more important that a domain registrar not refuse to register a >domain, or erroneously declare a valid listing invalid. > >The purpose of using a registrar is to establish DNS delegation, not >to validate your site's redundancy meets the absolute best possible >practices for fault tolerance. > >Ideally certainly should have DNS servers under multiple prefixes -- >and it seems a little bit silly to go through all the trouble of >implementing a complicated anycast geo. dist scheme, while ignoring >a simpler failure mode. It's your choice. > >It's not appropriately so for a registrar to say anything your choice; >thats your network >not theirs. By the same token the registrar can't tell you not to >alias all 3 IP addresses on >different subnets to the same physical server. > >Again, it's ill-advised, but a "mistake" that has nothing to do with >the registrar's network or the registration service. > >-- >-JH > > > >------------------------------ > >Message: 5 >Date: Tue, 29 May 2012 05:59:19 +0000 >From: bmann...@vacation.karoshi.com >To: Mark Andrews <ma...@isc.org> >Cc: NANOG <nanog@nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <20120529055919.ga23...@vacation.karoshi.com.> >Content-Type: text/plain; charset=us-ascii > >On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >> >> Putting it another way, the ISP doesn't want to be fooled even if >> it is fooling its customers. > > don't lie to us, but we lie to our customers. > > and you don't see a problem with this? > >/bill > > > >------------------------------ > >Message: 6 >Date: Tue, 29 May 2012 15:13:33 +0900 >From: Randy Bush <ra...@psg.com> >To: Jimmy Hess <mysi...@gmail.com> >Cc: North American Network Operators' Group <nanog@nanog.org> >Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs > registrar/registry policies >Message-ID: <m2txyzikfm.wl%ra...@psg.com> >Content-Type: text/plain; charset=US-ASCII > >> It is more important that a domain registrar not refuse to register a >> domain, or erroneously declare a valid listing invalid. >> >> The purpose of using a registrar is to establish DNS delegation, not >> to validate your site's redundancy meets the absolute best possible >> practices for fault tolerance. > >just for my curiosity, where do you draw the line for technical >compliance? do the servers need to serve the zone? does the served >zone need to have the same NS RRset as the request and hence parent? >do the servers need to be able to answer compliant dns queries? over >tcp too? > >your first paragraph quoted above would seem to say that none of this is >needed. the registrar's job is to stick the delegation in the parent >zone and actually functioning name service be damned. > >randy, a naggumite > > > >------------------------------ > >Message: 7 >Date: Tue, 29 May 2012 16:37:29 +1000 >From: Mark Andrews <ma...@isc.org> >To: bmann...@vacation.karoshi.com >Cc: NANOG <nanog@nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <20120529063731.686622106...@drugs.dv.isc.org> > > >In message <20120529055919.ga23...@vacation.karoshi.com.>, >bmann...@vacation.ka >roshi.com writes: >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >> > >> > Putting it another way, the ISP doesn't want to be fooled even if >> > it is fooling its customers. >> >> don't lie to us, but we lie to our customers. >> >> and you don't see a problem with this? > >I didn't say I like it. It may even be illegal in some juristictions >for a ISP to do it without properly informing the customer and >allowing them to opt in/out. Doing it to yourself however can't >be illegal. In the end it is a tool and the method of deployment >is often as important as whether you deploy it or not. > >It's a little like direct marketing via email. If you have consent >of the party being emailed it isn't spam. If you don't have consent >it is spam at least here in Australia. Other juristictions have >looser guidelines. > >Mark >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > >------------------------------ > >Message: 8 >Date: Mon, 28 May 2012 23:42:14 -0700 >From: George Herbert <george.herb...@gmail.com> >To: "bmann...@vacation.karoshi.com" <bmann...@vacation.karoshi.com> >Cc: NANOG <nanog@nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: <2a84793d-5d89-4f4e-adc0-6cb578ad1...@gmail.com> >Content-Type: text/plain; charset=us-ascii > > > > > >On May 28, 2012, at 22:59, bmann...@vacation.karoshi.com wrote: > >> On Tue, May 29, 2012 at 12:38:23PM +1000, Mark Andrews wrote: >>> >>> Putting it another way, the ISP doesn't want to be fooled even if >>> it is fooling its customers. >> >> don't lie to us, but we lie to our customers. >> >> and you don't see a problem with this? >> >> /bill > >We tried saying no, we tried walking customers away, we tried not adding >the feature, we tried shame, someone reputedly had dolls with pins in >them. > >We lost. > >There is an endgame around that; when it's ready.... > > >George William Herbert >Sent from my iPhone > > >------------------------------ > >Message: 9 >Date: Tue, 29 May 2012 10:51:54 +0100 >From: Tony Finch <d...@dotat.at> >To: Randy Bush <ra...@psg.com> >Cc: North American Network Operators' Group <nanog@nanog.org> >Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. >Message-ID: > <alpine.lsu.2.00.1205291050540.5...@hermes-2.csi.cam.ac.uk> >Content-Type: TEXT/PLAIN; charset=US-ASCII > >Randy Bush <ra...@psg.com> wrote: >> >> > When your browers supports DANE >> >> and a billion home nats support dnssec :( > >I expect there will be a depressingly large amount of DNS-over-TLS in the >future in order to bypass broken ALGs. > >Tony. >-- >f.anthony.n.finch <d...@dotat.at> http://dotat.at/ >Malin: Cyclonic 4 or 5. Slight or moderate. Fog patches. Moderate, >occasionally very poor. > > > >End of NANOG Digest, Vol 52, Issue 67 >*************************************