nanog mailing list archives

Re: NANOG Digest, Vol 52, Issue 67

From: "carl gough [mobsource]" <carl () mobsource com>
Date: Tue, 29 May 2012 22:21:39 +1000

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 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 5/28/12, David Conrad <drc () 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 () 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
*************************************

Current thread:

Re: NANOG Digest, Vol 52, Issue 67 carl gough [mobsource] (May 29)
- RE: NANOG Digest, Vol 52, Issue 67 Nabil Sharma (May 29)
  - trading bandwidth carl gough [mobsource] (May 29)
    - Re: trading bandwidth Owen DeLong (May 29)
    - Re: trading bandwidth Brett Watson (May 29)
    - Re: trading bandwidth John Kristoff (May 29)
    - RE: trading bandwidth Lorell Hathcock (May 29)
    - Re: trading bandwidth Carlos Alcantar (May 29)
    - Re: trading bandwidth Mark Andrews (May 29)