Date: Tue, 29 May 2012 22:21:39 +1000 Subject: Re: NANOG Digest, Vol 52, Issue 67 From: carl@mobsource.com To: nanog@nanog.org
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-request@nanog.org" <nanog-request@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-request@nanog.org
You can reach the person managing the list at nanog-owner@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. (bmanning@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 <fernando@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.5000703@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
If you ever want a run down on how Enron did it (or didn't do it), there are several on this list who can tell you all about it. -----Original Message----- From: carl gough [mobsource] [mailto:carl@mobsource.com] Sent: Tuesday, May 29, 2012 4:50 PM To: Nabil Sharma; nanog@nanog.org Subject: trading bandwidth Thanks Nabil, Bandwidth Trading is not a new concept, but to make it work effectively it will have to address a couple of prerequisites to be successful. A network of buyers and sellers has to be created, contracted and connected for instant pricing, inventory management and delivery of a defined and standardised service. Not a la enron of course, they traded derivatives. [carl gough] founder and CEO +61 425 266 764 mobsource .com defined by benefits not by technology Skype - mobsource Follow @mobsource Facebook - mobsource From: Nabil Sharma <nabilsharma@hotmail.com> Date: Tue, 29 May 2012 14:06:41 +0000 To: carl gough <carl@mobsource.com>, <nanog@nanog.org> Subject: RE: NANOG Digest, Vol 52, Issue 67 Mr Karl: We use number of these service to improve delivery of our content to end users. Which service or services do you seek info for? Sincerely, Nabil 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: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
-- Fernando Gont e-mail: fernando@gont.com.ar || fgont@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 <marka@isc.org> To: Jay Ashworth <jra@baylink.com> Cc: NANOG <nanog@nanog.org> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. Message-ID: <20120529023823.C2B5220FE5A8@drugs.dv.isc.org>
In message <23491623.6382.1338256344974.JavaMail.root@benjamin.baylink.com>, Jay Ashworth writ es:
----- Original Message -----
From: "Mark Andrews" <marka@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 jra@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: marka@isc.org
------------------------------
Message: 3 Date: Tue, 29 May 2012 12:47:10 +1000 From: Mark Andrews <marka@isc.org> To: Jimmy Hess <mysidia@gmail.com> Cc: NANOG <nanog@nanog.org> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. Message-ID: <20120529024710.8971D20FE6A0@drugs.dv.isc.org>
In message <CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg@mail.gmail.com> , Jimmy Hess writes:
On 5/28/12, Mark Andrews <marka@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: marka@isc.org
------------------------------
Message: 4 Date: Mon, 28 May 2012 23:58:00 -0500 From: Jimmy Hess <mysidia@gmail.com> To: David Conrad <drc@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=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
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
On 5/28/12, David Conrad <drc@virtualized.org> wrote: 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: bmanning@vacation.karoshi.com To: Mark Andrews <marka@isc.org> Cc: NANOG <nanog@nanog.org> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. Message-ID: <20120529055919.GA23179@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 <randy@psg.com> To: Jimmy Hess <mysidia@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%randy@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 <marka@isc.org> To: bmanning@vacation.karoshi.com Cc: NANOG <nanog@nanog.org> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. Message-ID: <20120529063731.686622106AEB@drugs.dv.isc.org>
In message <20120529055919.GA23179@vacation.karoshi.com.>, bmanning@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: marka@isc.org
------------------------------
Message: 8 Date: Mon, 28 May 2012 23:42:14 -0700 From: George Herbert <george.herbert@gmail.com> To: "bmanning@vacation.karoshi.com" <bmanning@vacation.karoshi.com> Cc: NANOG <nanog@nanog.org> Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you. Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7@gmail.com> Content-Type: text/plain; charset=us-ascii
On May 28, 2012, at 22:59, bmanning@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 <dot@dotat.at> To: Randy Bush <randy@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.5807@hermes-2.csi.cam.ac.uk> Content-Type: TEXT/PLAIN; charset=US-ASCII
Randy Bush <randy@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 <dot@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 *************************************