NANOG Digest, Vol 52, Issue 67

Tue May 29 12:21:39 UTC 2012

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 at nanog.org" <nanog-request at nanog.org>
wrote:

>Send NANOG mailing list submissions to
>	nanog at 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 at nanog.org
>
>You can reach the person managing the list at
>	nanog-owner at 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 at 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 at gont.com.ar>
>To: NANOG <nanog at nanog.org>
>Subject: IPv6 security: New IETF I-Ds, slideware and videos of recent
>	presentations, trainings, etc...
>Message-ID: <4FC423AD.5000703 at 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: fgont at si6networks.com
>PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>
>
>-- 
>Fernando Gont
>e-mail: fernando at gont.com.ar || fgont at 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 at isc.org>
>To: Jay Ashworth <jra at baylink.com>
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <20120529023823.C2B5220FE5A8 at drugs.dv.isc.org>
>
>
>In message 
><23491623.6382.1338256344974.JavaMail.root at benjamin.baylink.com>, Jay
>Ashworth writ
>es:
>> ----- Original Message -----
>> > From: "Mark Andrews" <marka at 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 at 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 at isc.org
>
>
>
>------------------------------
>
>Message: 3
>Date: Tue, 29 May 2012 12:47:10 +1000
>From: Mark Andrews <marka at isc.org>
>To: Jimmy Hess <mysidia at gmail.com>
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <20120529024710.8971D20FE6A0 at drugs.dv.isc.org>
>
>
>In message 
><CAAAwwbWRGcGcxhJ7G4XcFTr=6Q--EOWkBgnOqHWBA1o0BB+zhg at mail.gmail.com>
>, Jimmy Hess writes:
>> On 5/28/12, Mark Andrews <marka at 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 at isc.org
>
>
>
>------------------------------
>
>Message: 4
>Date: Mon, 28 May 2012 23:58:00 -0500
>From: Jimmy Hess <mysidia at gmail.com>
>To: David Conrad <drc at virtualized.org>
>Cc: NANOG Mailing List <nanog at nanog.org>
>Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
>	registrar/registry policies
>Message-ID:
>	<CAAAwwbX8h=3mBuWVO3bpVijqndmmCRRZmNXi5xf5vicc2QdmkQ at mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On 5/28/12, David Conrad <drc at 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: bmanning at vacation.karoshi.com
>To: Mark Andrews <marka at isc.org>
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <20120529055919.GA23179 at 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 at psg.com>
>To: Jimmy Hess <mysidia at gmail.com>
>Cc: North American Network Operators' Group <nanog at nanog.org>
>Subject: Re: DNS anycasting - multiple DNS servers on same subnet Vs
>	registrar/registry policies
>Message-ID: <m2txyzikfm.wl%randy at 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 at isc.org>
>To: bmanning at vacation.karoshi.com
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <20120529063731.686622106AEB at drugs.dv.isc.org>
>
>
>In message <20120529055919.GA23179 at vacation.karoshi.com.>,
>bmanning at 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 at isc.org
>
>
>
>------------------------------
>
>Message: 8
>Date: Mon, 28 May 2012 23:42:14 -0700
>From: George Herbert <george.herbert at gmail.com>
>To: "bmanning at vacation.karoshi.com" <bmanning at vacation.karoshi.com>
>Cc: NANOG <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID: <2A84793D-5D89-4F4E-ADC0-6CB578AD15F7 at gmail.com>
>Content-Type: text/plain;	charset=us-ascii
>
>
>
>
>
>On May 28, 2012, at 22:59, bmanning at 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 at dotat.at>
>To: Randy Bush <randy at psg.com>
>Cc: North American Network Operators' Group <nanog at nanog.org>
>Subject: Re: NXDomain remapping, DNSSEC, Layer 9, and you.
>Message-ID:
>	<alpine.LSU.2.00.1205291050540.5807 at hermes-2.csi.cam.ac.uk>
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>Randy Bush <randy at 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 at 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
>*************************************