- Test - lists.nanog.org

isc - a good business
by paul vixie 31 May '12

31 May '12

greetings. i didn't notice this before, and i want to complete the record. i'm paying more attention to the quoting this time, too. > On Wed, May 23, 2012 at 04:33:28PM -0400, Christopher Morrow wrote: > > On Wed, May 23, 2012 at 1:40 AM, <bmanning at vacation.karoshi.com> wrote: > > > Paul will be there to turn things off when > > > they no longer make money for his company. > > > > is the dns changer thingy making money for isc? no. yes. depends on what you mean. we're under contract to the department of justice to run the servers. the amount is intended to be cost-recovery level. (doing stuff like this for nothing does not scale, unless the business is successful enough elsewhere, and even then there'll be limits.) > From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) > Date: Wed, 23 May 2012 21:00:27 +0000 > Message-ID: <20120523210027.GA26231(a)vacation.karoshi.com.> > > pretty sure. a contract w/ the Feds, outsouring contracts w/ affected ISPs > when the Fed deal runs out, development funding to code these kinds of fixes > into future versions of software, any number of second and third order fallout. i don't know of any outsourcing contracts that will come into force when the fed deal runs out. there is no development funding because there are no code fixes for this kind of problem. i am certainly hoping for second and third order fallout; we pay the people who write BIND using money collected from other people who buy support for BIND, or consulting, or training, or custom feature development. that's how we keep BIND free, and that's how we use a BSD-like license rather than a GPL-like license -- noone who derives their appliance or product from BIND has any obligation to anybody. (noting, nlnetlabs for unbound and nsd also use a BSD-like license, so ISC is not alone here.) > No telling how effective constent self-promotion is. One thing is clear, Paul > is able to tell a great story. thanks for your kind words. i've been trying to uplevel my storytelling capability since i've long since lost my coding skills. > but its all speculation from here. ISC is well positioned to extract value > from both ends of the spectrum. They have a great business model. The optics > look pretty odd from here, at lesat to me however - I am very glad for: )open > source & )other vendors of DNS SW. the women and men of ISC work their asses off to keep the world safer and saner. as you puzzle over our business model please keep in mind that there is no "exit" possibility here -- no IPO, no buyout. salaries at ISC are fair and reasonable, but nobody's getting rich doing this work. so while i am likewise glad for open source and for other vendors of open source DNS software, i'm struggling to grasp the intended suggestion. should ISC stop giving away software? should we stop adding the features to our software that make it relevant and desireable? should we stop selling the support and training and consulting that make it possible to give away this software? if you have a specific accusation of evil-doing, or a specific suggestion for how ISC can become more morally pure, then please say exactly what you mean, and we can discuss that. for more information, see: <http://www.isc.org/community/blog/201001/why-isc-not-profit>. the short version is: ISC is a good business, we do good things, mostly for free, but also for our customers. and we're totally unapologetic about what we do and who we are. paul

13 23

Help us to help you debug networks
by Nick McKeown 30 May '12

30 May '12

Dear Colleague, I am writing to ask you to help us.... so that we might help you. My group at Stanford University is building open source tools to automatically diagnose network failures such as reachability problems, networks loops, and traffic congestion. Our goal is to create tools that are useful to people who own and operate real production networks. Would you be willing to fill out a quick 5-minute survey to help us with our research? I know we all get asked to fill out a lot of these surveys - our goal here is to learn from you, so we can help you in your job, and help the community more broadly. To test our ideas, and to help us build tools that would be useful to you, we need your input: We want to know what network problems you deal with in your network. We plan to publish the results of our survey in an anonymized, aggregated form that you might find useful, along with our research results. Please feel free to forward this email. You can find the survey at http://svy.mk/NetDebug Many thanks. We really appreciate your time. - Nick -------------------------- Professor of Computer Science Stanford University

1 0

Cisco Security Advisory: Cisco IOS XR Software Route Processor Denial of Service Vulnerability
by Cisco Systems Product Security Incident Response Team 30 May '12

30 May '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco IOS XR Software Route Processor Denial of Service Vulnerability Advisory ID: cisco-sa-20120530-iosxr Revision 1.0 For Public Release 2012 May 30 16:00 UTC (GMT) +--------------------------------------------------------------------- Summary ======= Cisco IOS XR Software contains a vulnerability when handling crafted packets that may result in a denial of service condition. The vulnerability only exists on Cisco 9000 Series Aggregation Services Routers (ASR) Route Switch Processor (RSP440) and Cisco Carrier Routing System (CRS) Performance Route Processor (PRP). The vulnerability is a result of improper handling of crafted packets and could cause the route processor, which processes the packets, to be unable to transmit packets to the fabric. Cisco has released free software updates that address this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-… -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAk/GMvQACgkQQXnnBKKRMNDF2wD6A5yZWmZgCmk5x+RJ2mxIXzcW RXsu7/NENNspgbOJk2wA/RIJ9Fbzy+QZTRuQtg2vX0vCOhterMOVmN3Ue0VCzj52 =lCxE -----END PGP SIGNATURE-----

1 0

Contact Requested : China Telecom and SingTel
by Olivier CALVANO 30 May '12

30 May '12

Hi anyone have the name/email of a contact into China Telecom and SingTel for operator ? thanks olivier

2 1

yahoo uk & ireland contact
by Athanasios Douitsis 30 May '12

