NANOG Digest, Vol 52, Issue 67
carl gough [mobsource]
carl at mobsource.com
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
>*************************************
More information about the NANOG
mailing list