30 May '12

Hi, Could someone from engineer from yahoo uk & ireland please contact me off-list? I am the admin of a provider with ~25000 DSL users in Greece. For some months now, yahoo cannot be accessed correctly from our newly acquired IP block 37.32.128.0/17. Reportedly, the problem appears when talking to 217.146.187.123 but doesn't appear when talking to 217.12.8.76. Even the contact mail registered with RIPE (uk-abuse(a)cc.yahoo-inc.com) returns an automated response saying they don't read mail from that address. Regards to all, Athanasios Douitsis

1 0

NANOG 55 Peering Track agenda and announcements
by Steve Ginsberg 30 May '12

30 May '12

Hi All, Here's the current plan for the Peering BOF. Session will take place on Monday, June 4, 2012 from 4:30 PM to 6:00 PM in Salon D-F Please join us for a lively discussion. NANOG Peering BoF 90 minutes Introductions and PeeringDB PSA 5min Peering Personals Part I 5min LinkedIN Presentation/Discussion 20min IX Updates 5 min Peering Personals Part 2 5-10 min Pandora Presentation/Discussion 20min Mobile/Peering Changes Discussion 20 min * If you'd like to be part of new Peering Personals - a chance to announce your intention to peer - we'd love to meet you. Please email me off-list with Name, Organization, and URL in Peeringdb by next Monday. * If you're an IX and want to be part of the IX update, please email me directly for the slide template. I'll send it to you so you can submit 1-3 (no more) PowerPoint slides which can be rolled with out narration, by next Monday. * I'd also like to speak to some more folks who work for the Mobile carriers so please get in touch if you'd like to help. ~Steve http://www.pandora.com/profile/peace https://www.peeringdb.com/private/participant_view.php?id=1407 for peering requests please send to peering(a)pandora.com

1 1

Comcast Service for Non-Cap Bandwidth
by Nabil Sharma 30 May '12

30 May '12

NANOG List, I am developing streaming video service, and seek your feedback... I would like to pay Comcast forward so that accessing our site does not count against user's bandwidth caps, similar to the arrangement made with Microsoft Xbox. Does anyone know the name of this service? Is it something the sales contact at http://as7922.peeringdb.com/ can provide? Thank you for your time. Sincerely, Nabil

6 13

Re: NANOG Digest, Vol 52, Issue 74
by carl gough [mobsource] 30 May '12

30 May '12

>John, I think we have cross wires, without meaning to advertise or tout >for business, the bandx solution and the enron solutions totally missed >the mark in terms of timing. Every revolution, wether electricity, steam, automotive or telecoms, goes through a boom, then a bust, then a golden age period that emerges where it matures, we are in a maturity period now of IT. The names above, came at a time when the boom and subsequent bust occurred, they were not around for the golden age - fast forward to now, over a decade later since bandx, and you have the pieces of the puzzle that can be re assembled using the right technology. We don¹t differentiate using technology anymore, we get creative with the way we use iT. 70% of the worlds capacity is unlit, untouched, and creating no value whatsoever - http://mobsource.tumblr.com/post/22890631023/bandwidth-trading-platform-liv e >Message: 7 >Date: Tue, 29 May 2012 19:46:08 -0500 >From: John Kristoff <jtk(a)cymru.com> >To: Owen DeLong <owen(a)delong.com> >Cc: "carl gough \[mobsource\]" <carl(a)mobsource.com>, nanog(a)nanog.org >Subject: Re: trading bandwidth >Message-ID: <20120529194608.74e83eb6@localhost> >Content-Type: text/plain; charset=US-ASCII > >On Tue, 29 May 2012 15:10:04 -0700 >Owen DeLong <owen(a)delong.com> wrote: > >> IIRC, the concept was first introduced by MCI and Enron to great >> fanfare and subsequent graphic demonstrations of the destructive >> power of unregulated markets controlled by people of limited moral >> fortitude. > >I thought those big organizations actually came in later. Here is an >article discussing Band-X, which was one of at least two as I recall >that predated some of some of those more well known, later entrants: > > http://www.technologyreview.com/communications/11772/ > >John > >

1 0

the report from the spambox front
by Randy Bush 30 May '12

30 May '12

as part of daily maint, where i read midnight logs from 20+ systems etc, i scan my spambox to make sure nothing falls through, and indeed catch one or two daily. but the spam is a source of great amusement. the internet is an wondrous place. the number of messages offering help for the serious bedbug problem has been dropping off recently. so there really is hope we are winning the war on the bedbug front. whew! fedex has so many dell xps laptops in transit to me that storing them looks to become a serious problem. anyone with some space in a storage locker near jimbocho? zita would really like to take advantage of all the free lobsters, but there is no red lobster we know of in tokyo [0]. as tokyo has everything, i am sure i could find one. but will they take an american coupon? a lot of russians are still trying to draw my attention to something which is obviously important. anyone out there read russian? i hope it is not something critical, like news on the bedbugs in moscow. we would love to take advantage of all the great clearance sales on fords, but the cost of garaging a car, especially a large one, in tokyo is a bit steep. randy, who has to run out to the accountant to keep up with all the fraud monitoring reports on my bank accounts and credit cards in the caymans.

3 2

Re: NANOG Digest, Vol 52, Issue 67
by carl gough [mobsource] 30 May '12

30 May '12

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

8 8