Call for Presentations: 33rd DNS-OARC Workshop, Paris, France, May 09 - 10th 2020

[Joe Abley]

The 33rd DNS-OARC Workshop will take place at the Marriott Rive Gauche Hotel & 
Conference Center in Paris, France on May 9th and 10th 2020. It is co-located 
with and will take place right after the ICANN GDD (May 3rd to 6th), 
Registrations Operations Workshop (May 6th) and ICANN DNS Symposium (May 7th 
and 8th).

The Workshop's Program Committee is requesting proposals for presentations. All 
DNS-related subjects are welcome.

A time slot will also be available for lightning talks (5-10 minutes each) on 
day two of the workshop, for which submissions will be accepted just before the 
start of the workshop and until the start of the morning break on day two. 
Poster submissions are also welcome.

There will be an OARC Business session during the workshop, which will be for 
OARC Members only. If you are an OARC member and have a sensitive topic that 
you wish to present during that session those can be accommodated.

Workshop Milestones:
  10 Jan 2020 - Submissions open via Indico
  05 Mar 2020 - Deadline for submission (midnight CEST)
  19 Mar 2020 - Initial Contribution list published
  02 Apr 2020 - Full agenda published
  02 May 2020 - Deadline for slideset submission
  09 May 2020 - Workshop begins

Details for presentation submission are published here:

  <https://indico.dns-oarc.net/event/34/call-for-abstracts/>

The workshop presentations will be organized by common themes, depending on the 
topics and the timing of each presentation. There are 30-minute and 15-minute 
slots, let us know your preference in your submission.

To allow the Programme Committee to make objective assessments of submissions, 
so as to ensure the quality of the workshop, submissions SHOULD include slides. 
Draft slides are acceptable on submission.

If you have questions or concerns you can contact the Programme Committee:

  https://www.dns-oarc.net/oarc/programme

via 

Joe Abley, for Dave Knight, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social events. 
 Please contact  if your organization is interested in 
becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a position 
to reimburse expenses or time for speakers at its meetings.)

Re: BGP over TLS

[Joe Abley]

On 21 Oct 2019, at 12:05, Keith Medcalf  wrote:

> On Monday, 21 October, 2019 09:44, Robert McKay  wrote:
> 
>> The MD5 authentication is built into TCP options.. not obvious how you
>> would transport it over TLS which afaik doesn't offer similar
>> functionality.
> 
> AHA!  I understand now and sit corrected.  I was under the mistaken 
> impression that MD5 authentication was an application level thing, not a TCP 
> level thing.

Well, TLS exists within a TCP session, and that TCP session could incorporate 
the MD5 signature option. I guess.

Julien's BGP-STARTTLS idea is interesting. I wonder about the practicality of 
deploying certificates to every BGP speaker that are useful for strict checking 
by neighbours, though. Perhaps I've been too long with my hands out of routers 
and things have moved on, but it seems to me that the history of certificate 
management in routers is not a rich tapestry of triumph.

Without strict checking in both directions, the threat model with TLS looks 
pretty similar to that with TCP-MD5 with not very secret secrets, which I 
gather is one of the deficiencies that the TLS proposal seeks to address.


Joe

OARC 31 Agenda Published ; OARC32 CfP!

[Joe Abley]

Note for the record: I am not actually Keith, nor do I play Keith on TV.

--

Dear colleagues,

The agenda for the 31st DNS-OARC Workshop has now been
published at:

 

OARC 31 takes place at the JW Marriott Austin, in Texas, USA on
October 31st and November 1st, immediately after NANOG77.

REGISTRATION
==
To participate in person, please register to attend sooner rather
than later - Early Bird Registration ends on October 9th - at the
link below, on the “Registration” page:



OARC 32 CfP
==
OARC 32 will take place on February 8th, 2020 in San Francisco -
and now that we have announced the agenda for the upcoming
Workshop, we have opened the CfP for the one after. Take a look at:



Come and celebrate #OARCtoberfest with us!

Regards
Keith Mitchell, DNS-OARC.


signature.asc
Description: Message signed with OpenPGP

Re: Cost effective time servers

[Joe Abley]

On 21 Jun 2019, at 10:57, Quan Zhou  wrote:

> Yep, went through the same route until I figured out that GPS time is a bit 
> ahead of UTC.

The clocks on the GPS satellites are set to GPST which I think (I'm not a time 
geek so this is going to make someone cringe) is UTC without leap seconds or 
other corrections relating to rotation of the earth.

However, the messages sent to GPS receivers include the offset between GPST and 
UTC as well as the GPST timestamp. The receivers can use both together to 
obtain a measure of UTC accurate to about 100 nanoseconds.

Seems to me (again, not time geek, stop throwing things) that the use of GPST 
is an internal implementation detail chosen because it's easier to adjust an 
offset that rarely changes than it is to adjust atomic clocks floating in 
space. The system (including the system-internal adjustment of GPST with the 
offset) still produces a reasonably accurate measure of UTC. Also I imagine 
occasional leap seconds causing GPS navigators to jump spontaneously to the 
left which is probably more amusing in my imagination than in real life.


Joe


signature.asc
Description: Message signed with OpenPGP

Re: BGP person from Bell Canada/AS577

[Joe Abley]

On 19 Jun 2019, at 10:27, Mike Hammett  wrote:

> I'm curious as to why someone would want to do this? My interest is 
> education, not combative.

In previous lives I have had great success simply talking to people at Akamai 
about where my customers' traffic was landing, and where would make more sense 
for it to land. They were always very responsive; the people I used to talk to 
are no longer there, but I imagine there are replacements, even if you have to 
hunt a little further than the published noc address. I always took care to 
describe my problem in terms of clients and content rather than routing policy, 
which seemed like a better bet than making assumptions about how their 
content-steering machinery worked.

Asking Akamai seems more likely to succeed than asking a third-party network to 
modify their BGP export policy for a non-customer, especially when the 
third-party network is large and, I am guessing, highly-automated and 
policy-rigid. But it would be interesting to me too to find out if I'm wrong.

Jason, if you are multi-homed you could always try AS_PATH prepending 18717 to 
the advertisments you send towards 577 (he said, over his shoulder, running 
away).


Joe


signature.asc
Description: Message signed with OpenPGP

Re: someone is using my AS number

[Joe Abley]

On 13 Jun 2019, at 10:06, Job Snijders  wrote:

> 1/ We can’t really expect on the loop detection to work that way at the 
> “jacked” side. So if this is innocent traffic engineering, it is unreliable 
> at best.
> 
> 2/ Attribution. The moment you stuff AS 2914 anywhere in the path, we may get 
> blamed for anything that happens through the IP addresses for that route. In 
> a way the ASNs in the AS_PATH attribute an an inter-organizational escalation 
> flowchart.

Good answer! Somebody should write that down. :-)


Joe


signature.asc
Description: Message signed with OpenPGP

Re: someone is using my AS number

[Joe Abley]

Hey Joe,

On 12 Jun 2019, at 12:37, Joe Provo  wrote:

> On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote:
>> Send abuse complaint to the upstreams
> 
> ...and then name & shame publicly. AS-path forgery "for TE" was
> never a good idea. Sharing the affected prefix[es]/path[s] would
> be good.

I realise lots of people dislike AS_PATH stuffing with other peoples' AS 
numbers and treat it as a form of hijacking.

However, there's an argument that AS_PATH is really just a loop-avoidance 
mechanism, not some kind of AS-granular traceroute for prefix propagation. In 
that sense, stuffing 9327 into a prefix as a mechanism to stop that prefix 
being accepted by AS 9327 seems almost reasonable. (I assume this is the kind 
of TE you are talking about.)

What is the principal harm of doing this? Honest question. I'm not advocating 
for anything, just curious.


Joe



signature.asc
Description: Message signed with OpenPGP

Re: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover

[Joe Abley]

On 2 Nov 2017, at 09:25, Naslund, Steve  wrote:

> There are four facts to be aware of here.
> 
> 1.  Locators are not 100% especially when it comes to fiber.

I remember years ago in New Zealand there was buried fibre along the railway 
running north-south in the North Island that was not generally anybody's first 
choice of glass when trying to connect sites in Auckland and Wellington. The 
problem I heard described (from memory, long time ago, I am old) was that the 
natural vibration of the ground due to trains on rails had the effect over time 
of pushing conduit down the embankment away from the track, leading to fibre 
breaks with no corresponding obvious cause (no digging).

You could bounce signals down the copper in the conduit from either side to try 
and figure out where the break was, but once on site you still had to find the 
fibre which was usually not anywhere close to where the map said it was buried.


Joe

shipping from US to Telstra (ex-Pacnet) facility, 11 Chun Kwong St, Hong Kong

[Joe Abley]

Hi all,

If anybody has recently managed to ship equipment from the US to the Pacnet 
(now Telstra) facility at 11 Chun Kwong St, Hong Kong and doesn't mind 
comparing notes, any chance you could drop me a line off-list?

We have some shipping confusion, and it would be great to see an example of 
paperwork that is known not to have failed.

Thanks,


Joe

Re: list of .org domain names?

[Joe Abley]

On Dec 30, 2015, at 18:50, Ryan Finnesey  wrote:

> Is it possible to get a complete list of .org domain names that have been 
> registered?

If you can satisfy the terms of the sone file access agreement, you
can get a copy of the org zone which will give you a list of delegated
domain names (not quite the same as the list of registered domain
names, but similar).

http://pir.org/resources/file-zone-access/


Joe

Re: de-peering for security sake

[Joe Abley]

On Dec 26, 2015, at 10:09, Stephen Satchell  wrote:

> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes from 
> a /32, I block the /32.

... without any knowledge of how many end systems are going to be affected.

A significant campus or provider user base behind a NAT is likely to
have more infections in absolute terms, which means more observed bad
behaviour. It also means more end-systems (again, in absolute terms)
that represent collateral damage.

> When I get lots of SSH probes across a range of a /24, I block the /24.

[...]

> When I see that the bad traffic has caused me to block multiple /24s, I will 
> block the entire allocation.

Your network, your rules. But that's not the way I would manage things
if I thought my job was to optimise and maximise connectivity between
my users and the Internet.

With respect to ssh scans in particular -- disable all forms of
password authentication and insist upon public key authentication
instead. If the password scan log lines still upset you, stop logging
them.


Joe

Re: Rack Locks

[Joe Abley]

On Nov 20, 2015, at 20:55, Jimmy Hess  wrote:

> You're not going to be able to look at a log and see Joe opened it at 2:45AM
> 12 months ago,  and ever since then,  the servers are not quite right.

And I would have got away with it to, if it wasn't for you kids and
your pesky logs.


Joe

Re: bad announcement taxonomy

[Joe Abley]

On 18 Nov 2015, at 15:55, Arturo Servin wrote:

> Laundered route

The routes in question are not just being laundered, they're being bleached.


Joe

Re: configuration sanity check

[Joe Abley]

Salut Marcel,

On Oct 29, 2015, at 04:16, "marcel.durega...@yahoo.fr"
 wrote:

> Any recommendation about a software which check the live config of 
> cisco/juniper devices against some templates ?
>
> The goal is to have a template about different function device, like:
> - CORE device must have this bloc and this clock
> - PE device must have at least that and that
> - CPE must have this and that
> - Distrib switch block 1 and block2
> - etc...

Not precisely what you wanted but some pointers for doing it yourself:

https://www.nanog.org/meetings/nanog26/presentations/stephen.pdf

The example code was still on ftp.isc.org last time I checked.


Joe

Aue Te Ariki! He toki ki roto taku mahuna!

Re: *tap tap* is this thing on?

[Joe Abley]

On Oct 26, 2015, at 13:10, Brielle Bruns  wrote:

> This spam flood is kinda hilarious in a way.  Any idea why no one with mod or 
> admin privs for the mailing list has bothered to step in and deal with this?


I asked a similar question myself on another list.

But then after a minute's reflection, the fact that we all got 200+
messages like this on the NANOG list and not a single other message
complaining about it suggests that someone did actually hit the big
red moderation button promptly, and just waited until Monday to sort
it out (which would not have been completely unreasonable, I think).

The residual messages that tricked through after that seem likely to
be nothing more than outbound queues draining.


Joe

Fw: new message

[Joe Abley]

Hey!

 

New message, please read <http://lowveld-tours.com/often.php?lcvf>

 

Joe Abley

Re: /27 the new /24

[Joe Abley]

On 12 Oct 2015, at 11:23, Todd Underwood wrote:


it's also not entirely obvious what the point of having local IXes
that serve these kinds of collections of people.


I think that's true. But I don't think it's always the case this means 
there is no point.


When Citylink (incubated by the City Council) started stringing fibre 
around central Wellington, New Zealand and building fast ethernet access 
into buildings in the mid-90s it wasn't obvious what benefit that would 
give anybody at a time when most of the country was hanging off a 
collection of E1 half-circuit leases to the west-coast US. But it led to 
a cottage industry in teleworking, off-site data storage, digital print 
shops and video conferencing in the city that would not have been 
possible otherwise.


What Citylink built was part access network, part exchange, but to their 
credit they didn't spend too much time worrying about what to call what 
they were building: they just built it.


Part of keeping the network stupid is giving people at the edge room to 
innovate. Sometimes when you build it, they come.



Joe

Re: /27 the new /24

[Joe Abley]

On 7 Oct 2015, at 9:29, Matthew Kaufman wrote:


On Oct 7, 2015, at 5:01 AM, Owen DeLong  wrote:

Instead, the followup question is needed… “That’s great, but 
how does that help me reach a web site that doesn’t have and 
can’t get an IPv4 address?”


At the present time, a web site that doesn't have and can't get an 
IPv4 address isn't "on the Internet".


By the only definition of the Internet that matters, the function "is on 
the Internet" is very much in the eye of the beholder.


Using this definition, v6-only services are most certainly "on the 
Internet" for people who have v6 connectivity. Similarly, various 
instances of the Pirate Bay that have v4 reachability are not "on the 
Internet" for end-users in draconian jurisdictions like the UK. Trying 
to make assertions about what "on the Internet" means in a general, 
global sense is an effort doomed to failure.


I realise you're talking in pragmatic terms about services that have a 
general, dispersed, global end-user population, but not all services are 
like that.



Joe

[1] Internet, n: “the largest equivalence class in the reflexive 
transitive symmetric closure of the relationship ‘can be reached by an 
IP packet from’” (Seth Breidbart)

Re: root zone archive

[Joe Abley]

Hi Alvin,

On 17 Sep 2015, at 1:27, alvin nanog wrote:


On 09/17/15 at 12:33am, Joe Abley wrote:
...
I'm particularly interested in zone data that describes the build out 
of the
original root zone NS set to nine servers in mid-1994, the renaming 
under
the ROOT-SERVERS.NET domain and the subsequent assignment of J, K, L 
and M.


wouldn't that info be in the files included with bind-0.x


I don't know, but worth a look. Good idea, thanks!


Joe

root zone archive

[Joe Abley]

Hi all,

Is anybody here aware of a complete or partial archive of root zone data 
that is older than the set available at DNS-OARC? OARC's archive has 
nothing older than July 2009.


I'm particularly interested in zone data that describes the build out of 
the original root zone NS set to nine servers in mid-1994, the renaming 
under the ROOT-SERVERS.NET domain and the subsequent assignment of J, K, 
L and M.


I realise this is a bit of a long shot, but the answer's always no if 
you don't ask :-)


[I'm asking the same question on a small handful of lists; apologies if 
you get multiple copies of this.]



Joe

Re: Updating dns glue

[Joe Abley]

Hi Mike,

On 5 Sep 2015, at 0:34, Mike wrote:

 Due to a recent fiber cut in northern california, I've stepped up my 
plan to have one authoritative dns and backup mail exchanger located 
on another network far, far away. I am sadly having immense trouble 
with dotster understanding that I need to update the ip address of a 
glue record, as I host my own stuff,  for which their gui has no 
abillity and which phone support says open a ticket for which the 
e-mailed response was utter cluelessness, claiming they checked and 
it's already set... yeah, you recursed and hit my existing ns which 
gave you the answer, but it's the roots which need to know


Some ideas:

1. You could just add a nameserver. There's no rule that says you have 
to have exactly two. You could almost certainly have three. (There are 
some registry-specific rules that specify the minimum and maximum 
numbers, but I've never seen a registry where the maximum was two.) If 
you add a new nameserver, and leave your existing two as they are, 
you've achieved your diversity goal and avoided the problem you're 
currently struggling with. Apply a touch of mind bleach, and you'll 
forget that "glue records" are even a thing.


2. There's no universal answer to the question "how do I update glue 
records in a parent zone". It depends on the registry, and the data 
model they use to link all the various DNS and meta-DNS information they 
store.


[Incidentally, it's almost never the root server operators that need to 
know unless you're running a top-level domain (and even then, it's the 
administrator of the root zone that needs to know, not the root server 
operators). But when you said "roots" you didn't mean root servers, you 
meant "operator of the registry for the parent zone".]


For registries that follow the data model that was originally used for 
COM, NET and ORG, what you're looking for is a database operation 
"modify host object" to happen at the particular registry that contains 
that host object with addresses (a host object subordinate a the 
registry apex, you could call it, somewhat inelegantly).


Once you've found the right registry, you need to figure out how to make 
changes. Find the sponsoring registrar for the domain the host object is 
subordinate to. That's the organisation you need to talk to.


For example,

  QUIRKAFLEEG.NET

is a domain with the following listed nameservers:

[scallop:~]% whois quirkafleeg.net | egrep '^Name Server: .'
Name Server: NS1.P23.DYNECT.NET
Name Server: NS2.P23.DYNECT.NET
Name Server: NS4.P23.DYNECT.NET
Name Server: NS3.P23.DYNECT.NET
[scallop:~]%

If your whois client needs help in finding out what server to use, try 
Rodney's very handy .whois-servers.net, e.g.


[scallop:~]% host net.whois-servers.net
net.whois-servers.net is an alias for whois.verisign-grs.com.
whois.verisign-grs.com has address 199.7.50.74
whois.verisign-grs.com has IPv6 address 2001:503:5ae2:1000::74
[scallop:~]%

If I decided I wanted to rename NS3.P23.DYNECT.NET, I would need to 
identify the sponsoring registrar for the DYNECT.NET domain name:


[scallop:~]% whois dynect.net | egrep '^Registrar:'
Registrar: DYNAMIC NETWORK SERVICES, INC
[scallop:~]%

The registrant (the person who "owns" the domain) in this case is:

[scallop:~]% whois dynect.net | egrep '^Registrant'
Registrant Name: Dynamic Network Services
Registrant Organization: Dyn
Registrant Street: 150 Dow St, Tower 2
Registrant City: Manchester
Registrant State/Province: NH
Registrant Postal Code: 03101
Registrant Country: US
Registrant Phone: +1.6036684998
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: doma...@dyn.com
[scallop:~]%

So those are the people I would ask to rename (say) NS3.P23.DYNECT.NET. 
Of course in this case they would say "haha, no" and probably advise me 
to add a nameserver rather than trying to reconfigure their commercial 
DNS service. But you get the idea; if the nameserver you want to rename 
is subordinate to a domain name you have administrative control over, 
you could interact with the registrar for the domain and make the 
change.


The precise way a particular registrar will accept such a change varies 
by registrar. Sometimes (I hear) the user interface involves phone calls 
and shouting. But then you have a choice of registrar, if you can figure 
out how to make transfers work.


If your domain and/or nameservers are not named under NET, ORG or COM, 
the above may be useful or, quite possibly, completely irrelevant, 
depending on factors that your registrar is in theory supposed to hide 
from you. There are as many other data models as there are other TLDs, 
almost-maybe, and I certainly don't know the details of all or even many 
of them.


If this is sounding very XKCD-927, that's because it is. This is perhaps 
why lots of people pay others to do this for them (registry/registrar 
shenanigans and DNS hosting) so that they can live their lives with one 
less thing to be angry about.

Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica

[Joe Abley]

Hi Jared,

On 4 Aug 2015, at 12:00, Jared Mauch wrote:

I recommend using DNSDIST to balance traffic at a protocol level as 
you can have implementation diversity on the backside.


I can send an example config out later for people. You can balance to 
bind NSD and others all at the same time :-) just move your SPoF


As someone who once hosted TLD zones in a way that a query to a 
particular nameserver could be answered by either NSD or BIND9, my 
advice would be don't do that. You're setting yourself up for 
troubleshooting hell.


You can include different nameservers in the set for a single zone. 
Using different software for different nameservers can be sensible. 
Using different software for the same nameserver can be a nightmare.



Joe

Re: Exploits start against flaw that could hamstring huge swaths of

[Joe Abley]

On 4 Aug 2015, at 15:54, Barry Shein wrote:


Wow this thread went off-track in nanoseconds.

So which bind versions are ok?


9.10.2-P3 is marked current stable, and 9.9.7-P2 is marked 
current-stable ESV at:


  https://www.isc.org/downloads/

The bind-users is probably a place where this kind of thread would at 
least go off-track in a different set of ways:


  https://lists.isc.org/mailman/listinfo/bind-users


Joe

Re: Route leak in Bangladesh

[Joe Abley]

On 1 Jul 2015, at 11:03, Jared Mauch wrote:


On Wed, Jul 01, 2015 at 03:54:16PM +0100, Nick Hilliard wrote:

On 01/07/2015 15:51, Mark Tinka wrote:
I found RPSL complicated a few years ago, and sort of put that on 
the

back-burner.


you probably want to ignore more rpsl constructs and depend solely on
as-sets, aut-nums and route/route6 objects.  RPSL is not going to 
live up

to your expectations.


Yes, like any technology there are lots of knobs that one could
use but are not recommended.

You just need these few objects and life will be simple.


... as long as the people responsible for maintaining those as-sets 
don't get confused and include lots of other inappropriate as-sets by 
reference, right?


The idea of configuring this stuff from the IRR is great in terms of 
distributing the ops cycles in the right places, but it doesn't help 
with verifying that the end result isn't insane, as I think you and Mike 
have described on this list over the past couple of days.



Joe

Re: Route leak in Bangladesh

[Joe Abley]

On 30 Jun 2015, at 9:41, Job Snijders wrote:

In addition to the BGP community scheme, outbound as-path filters 
could

help.


I agree, but possibly not in the case of a redistribution loop.

(We don't know that's what happened, exactly, but I thought it was worth 
mentioning.)



Joe

Re: World's Fastest Internet™ in Canadaland

[Joe Abley]

On 26 Jun 2015, at 15:04, Hank Disuko wrote:

Bell Canada is apparently gearing up to provide the good people of 
Toronto with the World's Fastest Internet™.

http://www.thestar.com/news/city_hall/2015/06/25/bell-canada-to-give-toronto-worlds-fastest-internet.html


Bell Canada is in the business of defending the current regulatory 
regime from claims that internet speeds are slow, or that investment by 
incumbents in the last mile is lacking, or that it ought to be required 
to share its access network with competitors. Read the press with that 
context in mind.


There's cooperative, rural broadband in the UK [1] that offers 10G 
access to farms at a lower price than Bell charges for some satellite TV 
bundles. I don't think anybody need waste any cycles persuading other 
people here that the fastest internet claims are not aligned precisely 
with the kind reality you find even on this list.



Joe

[1] http://b4rn.org.uk

Re: Anycast provider for SMTP?

[Joe Abley]

On 19 Jun 2015, at 8:12, Christopher Morrow wrote:

On Fri, Jun 19, 2015 at 7:19 AM, James Hartig fastest...@gmail.com 
wrote:



Just curious, how does DNS load balancing work if people are using
8.8.8.8/208.67.222.222 or basically any public resolvers that cache 
and


If the client that performs the upstream query within the 
8.8.8.8/whatever infrastructure is close to you for some meaningful 
interpretation of close then you still get an answer that is 
(effectively) localised for you.


If the resolver infrastructure is sufficiently far that what is good for 
it is not good for you, then the deployed (if not quite standardised) 
answer is edns-client-subnet: the resolver infrastructure you're using 
embeds your client address in its upstream query. The authority servers 
can then localise a response (and scope it) as being suitable for you, 
not the resolver in general.


  http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02

There are privacy concerns, here. But we might posit that you've already 
in the business of trading privacy for convenience if you're using a 
public resolver.



don't know exactly, but you might get some interesting clues from the
f-root or as112 designs, eh?


Root servers and AS112 servers don't steer clients towards content 
according to where they are. They give consistent answers for all 
queries, regardless of where they came from.



Joe

Re: Anycast provider for SMTP?

[Joe Abley]

On 18 Jun 2015, at 7:51, Ray Soucy wrote:

You can certainly do anycast with TCP, and for small stateless 
services it
can be effective.  You can't do anycast for a stateful application 
without

taking the split-brain problem into account.


It's really difficult to apply broad can or can't, works or 
doesn't work advice here since there really are no absolutes. What 
works and what doesn't depends on the intersection between theory and 
practice (including other peoples' networks), and is broader than the 
architectural decision to use or not use anycast.


The text I pasted much earlier from RFC 4786 was a result of a lot of 
discussion (and more than a handful of objections to our attempts to 
answer this question, and to the document as a whole existing at all).


In the general, mathematical sense, it's never safe to use anycast with 
TCP; safe here means entirely safe in all circumstances. Since we 
live on the Internet, we know nowhere is safe, so this answer is 
unsatisfying and doesn't help us make real-world decisions.


In the pragmatic, throw it at the wall and see what sticks sense, it's 
usually fine to use anycast with TCP; usually means things like 
pretty sure I remember this working just fine at my last job and in 
our very particular situation the helpdesk phone didn't seem to ring. 
There's usually very little science attached to this answer, either in 
terms of comprehensive data about failures or in terms of characterising 
the precise environment and considering the ways in which it is similar 
or dissimilar to others.


If anycast is being considered as part of a solution to a particular 
problem, we might consider an answer of the form anycast, when it 
works, is expected to solve that problem; anycast might introduce new 
problems, though, so we also need to think about a fall-back to a 
situation where the old problems are reintroduced but the new ones are 
gone. This kind of fudges around the difficulty in confidently 
enumerating all the new problems with an anticipation that anycast will 
work enough of the time to make it worth using at all.


So, in the example at hand, using an MX RRSet that tries first to 
deliver to an SMTP service that is distributed using anycast but will 
fall back to SMTP service that is not might be a reasonable approach, 
e.g.


$ORIGIN QUIRKAFLEEG.ORG.

@  MX 10 ANY.MX   ; service provided at DEFRA, NLAMS, USIAD, HKHKG
   MX 20 DEFRA.MX ; service provided just at DEFRA
   MX 20 NLAMS.MX ; service provided just at NLAMS
   MX 20 USIAD.MX ; service provided just at USIAD
   MX 20 HKHKG.MX ; service provided just at HKHKG.

so a client will first attempt to deliver to ANY.MX.QUIRKAFLEEG.ORG, and 
if that fails we'll try one of the others.


For this particular question I still think that geoip/dns is a more 
straightforward approach, since it avoids the possible timeout and retry 
behaviour of the client that might delay delivery of mail in the event 
that the anycast MX is unavailable.



Joe

Re: Anycast provider for SMTP?

[Joe Abley]

On 18 Jun 2015, at 15:43, Jonas Björk wrote:

While risking being slightly off topic: Does anyone use anycast dhcp 
servers?

Have you run into any problems considering synching the leases?


Since DHCP uses broadcast and multicast addresses when a client is 
discovering a server, it's not obvious why you'd have to.


You can run redundant sets of isc-dhcpd servers together serving the 
same broadcast domain and have them assign leases from the same address 
pools (at least, I've never tried it, but I was within internal mailing 
list range of the person maintaining that code and heard him shouting 
fairly often about it, not always in tones of rage and frustration).


Was that what you were after?


Joe

Re: Anycast provider for SMTP?

[Joe Abley]

On Jun 17, 2015, at 17:15, Chuck Church chuckchu...@gmail.com wrote:

 As such, you typically only see it leveraged for simple services (e.g. DNS, 
 NTP).

 I've been thinking about this for NTP.  Wouldn't you end up with constant 
 corrections with NTP and Anycast?

I am not a time geek, but the general and consistent advice I have
heard from actual such geeks is, as you suspected, not to use anycast
to distribute NTP service.

I imagine that advice could be modified somewhat if you differentiate
between NTP as used within a mesh of well-synchronised clocks and NTP
as an occasional service for mobile clients that require only a loose
sense of now. The latter seems like availability might be more
important than stability over an extended period, so anycast might
make sense there.


Joe

Re: Anycast provider for SMTP?

[Joe Abley]

Hi Joe,

On 15 Jun 2015, at 13:50, Joe Hamelin wrote:

I have a mail system where there are two MX hosts, one in the US and 
one in

Europe.  Both have a DNS MX record metric of 10 so a bastardized
round-robin takes place.  This does not work so well when one site 
goes

down.   My solution will be to place a load balancer in a hosting site
(virtual, of course) and have it provide HA.  But what about HA for 
the
LB?  At first glance anycasting would seem to be a great idea but 
there is

a problem of broken sessions when routes change.

Have any of you seen something like this work in the wild?


If you can give responses to QTYPE=MX queries that match the location of 
the client, you can approximate this without deploying your SMTP servers 
using anycast. This feels like a simpler solution to operate; anycast 
sometimes pits BGP-fearing, syseng people against neteng people when 
things break at 3am, and if that rings true for you then a solution that 
avoids it might be of interest.


So, suppose clients in region A could query NETHEAD.COM/IN/MX and get a 
response that looks like


  NETHEAD.COM. IN MX 10 REGION-A-MX.NETHEAD.COM.
   IN MX 20 REGION-B-MX.NETHEAD.COM.
   IN MX 20 REGION-C-MX.NETHEAD.COM.

whereas clients in region B might see a response that looks more 
sensible to them:


  NETHEAD.COM. IN MX 10 REGION-B-MX.NETHEAD.COM.
   IN MX 20 REGION-A-MX.NETHEAD.COM.
   IN MX 20 REGION-C-MX.NETHEAD.COM.

etc, etc.

That way you still get a reasonable fallback in the event that one MX 
target is unreachable for a particular client, but you steer the bulk of 
your traffic in a way that makes sense (and which your syseng people 
don't have to understand the details of).


You can achieve the above DNS trickery using various load balancers that 
other people in this thread have already mentioned. You can also install 
your own geomaps in your own nameservers and handle it yourself, or you 
can buy managed DNS service from various people that can do this kind of 
thing.


Disclaimer: Dyn, for whom I work, sells such a service.


Joe

Re: Anycast provider for SMTP?

[Joe Abley]

On 15 Jun 2015, at 15:05, Dave Taht wrote:


I have been using anycast at a small scale on mesh networks, for dns,
primarily. Works.


Many of us have been using anycast at Internet scale for DNS for a 
couple of decades. I would go further than works and perhaps say 
necessary.


There were some wise words written in RFC 4786 about use of anycast with 
other protocols (well, I think they are wise, but then I wrote some of 
them):


   When a service is anycast between two or more nodes, the routing
   system makes the node selection decision on behalf of a client.
   Since it is usually a requirement that a single client-server
   interaction is carried out between a client and the same server node
   for the duration of the transaction, it follows that the routing
   system's node selection decision ought to be stable for 
substantially

   longer than the expected transaction time, if the service is to be
   provided reliably.

   Some services have very short transaction times, and may even be
   carried out using a single packet request and a single packet reply
   (e.g., DNS transactions over UDP transport).  Other services involve
   far longer-lived transactions (e.g., bulk file downloads and audio-
   visual media streaming).

   Services may be anycast within very predictable routing systems,
   which can remain stable for long periods of time (e.g., anycast
   within a well-managed and topologically-simple IGP, where node
   selection changes only occur as a response to node failures).  Other
   deployments have far less predictable characteristics (see
   Section 4.4.7).

   The stability of the routing system, together with the transaction
   time of the service, should be carefully compared when deciding
   whether a service is suitable for distribution using anycast.  In
   some cases, for new protocols, it may be practical to split large
   transactions into an initialisation phase that is handled by anycast
   servers, and a sustained phase that is provided by non-anycast
   servers, perhaps chosen during the initialisation phase.

   This document deliberately avoids prescribing rules as to which
   protocols or services are suitable for distribution by anycast; to
   attempt to do so would be presumptuous.

   Operators should be aware that, especially for long running flows,
   there are potential failure modes using anycast that are more 
complex

   than a simple 'destination unreachable' failure using unicast.


Joe

Re: most accurate geo-IP source to build country-based access lists

[Joe Abley]

On 9 Jun 2015, at 5:11, Martin T wrote:


At a brute force country level it is possible to use the Delegated
ranges lists but that runs into the problem where IP ranges are
subnetted and allocated to other countries.


Yeah.


I would say that a perfectly accurate mapping of address to anything 
geographical (with more accuracy than it's within the observed 
universe, somewhere) is unlikely ever to exist, except by accident and 
for short periods of time. Accuracy and lack of authoritative sources of 
data is one reason, constant uncoordinated reconfiguration is another. 
You need to decide how accurate your mapping needs to be (and figure out 
how to measure that, if accuracy is important).


Another part of the problem is framing the question in a useful way: a 
universal solution seems intractable when the following questions are 
answered differently (but accurately) by different people who have 
different needs.


Is a device in Uganda connected via satphone to a router in France in 
Uganda, or France?


Is a network in Fiji that can't talk to any other networks in Fiji 
without leaving the island but is one layer-3 hop away from Australia in 
Fiji, or Australia?


Does the source address of a packet always identify the device that sent 
the packet?


If I'm in region A and you're in region A, and you route within region 
to me but my replies leave the region on the way back, are we in the 
same region from my perspective? How about yours?


Even: if I'm in region A but I'm using a DNS resolver in region B, am I 
in region A or region B?



Joe

Re: Looking for information on IGP choices in dual-stack networks

[Joe Abley]

On 9 Jun 2015, at 16:23, Christopher Morrow wrote:

 On Tue, Jun 9, 2015 at 3:21 PM, Randy Bush ra...@psg.com wrote:
 If you have a production dual-stack network, then we would like to know
 which IGP you use to route IPv4 and which you use to route IPv6.

 in one network, both ospfs.  in another is-is.  i recommend the latter.

 We would also like to know roughly how many routers are running this
 combination.

 why is the question /routers/ and not /networks/ ?

Routers makes more sense to me than networks (IGP, so one network, right?)


Joe

Re: Looking for information on IGP choices in dual-stack networks

[Joe Abley]

Hi Randy,

On Jun 9, 2015, at 18:08, Randy Bush ra...@psg.com wrote:

 Routers makes more sense to me than networks (IGP, so one network,
 right?)

 so you are thinking of a network where half the routers run is-is one
 quarter ospf/ospfv2 and one quarter ospf/ripv3.  right.

No, not at all. I thought Victor was asking what IGP and how many
routers use it in your network. I assumed he was interested in
whether the size of the network influenced the IGP choice.

Perhaps I misunderstood, because apparently I was the only one who
read it that way.


Joe

Re: gmail security is a joke

[Joe Abley]

On 28 May 2015, at 22:18, Rich Kulawiec wrote:


On Thu, May 28, 2015 at 03:13:37PM -0400, William Herrin wrote:

My first dog's name was a random and unpronounceable 30-character 
string.


I think this (Bill's) is a very good practice.


That's what I should do. Instead, I pull down the list of candidate 
questions and think to myself...


 - I didn't go to a high school
 - I don't understand this other high school reference
 - I don't watch sports
 - I don't have a favourite sports team
 - I wonder vaguely whether that question actually had anything to do 
with sports

 - I don't have a favourite pet
 - I don't know my grandmother's middle name, and never did
 - I don't have a favourite colour
 - I've never owned a dog
 - Are pets ever really owned?
 - Doesn't that speak to the denegration of others based on species?
 - Aren't we against that?

and around this point, I start to think

 - I've had enough of this
 - this is too hard
 - I don't even remember what I am signing up for at this point
 - I am going to look for amusing cats on youtube


Joe

Re: gmail security is a joke

[Joe Abley]

On 27 May 2015, at 13:19, Owen DeLong wrote:

If someone has the ability to hijack your BGP, then you’ve got 
bigger problems than

having them take over your Gmail account.


Could we perhaps summarise this entire thread with if you have tighter 
security requirements for your e-mail than a particular e-mail provider 
can give you, host your e-mail somewhere else?


Also, if you get a stabbing pain in your eye every time you drink tea, 
take the spoon out of the cup.



Joe

Re: Measuring DNS Performance Graphing Logs

[Joe Abley]

Hi Zayed,

I think you're more likely to get good answers to your BIND-specific 
questions on the bind-users mailing list. See:


  https://lists.isc.org/mailman/listinfo/bind-users

BIND9 has the capability to produce a vast variety and volume of logs, 
and dealing with logs in general is something that there are solutions 
for. Maybe look at logstash/elasticsearch as a starting point. Other 
BIND9 users on the bind-users list will no doubt have advice about what 
types logs they think are important.


Recent releases of BIND9 can export a variety of statistics in XML and 
JSON formats using HTTP. Pulling those out and sending them to 
cacti/graphite/whatever is also a fairly non-DNS-specific problem to 
have.


Advice for tuning a BIND9 recursive resolver's cache can be found in a 
tech note published by ISC; if that's not especially relevant to modern 
releases (I seem to think it was published some time ago) you could 
again look to the bind-users list for advice. For authority-only 
servers, your main concern is whether you have enough RAM to hold all 
your zone data. If you do, and if your server was built this decade and 
has no hardware faults, chances are you're good.


Deciding whether your servers struggling to keep up with the load of the 
software you're running on it is another problem that is not specific to 
the DNS. Check with whoever provides your operating system for advice; 
look in to system statistics collection using things like collectd and 
publish somewhere you can record data and identify long-term trends so 
you know what looks normal (since until you know what normal looks like, 
you can't tell what a problem looks like).


You can use commercial services like catchpoint and thousandeyes to 
check that your authoritative nameservers are suitably responsive. You 
can use non-commercial services like Atlas to do the same thing.


If you've connected your nameservers to the network in such a way that 
there's a stateful firewall between the server and its clients, the 
report to your boss could be very brief and accurate; something like 
service expected to fail at any time; explosion imminent would do it.



Joe

On 21 May 2015, at 7:15, Zayed Mahmud wrote:

Thanks a lot to Denis Fondras, Zachary, Andrew Smith, Christopher 
Morrow

for your valuable advice.

I've tried cacti but failed to get desired logs. i've also tried bind
graph...but it consumes too much memory in the long run.

can u suggest some suitable tools that i can measure the performance 
of the
dns servers? like what shud b active and what shud not be in general 
safe
dns server practice and check against my own settings or whatever the 
tool
can query, something like nmap. this would be really helpful. i just 
need
to make a report about my dns servers for my boss...and i'm clueless 
what

to point out and what not to or how to evaluate it's performance. i'm
running bind9 under unix environment.

thanks in advance.

On Tue, May 19, 2015 at 11:34 PM, Zayed Mahmud 
zayed.mah...@gmail.com

wrote:


Hello!
This is my first message to NANOG's mailing list. I hope someone can 
help

me.

I was wondering which tool(s) can I use to measure the performance of 
my 3
DNS servers (1 primary, 1 secondary, 1 solely cacheDNS)? From the 
stats I
would like to know if my DNS server is serving as it should be or if 
any of

it's options are set inappropriately and others alike.

I looked for a while but could not find any. Any help would be highly
appreciated. I am running bind9 on UNIX platform.

Question 2) I would also like to know how can I graph my DNS logs? 
And how
can I integrate it to my CACTI server as well? I couldn't find any 
suitable

plugin. Any suggestion?

--

--
Best Regards,

*Zayed Mahmud*

*Senior Core  IP Network Team,*

*Banglalion Communications Limited, Bangladesh.*





--

--
Best Regards,
*Zayed Mahmud.*

Re: ASN Domain for rDNS

[Joe Abley]

On 9 Dec 2014, at 19:30, Keefe John keefe...@ethoplex.com wrote:

 I've been seeing more and more carriers(and even small ISPs) using as.net 
 as their domain for rDNS on IP space.  What are the pros and cons for doing 
 this versus using your primary business domain name?

When you are forced to change your name because of chapter 11, acquisition, 
rebranding, trademark challenge or a sudden need to distance yourself from 
previous senior management and their intense hatred of all customers, it's nice 
not to have to change all your reverse DNS.


Joe

Re: Anyone running Knot?

[Joe Abley]

Hi Jay,

On 6 August 2014 at 23:26:36, Jay Ashworth (j...@baylink.com) wrote:

 LWN this week covers the Knot DNS server, written by/for the .cz root zone 
 ops, which can,  
 amongst other interesting attributes, load the entire 35 million record .net 
 zone in  
 10 seconds.

https://www.knot-dns.cz

Knot was written by people at CZ.NIC Labs, as far as I know. When I was at 
ICANN we were interested in using it for L-Root, but I don't know that that has 
happened. The team is really, really good. I routinely suffer jawcraig [1] at 
their apparently outrageous productivity.

 Is anybody here using it? Or knows of it being used somewhere they're 
 permitted to discuss?  
 Is it suitable for running on... much smaller zones? or does the optimization 
 make it  
 impractical?

There's a mailing list:

   knot-dns-us...@lists.nic.cz


Joe

[1] http://tmoliff.blogspot.co.nz/2011/04/jawcraig-n-medical.html

Re: rz.verisign-grs.com root zone ftp access

[Joe Abley]

On 28 May 2014, at 3:21, Martin Hannigan hanni...@gmail.com wrote:

 IIRC you can ftp to rs.internic.net (the IANA) and download zones to your
 hearts content. At least until transition, I'd think this one is
 authoritative.
 
 I don't exactly remember where you can pull it from, but I believe they
 offer it in XML too.
 
 [ Paging Joe Abley ]

*twitch*

Half of this thread seems to be talking about the COM/NET zones, not the root 
zone, but since you asked...

ftp://ftp.internic.net/domain/root.zone is a service provided by ICANN.

ftp://rs.internic.net/domain/root.zone is a service provided by Verisign.

I think both services are provided under their respective agreements with NTIA 
(the IANA Functions Contract and the Cooperative Agreement) and hence those 
URLs can be expected to be somewhat stable. (We live in interesting times, but 
I don't sense a desire by anybody to change the IANA Functions as part of the 
management transition currently under discussion). I don't remember the details 
of how the two sites above are provisioned, but I have a feeling that one is 
mirrored from the other.

Right now, from here, B-Root, C-Root, F-Root, G-Root, and K-Root respond 
positively to AXFR requests. Sending AXFR requests to instances of root servers 
is a bit unfriendly, in my opinion, since you're occupying TCP slots on 
nameservers that arguably would be better used for non-AXFR queries using TCP 
transport.

As Mehmet mentioned, xfr.cjr.dns.icann.org and xfr.lax.dns.icann.org are both 
dedicated AXFR servers from which the root zone (and other zones served by 
ICANN's DNS Operations department) can be retrieved. I am not aware of any 
commitment or requirement to provide those services, but I can't imagine the 
good people currently in that ICANN department would make them unavailable 
gratuitously.

Lastly, the root zone is signed with NSEC, which means you can walk the NSEC 
chain and recover the complete zone (see below, thanks Jelte). It occurs to me 
that this is actually a plausible way to prime your resolver with the full 
contents of the root zone, as an alternative to slaving the root zone, for 
people who think this kind of obsessive behaviour is useful. But maybe that's 
just the malarone talking.

I am not aware of anybody providing the contents of the root zone in XML format 
(and I'm not sure what value that would have to anybody). You may have been 
remembering the root zone trust anchor distribution format, as seen at 
http://data.iana.org/root-anchors/root-anchors.xml.


Joe

[walrus:~]% ldns-walk -f . | head -40
.   218447  IN  NS  i.root-servers.net.
.   218447  IN  NS  h.root-servers.net.
.   218447  IN  NS  m.root-servers.net.
.   218447  IN  NS  l.root-servers.net.
.   218447  IN  NS  j.root-servers.net.
.   218447  IN  NS  e.root-servers.net.
.   218447  IN  NS  d.root-servers.net.
.   218447  IN  NS  b.root-servers.net.
.   218447  IN  NS  f.root-servers.net.
.   218447  IN  NS  k.root-servers.net.
.   218447  IN  NS  g.root-servers.net.
.   218447  IN  NS  c.root-servers.net.
.   218447  IN  NS  a.root-servers.net.
.   487056  IN  RRSIG   NS 8 0 518400 2014060300 2014052623 
40926 . 
gsG1xrmc32HKMscG4pEQjgTNg2UOKgXTEZEGjg5lY9X14ADCwNleAwfNXkeAS2cEEJI+Sj8P4gWvKCpgCi7rKSMVPapfelN8huMZHiplWsl0JyaHxkU6WwAa2ciBIayGuY7vsPY2LGudosN4th+5eXnB0gfIJFCuQjhaK3dI5iM=
.   86309   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 
2014052701 1800 900 604800 86400
.   86309   IN  RRSIG   SOA 8 0 86400 2014060300 2014052623 
40926 . 
JZPdfvMZq/+k+ScgnPVp02j6PSYnA5ntR4TGiLHoeeLTWty7OY3ATas48mCxRZja8D/44VKV5COiXb3dNJNRnXtGqI1nuTWwGXmK/J52satKzLilkk/NtHjy1MxT1NQmgnPYFKNP4liE3vr0deTUYCPRkjDwveTCJ/NowB1OyWs=
.   45819   IN  DNSKEY  257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
 ;{id = 19036 (ksk), size = 2048b}
.   45819   IN  DNSKEY  256 3 8 
AwEAAZvJd8ORk+jmZ41QMYbQ1XCpf60l6YJuHtnxn0VSh5a5vqwEjTST3/PZ4xhUFu2YcTfRNWxs9WTiGZl3MY/UlBIvzpLhKgKnf9Vk8sEU3q0nmOGFgE6jTi/cU95ATU/2dTQovMDv9XyWvrmj8KIG2brj6mF4S8GTae6G2GwbMF5v
 ;{id = 40926 (zsk), size = 1024b}
.   45819   IN  RRSIG   DNSKEY 8 0 172800 20140604235959 2014052100 
19036 . 
H6fUqoXYqDtYeDOZxBxBEXWsQ1APR6+MMboI74uSgdIkcm5B2zBQOwD+lYid1j3JJ1vhzONwk4PP31o1RG24P0iMqhwwaGXtoWLDeH3FSQxuVUdLA3DxIM0c8NdEzgCW36iH8zzcy/uzFwgPvw6/ksbd6Np+nu/bIw38XhGH61fkidahj1lTAUDIMXi4TM7igJ9bZgUtLViXN8sLeD4G+hrPZbydcksvZpVB8XFCvgKrHHMq3Ha7AO6cl2XDrn6/DodibcVBpMK07kL24NEVFre/jeqjiQWCms6GDuGkqRKaUf8Hdwl12rsmptIuDa70qNh3Pz+pbjNXXGuWlkyYdA

Re: New Zealand Spy Agency To Vet Network Builds, Provider Staff

[Joe Abley]

On 13 May 2014, at 15:49, Paul Ferguson fergdawgs...@mykolab.com wrote:

 So is there just reluctant acceptance of this law, or is there
 push-back and plans to repeal, or...?

This was news to me when I heard about it the other day (because apparently I 
am a bad kiwi and do not keep myself informed), but it does sound like the 
conversation at NZNOG resulted in an exception list that makes the general idea 
at least a little more practical, if not palatable. See

  http://ncsc.govt.nz/assets/TICSA/NCSC-Guidance-for-Network-Operators.pdf
  http://ncsc.govt.nz/assets/TICSA/Notice-of-Exemptions.pdf

The recent NZNOG discussion is hereabouts:

  http://list.waikato.ac.nz/pipermail/nznog/2014-May/020802.html


Joe

real-world data about fragmentation

[Joe Abley]

Hi all,

It's common wisdom that a datagram that needs to be fragmented between 
endpoints (because it is bigger than the path MTU) will demonstrate less 
reliable delivery and reassembly than a datagram that doesn't need to be 
fragmented, because math, firewall, other, take your pick.

Is anybody aware of any wide-scale studies that examine the probability of 
fragmentation of datagrams of different sizes?

For example, I could reasonable expect an IPv4 packet of 576 bytes not to be 
fragmented very often (to choose a size not at random). The probability of a 
10,000 octet IPv4 packet getting fragmented seems likely to be 100%, if we're 
talking about arbitrary paths across the Internet.

What does the curve look like between 576 bytes and 10,000 bytes?

I might expect exciting curve action around 1500 bytes (because ethernet), 1492 
(PPPoE), 1480 (GRE), etc. But I'm interested in actual data.

Anybody have any pointers? IPv4 and IPv6 are both interesting.


Joe

Re: [dns-wg] Global Vs local node data in www.root-servers.org

[Joe Abley]

On 17 Mar 2014, at 7:39, John Bond john.b...@icann.org wrote:

 Global and Local nodes are very loosely defined terms.  However general
 consensus of a local node is one that has a desired routing policy which
 does not allow the service supernets to propagate globally.  As we impose
 no policy we mark all nodes as global.

I think the taxonomy is probably my fault. At least, I thought I invented it 
when I wrote

  http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt

the pertinent text of which is this:

   Two classes of node are described in this document:

   Global Nodes advertise their service supernets such that they are
  propagated globally through the routing system (i.e. they
  advertise them for transit), and hence potentially provide service
  for the entire Internet.

   Local Nodes advertise their service supernets such that the radius of
  propagation in the routing system is limited, and hence provide
  service for a contained local catchment area.

   Global Nodes provide a baseline degree of proximity to the entire
   Internet. Multiple global nodes are deployed to ensure that the
   general availability of the service does not rely on the availability
   or reachability of a single global node.

   Local Nodes provide contained regions of optimisation. Clients within
   the catchment area of a local node may have their queries serviced by
   a Local Node, rather than one of the Global Nodes.

The operational considerations that you mention would have been great for me to 
think about when I wrote that text (i.e. it's the intention of the originator 
of the route that's important, not the practical limit to propagation of the 
route due to the policies of other networks).

We did a slightly better job in RFC 4768 (e.g. in such a way, potentially):

   Local-Scope Anycast:  reachability information for the anycast
  Service Address is propagated through a routing system in such a
  way that a particular anycast node is only visible to a subset of
  the whole routing system.

   Local Node:  an Anycast Node providing service using a Local-Scope
  Anycast Address.

   Global-Scope Anycast:  reachability information for the anycast
  Service Address is propagated through a routing system in such a
  way that a particular anycast node is potentially visible to the
  whole routing system.

   Global Node:  an Anycast Node providing service using a Global-Scope
  Anycast Address.


Joe


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [dns-wg] Global Vs local node data in www.root-servers.org

[Joe Abley]

On 17 Mar 2014, at 10:27, manning bill bmann...@isi.edu wrote:

 alas, our service predates Joe’s marvelous text.
 
 “B” provides its services locally to its upstream ISPs.
 We don’t play routing tricks, impose routing policy, or attempt to 
 influence prefix announcement.

In the taxonomy I just shared, that makes the origin nodes of B all global 
nodes.

To clarify though, I certainly wasn't trying to suggest that the things I 
described were new or original when I was writing in 2003. Anycast had already 
been in use for quite some time by a variety of people at that time.

It's specifically the terms local and global in a DNS anycast context that 
I was apologising for :-)


Joe

Re: Managing IOS Configuration Snippets

[Joe Abley]

On 27 Feb 2014, at 12:46, Erik Muller er...@buh.org wrote:

 On 2/27/14, 12:21 , Suresh Ramasubramanian wrote:
 This has been around for several years now -
 http://sourceforge.net/projects/cisco-conf-rep/
 
 But that's just archiving, like rancid, right?

This is not any kind of sensible answer to the original question, but the 
general approach “give ops people a shell on a box with a rancid repository, 
encourage them to write scripts that do stuff” has the potential to cause all 
kinds of good things to happen faster than the time taken to organise a 
conference call to discuss requirements gathering for a “production” system.

Examples, as ever:

  http://www.nanog.org/meetings/nanog26/presentations/stephen.pdf
  ftp://ftp.isc.org/isc/toolmakers/

(It’s not pretty. But it’s not supposed to be pretty.)


Joe

Re: Internet Routing Registries - RADb, etc

[Joe Abley]

On 2014-01-16, at 18:21, Jeroen Massar jer...@massar.ch wrote:

 On 2014-01-16 23:11, Nick Hilliard wrote:
 On 16/01/2014 21:22, Jon Lewis wrote:
 Also, at least of the ones I've dealt with, there is no verification of
 records as they're entered.
 
 on the RIPE IRRDB, there is validation, so you can't just go in and
 register route: objects for someone else's allocations or assignments.
 
 You mean auth for RIPE region prefixes, as one can also register
 ARIN/APNIC/etc prefixes in the RIPEdb and then, there is no auth (but a
 mail to d...@ripe.net resolves any issues quite quickly if something fake
 is there)

Yep. For someone with non-RIPE NCC numbers the only manual part of the process 
is getting a maintainer object created. Once you've done that it's likely that 
your new parent route object in the RIPE db will be something like this:

inetnum:199.91.32.0 - 199.255.255.255
netname:NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK
descr:  IPv4 address block not managed by the RIPE NCC
remarks:--
remarks:
remarks:Networks in this range are not in use in
remarks:the RIPE NCC service region.
remarks:
remarks:You can find the whois server to query, or the
remarks:IANA registry to query on this web page:
remarks:http://www.iana.org/assignments/ipv4-address-space
remarks:
remarks:You can access databases of other RIR's at:
remarks:
remarks:AFRINIC (Africa)
remarks:http://www.afrinic.net/ whois.afrinic.net
remarks:
remarks:APNIC (Asia Pacific)
remarks:http://www.apnic.net/ whois.apnic.net
remarks:
remarks:ARIN (Northern America)
remarks:http://www.arin.net/  whois.arin.net
remarks:
remarks:LACNIC (Latin America and the Carribean)
remarks:http://www.lacnic.net/ whois.lacnic.net
remarks:
remarks:--

which includes

mnt-routes: RIPE-NCC-RPSL-MNT

corresponding to

mntner: RIPE-NCC-RPSL-MNT
descr:  This maintainer may be used to create objects to represent
descr:  routing policy in the RIPE Database for number resources not
descr:  allocated or assigned from the RIPE NCC.
admin-c:RD132-RIPE
auth:   MD5-PW # Filtered
remarks:***
remarks:* The password for this object is 'RPSL', without the *
remarks:* quotes. Do NOT use this maintainer as 'mnt-by'. *
remarks:***
mnt-by: RIPE-DBM-MNT
referral-by:RIPE-DBM-MNT
source: RIPE # Filtered


Joe


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: best practice for advertising peering fabric routes

[Joe Abley]

On 2014-01-15, at 12:04, Jim Shankland na...@shankland.org wrote:

 On 1/14/14, 8:41 PM, Patrick W. Gilmore wrote:
 I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static 
 route. An IXP LAN should not be reachable from any device except those 
 directly attached to that LAN. Period.
 
 So ... RFC1918 addresses for the IXP fabric, then?

I've heard apparently non-drunk people suggest IPv6 link-local addresses as BGP 
endpoints across exchanges, too.

 (Half kidding, but still )

RFC 6752.

One observation on this thread: some networks have customers who react badly to 
unusual things seen in traceroute. Sometimes the margin on an individual 
customer is low enough that one support call displaces any profit you were 
going to make off them this month.

It's understandable to me that such network operators would choose to carry IXP 
routes internally in order to avoid that potential support burden.

I don't pretend to have any universal good/bad answer to the original question, 
though. I don't think the world is that simple.


Joe


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: BGP neighbor/configuration testing

[Joe Abley]

On 2013-11-20, at 14:53, Eric A Louie elo...@yahoo.com wrote:

 Scenario: a regional ISP preparing to cutover to a new upstream BGP provider 
 at one of my POPs.  Want minimal or no network disruption, and want to ensure 
 everything is ready to go prior to the cutover.
 
  I'm planning to use the following order of operations:
 1. Establish IP connectivity to the new ISP (already done)
 2. Configure my BGP router and shutdown the new neighbor (ISP says their side 
 is already configured and ready)

Leave the adjacency up, and just deny all inbound and outbound on the 
corresponding route filter. You never want a maintenance's success to depend on 
no neigh x.x.x.x shut working smoothly; much better to be able to confirm 
that the session is up before you start and just change the import/export 
policy.

 3. During the maintenance window for this change, activate the new BGP 
 connection (remove neighbor shutdown)
 4. Do the appropriate tests (sh bgp nei, login to my upstream's route server 
 and check route advertisements, sign in to looking glass and/or route servers 
 from other providers to see if my routes from the new ISP are being 
 advertised, and I'm open to any other tests)

You could insert wait N days here, with a rollback plan (e.g. in case of 
customer-enraging congestion or packet loss) that restores the original 
configuration by shutting down the new adjacency.

 5. Turn down the old connection (neighbor shutdown)
 6. Watch the old connection get removed from route servers/looking glasses 
 from step 4
 
 A. Does that order make sense or does it need some tweaking, additions, or 
 other?
 
 B. I'd like to test the new upstream BGP configuration without passing 
 traffic to and through it.  What can I do (if anything) on my configuration 
 end to put up the BGP configuration, establish a neighbor connection, and NOT 
 actually pass any traffic through it?  After putting my configuration up, I'd 
 like to do a show bgp nei 1.1.1.1 advertised-routes to ensure my routes are 
 going out, and then shut the neighbor down until the cutover.

Bring the session up with deny all in both directions, and use the appropriate 
show commands (show neigh ... received-routes since you're talking cisco) to 
show what routes were received upstream of the filter. You are presumably 
already testing your export policy on your live session; if the configuration 
on the new session is the same, then you're really just talking about making 
sure that the internal route set visible on the router with the new session is 
right.


Joe


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Cogent IPV6 connectivity to fireball.acr.fi

[Joe Abley]

 On Nov 3, 2013, at 15:38, Clinton Work clin...@scripty.com wrote:

 I can reach fireball.acr.fi on TCP port 80 so it looks like Cogent is
 just filtering or dropping IPV6 traceroute packets.

Traceroute packets is extremely vague. As a general rule, if you
want to discover a complete path between endpoints that are expected
to communicate using 80/tcp, trace the route using 80/tcp.

(Not that it's ever expected to see protocol-specific drops in a core
or across a transit or peering edge.)


Joe

Re: Reverse DNS RFCs and Recommendations

[Joe Abley]

On Oct 30, 2013, at 17:34, Nolan Rollo nro...@kw-corp.com wrote:

 So in the four examples below, 3 of them preface the IP with an alpha 
 character. Charter however, starts the rDNS off with a number. I'm not 
 arguing with anyone but what potential problems could that cause with DNS?

None.

 I'm also thinking of the famous  www.1and1.com, where the number 1 starts 
 off one of the sections.

Which is fine.


Joe

Re: ipv6 and geolocation

[Joe Abley]

On 2013-10-22, at 15:16, Blair Trosper blair.tros...@gmail.com wrote:

 Everyone loves IPv6, and it's a fantastic technology.  However, I've been
 pondering a few quirks of v6, including the low priority of PTR,

Not sure what that means, but...

 but I have a question I want to throw out there:
 
 Do you think IPv6 geolocatoin (GeoIP) will ever be viable?

To me it seems like an easier problem to solve than IPv4. There's no historical 
assignment swamp. Subnets are of fixed size. Many/most organisations who 
receive a direct assignment will never need a second.

 If so, when do you think this will happen?

As soon as enough people using geo-located services start doing so over v6.


Joe

Re: Need understand...

[Joe Abley]

On 2013-10-21, at 10:31, Randy Bush ra...@psg.com wrote:

 feeling a little st00pid here.

The crsnic servers return hostname matches as well as domain matches, an 
enduring source of confusion for many years.

You can make the server show all records that match using =. There's other 
stuff, whois -h whois.crsnic.net help for more.

By default, the server your whois client is using depends on the client. Some 
of the code I once wrote for OpenBSD's /usr/bin/whois has survived there and 
has insinuated itself into other platforms; if your whois is similar then it's 
using Ultra's whois-servers.net collection (so it's looking up 
com.whois-servers.net and finding whois.verisign-grs.com. That's a different 
server from whois.crsnic.net (at least, it has a different address). It's all a 
bit of a mess.


Joe

[krill:~]% whois -h whois.crsnic.net '=facebook.com'

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Server Name: FACEBOOK.COM.Z.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
   IP Address: 69.41.185.229
   Registrar: TUCOWS DOMAINS INC.
   Whois Server: whois.tucows.com
   Referral URL: http://domainhelp.opensrs.net

   Server Name: FACEBOOK.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM
   IP Address: 203.36.226.2
   Registrar: INSTRA CORPORATION PTY, LTD.
   Whois Server: whois.instra.net
   Referral URL: http://www.instra.com

   Server Name: FACEBOOK.COM.LOVED.BY.WWW.SHQIPHOST.COM
   IP Address: 46.4.210.254
   Registrar: ONLINENIC, INC.
   Whois Server: whois.onlinenic.com
   Referral URL: http://www.OnlineNIC.com

   Server Name: FACEBOOK.COM.KNOWS.THAT.THE.BEST.WEB.HOSTING.IS.NASHHOST.NET
   IP Address: 78.47.16.44
   Registrar: CENTER OF UKRAINIAN INTERNET NAMES
   Whois Server: whois.ukrnames.com
   Referral URL: http://www.ukrnames.com

   Server Name: FACEBOOK.COM.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM
   IP Address: 209.126.190.70
   Registrar: PDR LTD. D/B/A PUBLICDOMAINREGISTRY.COM
   Whois Server: whois.PublicDomainRegistry.com
   Referral URL: http://www.PublicDomainRegistry.com

   Server Name: 
FACEBOOK.COM.DISABLE.YOUR.TIMELINE.NOW.WITH.THE.ORIGINAL.TIMELINE-REMOVE.NET
   IP Address: 8.8.8.8
   Registrar: ENOM, INC.
   Whois Server: whois.enom.com
   Referral URL: http://www.enom.com

   Domain Name: FACEBOOK.COM
   Registrar: MARKMONITOR INC.
   Whois Server: whois.markmonitor.com
   Referral URL: http://www.markmonitor.com
   Name Server: A.NS.FACEBOOK.COM
   Name Server: B.NS.FACEBOOK.COM
   Status: clientDeleteProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Status: serverDeleteProhibited
   Status: serverTransferProhibited
   Status: serverUpdateProhibited
   Updated Date: 28-sep-2012
   Creation Date: 29-mar-1997
   Expiration Date: 30-mar-2020

 Last update of whois database: Mon, 21 Oct 2013 14:37:21 UTC 

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar.  Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' (VeriSign) Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability.  VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to 

Re: clear forwarding route

[Joe Abley]

On 2013-10-18, at 11:40, Manav Bhatia manavbha...@gmail.com wrote:

 I would like understand the circumstances under which an operator may want
 to clear all (or a subset of) the routes programmed in the forwarding table
 (FIB).

Because of bugs which have led to the FIB containing data that doesn't match 
the RIB, and which is causing customer enragement. They don't call it CEF for 
nothing.

 I believe the command to do this on Cisco is
 
 clear forwarding {ipv4 | ipv6} route {* | prefix} [vrf vrf-name] module
 {slot| all}

Cool. Back when I was chasing packets at 6461 the best we could do was

router(config)# interface blah
router(config-if)# shutdown
router(config-if)# no shutdown

 I ask this since doing this would result in the router dropping all transit
 traffic till the routes get reprogrammed in the FIB.

Seems likely!

 Why would somebody ever want to do this?

Screaming customer on the phone.


Joe

Re: comcast ipv6 PTR

[Joe Abley]

On 2013-10-09, at 10:10, Chris Adams c...@cmadams.net wrote:

 Once upon a time, Blair Trosper blair.tros...@gmail.com said:
 True, but the location information, at least the state, is quasi-helpful.
 
 That's another good reason to have reverse records for defined router
 interfaces.  Auto-generated reverse for eveything doesn't give any
 useful info though.

If people really want to use generic reverse names and have realised that the 
v6 address space is much too big for $GENERATE, one approach is to delegate the 
appropriate zones to a custom nameserver that can auto-generate PTRs on demand. 
There are scaling problems here, but probably nothing that can't be fixed with 
high TTLs and multiple nameservers.

If I was doing that, my instinct would be to code against Ray Bellis' evldns 
(see http://code.google.com/p/evldns/).

Note that I'm not suggesting that auto-generated v6 PTRs (or v4 PTRs) are a 
good idea. But I'm aware that a lack of reverse DNS on either protocol can make 
the helpdesk phone ring, so there is certainly a pragmatic argument in favour 
of it.


Joe

Re: NANOG 59 - Monday presentations on YouTube

[Joe Abley]

On 2013-10-09, at 18:04, Mehmet Akcin meh...@akcin.net wrote:

 On Oct 9, 2013, at 3:03 PM, Martin Hannigan hanni...@gmail.com wrote:
 
 Yes, very awesome!
 
 Wanted to take a quick moment to thank Sylvie, Betty and rest of the
 outgoing (past included) Board members for a job well done. So far has
 NANOG come and in such a short time. Great work everyone.
 
 Best,
 
 -M
 
 +1 excellent job.

I'd also like to thank the members for voting in much greater numbers than are 
normally seen, and for having the good sense to elect three new board members 
that I'm sure will do a better job than I would have done!

This all adds up to a good result for NANOG. I like it.


Joe

Re: NANOG 59 - Monday presentations on YouTube

[Joe Abley]

On 2013-10-09, at 18:35, Shrdlu shr...@deaddrop.org wrote:

 On 10/9/2013 6:14 PM, Joe Abley wrote:
 
 I'd also like to thank the members for voting in much greater
 numbers than are normally seen, and for having the good sense to
 elect three new board members that I'm sure will do a better job than
 I would have done!
 
 *I* voted for you. Maybe I should have voted more than once?
 
 I'm hoping that the pages will be updated soon with the results:
 
 http://www.nanog.org/elections/2013/results
 
 It really seems that NANOG is well on the way to becoming a going
 concern. I may actually make the trek to Bellevue (which has the
 virtue of being closer to home).

This probably belongs on the members list, but yes, the progress made by the 
organisation to date is very impressive. Costs are down, attendance is up, 
sponsorship is up, venues and dates have been locked in for the next two years, 
and the strategic plan looks entirely sane.

(the programme here in Phoenix was great too, in my opinion, big thumbs up to 
the PC)


Joe

Re: minimum IPv6 announcement size

[Joe Abley]

On 2013-09-27, at 10:40, Brandon Ross br...@pobox.com wrote:

 On Fri, 27 Sep 2013, Ryan McIntosh wrote:
 
 It's a waste, even if we're planning for the future, no one house
 needs a /64 sitting on their lan.. or at least none I can sensibly
 think of o_O.
 
 Okay, I'm just curious, what size do you (and other's of similar opinion) 
 think the IPv6 space _should_ have been in order to allow us to not have to 
 jump through conservation hoops ever again?  128 bits isn't enough, clearly, 
 256?  1k?  10k?

Given the design decision to use the bottom 64 bits to identify an individual 
host on a broadcast domain, the increase in address size isn't really 32 bits 
to 128 bits -- if your average v4 subnet size for a vlan is a /27, say, then 
it's more like an increase of 27 bits to 64 bits from the point of view of 
global assignment.

Alternatively, considering that it's normal to give a service provider at least 
a /32, whereas the equivalent assignment in v4 might have been something like a 
/19 (handwave, handwave), it's more like an increase of 13 bits to 32 bits.

Alternatively, considering that it's considered reasonable in some quarters to 
give an end-user a /48 so that they can break out different subnets inside 
their network whereas with IPv4 you'd give a customer a single address and 
expect them to use NAT, then it's more like an increase of 31 bits to 48 bits.

That's still a lower bound of 2^17 times as many available addresses, and 
having enough addresses to satisfy a network 131,072 times as big as the 
current v4 Internet does not seem like a horrible thing. But the oft-repeated 
mantra that there are enough addresses to individually number every grain of 
sand on the world's beaches doesn't describe reality very well.

The IPv6 addressing plan didn't wind up meeting our requirements very well. 
Film at 11.


Joe

Re: iOS 7 update traffic

[Joe Abley]

On 2013-09-23, at 09:10, Simon Leinen simon.lei...@switch.ch wrote:

 Glen Kent writes:
 One of the earlier posts seems to suggest that if iOS updates were
 cached on the ISPs CDN server then the traffic would have been
 manageable since everybody would only contact the local sever to get
 the image. Is this assumption correct?
 
 Not necessarily.  I think most of the iOS 7 update traffic WAS in fact
 delivered from CDN servers (in particular Akamai).  And many/most large
 service providers already have Akamai servers in their networks.  But
 they may not have enough spare capacity for such a sudden demand -
 either in terms of CDN (Akamai) servers or in terms of capacity between
 their CDN servers and their customers.

I think oversubscription in the access network (between the customer and the 
ISP network that might contain Akamai nodes) is the general concern, at least 
from the ISPs I have visibility into. Your access network doesn't have to be a 
narrowband satellite network for this kind of unexpected demand to hurt, and 
provisioning extra access bandwidth in anticipation of a one- or two-day 
possibility of increased demand is not practical.

I don't doubt Apple are aware of the issue and will make changes if they can. 
The characterisation that Apple doesn't care, or is callously causing pain in 
other networks ignores the commercial reality that user experience is important 
to them. The user experience when an anticipated update can't be downloaded 
easily is not great.

The suggestions on how to make things better next time that have appeared on 
this list seem helpful. I would imagine that any vendor with a huge and 
widely-distributed user base would do well to take note.


Joe

Re: iOS 7 update traffic

[Joe Abley]

On 2013-09-23, at 09:41, Glen Kent glen.k...@gmail.com wrote:

 BTW Linux distributions are available to download via bittorrent, so we
 dont really need Akamai/Limelight here. Is there a reason why Apple has not
 adopted bit-torrent for distribution? Are there legal/commercial
 implications using bit-torrent?

There are upstream congestion issues frequently associated with bittorrent. If 
you compare

(a) five thousand students on a campus wifi network trying to download a 1GB 
image from a nearby Akamai cache, and

(b) five thousand students on a campus wifi network seeding a 1GB image to 
people all over the world

it's not obvious that more pain results from (a) than (b).

Even given the ability of Apple to control the behaviour of the bittorrent 
agent (which presumably would be built into iOS) the impact of such a strategy 
on an event of this size seems very hard to predict, given a narrow time base 
and an unknowable number of local network constraints.

It doesn't seem impossible to try and optimise the fan-out by giving network 
operators hooks to influence peer selection based on local topology. But it 
also doesn't sound like an easy general problem to solve (or a problem that 
anybody necessarily wants to spend money on if the relief is only going to be 
felt once per year on major iOS updates).

(Remember as well that the scale here is very different. With iOS, Apple is the 
major Unix vendor on the planet by some margin. No other single Linux or other 
Unix/Unix-like distribution comes close, and I am guessing no single operating 
system triggers the update enthusiasm observed with iOS.)


Joe

Re: iOS 7 update traffic

[Joe Abley]

On 2013-09-19, at 13:58, Paul Ferguson fergdawgs...@mykolab.com wrote:

 Can someone please explain to a non-Apple person what the hell happened
 that started generating so much traffic? Perhaps I missed it in this
 thread, but I would be curious to know what iOS 7 implemented that
 caused this...

I think the inference is that iOS 7 caused the extra traffic by being available 
for download.

There are just a lot of Apple devices, and they tend to get upgraded more 
promptly than other platforms (e.g. on release day). We saw a similar 
phenomenon tracking downloads of the root zone DNSSEC trust anchor from 
data.iana.org -- we now see three million downloads per month, and pretty much 
all of those are iOS devices (or other devices impersonating them, which seems 
unlikely).


Joe

Re: iOS 7 update traffic

[Joe Abley]

On 2013-09-19, at 14:11, Warren Bailey wbai...@satelliteintelligencegroup.com 
wrote:

 I don't see how operators could tolerate this, honestly. I can't think of a 
 single provider who does not oversubscribe their access platform... Which 
 leads me to this question :
 
 Why does apple feel it is okay to send every mobile device an update on a 
 single day?

How is this different from the flash crowds caused by hockey championships, or 
football games, or any of the other things that generate a lot of simultaneous 
interest every once in a while?

 Never mind the fact that we are we ones on the last mile responsible for 
 getting it to their customers, 1gb per sub is pretty serious.. Why are they 
 not caching at their head ends, dslams, etc?

Given that the code is signed, I'm surprised that iDevices that have already 
upgraded the hard way don't advertise a update available service on local 
networks. Individual devices don't care where the updates come from, so long as 
the signatures are good.

You'd think that'd have the potential to improve the user experience as well as 
avoid jamming the tubes, especially in highly multi-user environments like 
university campuses; it could probably halve the network load in a significant 
number of home networks, too.


Joe

Re: iOS 7 update traffic

[Joe Abley]

On 2013-09-19, at 18:08, Jared Mauch ja...@puck.nether.net wrote:

 I think there's a lot that could be done when looking at how to shift this.

But likely not before the first iOS 7 patch release.

http://appleinsider.com/articles/13/09/19/apples-control-center-used-to-bypass-ios-7-passcode-lock


Joe

Re: DNS Reliability

[Joe Abley]

On 2013-09-13, at 16:01, Jean-Francois Mezei jfmezei_na...@vaxination.ca 
wrote:

 On 13-09-12 21:53, Larry Sheldon wrote:
 
 I expect 100.000%
 
 I'll accept 99.999% or better.
 
 At these numbers, one has to start to count failover time.

Before really any part of this thread makes sense, you have to describe exactly 
what you mean by available.


Joe

Re: Internet Surveillance and Boomerang Routing: A Call for Canadian Network Sovereignty

[Joe Abley]

On 2013-09-09, at 14:29, joel jaeggli joe...@bogus.com wrote:

 On 9/9/13 7:43 AM, Jason Lixfeld wrote:
 That notwithstanding, it's stupid to send traffic to/from one of the
 large $your_region/country incumbents via $not_your_region/country.
 It's just not good Internet. 
 
 yyz-yvr is faster via the united states. physics doesn't respect
 poltical boundries.

Not only physics, but geometry. Vancouver is further north than Seattle, but 
Toronto is further south than Portland.

http://www.gcmap.com/mapui?P=YYZ-YVR


Joe

Re: Evaluating Tier 1 Internet providers

[Joe Abley]

On 2013-08-27, at 15:02, Eric Louie elo...@yahoo.com wrote:

 Based on various conversation threads on Nanog I've come up with a few
 criteria for evaluating Tier 1 providers.  I'm open to add other criteria -
 what would you add to this list?  And how would I get a quantitative or
 qualitative measure of it?
 
 routing stability
 
 BGP community offerings
 
 congestion issues
 
 BGP Peering relationships
 
 path diversity
 
 IPv6 table size

I would add:

 - presence of staff in key locations (if 60 Hudson is a critical location for 
you, find out whether there's someone regularly present in or near the building 
to clean fibre and help run loopback tests when you need them)

 - expected time to clue when calling the support number (bonus points for 
being xkcd-806 compliant)

 - time taken to turn around BGP import filter changes

 - response you can expect when you call one day and say our 10GE is maxed out 
with inbound traffic from apparently everywhere, it has been going on for an 
hour, please help

 - billing accuracy, and turnaround time for questions raised about invoices 
received

A lot of this comes down to conversations in the NANOG bar with people who have 
war stories to share. To that extent, I think reputation is a good indicator, 
so long as your sample size is reasonable, and depending on the amount of beer 
involved.

One other thing to think about -- Tier 1 providers are transit free, so your 
can be reached by an IP packet from is naturally limited to specific peering 
relationships with other Tier 1 providers. Tier 2 providers (those who buy 
transit from a suitably-diverse set of Tier 1s) can insulate you from route 
fade due to peering spats.


Joe

Re: Vancouver IXP - VanTX - BCNet

[Joe Abley]

On 2013-08-21, at 6:40, Christopher Morrell
christopher.morrell.na...@gmail.com wrote:

 I think CANIX in Toronto has been dead for years. I used to operate the 
 switch for it in my days at UUNET in the 90s.

Yes, very dead.

 In Montreal, is anyone at the Peer1 exchange other than Peer1?

Peer1 exchanges are only open to Peer1 customers, I believe. At least,
that's how it worked in Toronto the last time I looked.


Joe

Re: Vancouver IXP - VanTX - BCNet

[Joe Abley]

Hi Randy,

On 2013-08-20, at 01:05, Randy Bush ra...@psg.com wrote:

 As you may know CIRA has been working with groups across Canada to
 establish new IXPs.
 
 wow!  i thought there were a lot of ixps, torix, vantx, ...

The TorIX has been the most significant exchange point with growth and traffic 
for some years. I hear the QIX in Montréal (pre-CIRA) was active, but I know 
less about that one since I've never had occasion to connect and use it. Other 
exchange points have existed (or still exist) in Halifax, London, Edmonton and 
Ottawa but have struggled to attract interest despite enthusiastic and 
well-meaning activism on the part of individuals.

I always had the impression that the BCIX in Vancouver was mainly a cooperative 
transit purchasing arrangement between academic institutions, and that all 
commercial peering on the west coast of Canada really took place in Seattle. 
Again, I have no direct experience however.

What CIRA is doing is providing support in the areas where previous efforts 
have struggled, providing hardware, accounts payable, legal, help with 
incorporation and forming sensible bylaws and stimulating local discussion and 
interest. My perspective is that they have done a great job in Calgary and 
Montréal. It sounds like the approach in Vancouver (engage with existing 
efforts, see where CIRA can help) is following the same path.

 are these open, neutral, ixps, a la six etc?  or big players trying to
 save the internet from itself?

I think they are as open and neutral as the local ISP communities want, and 
that CIRA is not dictating terms but rather enabling locals to do what they 
think is best for themselves. Open, Neutral, à la SIX (et à la TorIX) is what 
people seem to want.

I think the work CIRA is doing here is sensible, pragmatic, sensitive and 
useful. A good use of my .CA domain registration fees. It'd be nice to hear 
more about their experiences in Phoenix, if there is a suitable slot available 
on the programme.


Joe

Re: How big is the Internet?

[Joe Abley]

On 2013-08-15, at 16:18, Larry Sheldon larryshel...@cox.net wrote:

 Isn't that like excluding city streets from the How many miles of roads? 
 question--likely to be the bigger fraction of the whole-as-a-traveler-sees-it?

At last! A car analogy. I was beginning to think this was some other NANOG.


Joe

Re: .nyc - here we go...

[Joe Abley]

On 2013-07-03, at 01:04, Paul Ferguson fergdawgs...@gmail.com wrote:

 Why does this discussion have to always be one or the other?
 
 We have multiple problems here, friends.
 
 Focus.

I think you mean de-focus. :-)


Joe

Re: Paetec PI space?

[Joe Abley]

On 2013-06-26, at 13:52, Adam Greene maill...@webjogger.net wrote:

 We have a customer who was assigned some PI IPv4 space by Paetec back in
 mid-90's

I think it's correct to say that the only entities that can assign PI IPv4 
space are RIRs and the IANA. If I'm right, what you're talking about is PA 
space, regardless of claims made by your customer or Paetec.


Joe

Re: How ISP's in ARIN region create automatic prefix-filters?

[Joe Abley]

On 2013-06-12, at 13:38, Martin T m4rtn...@gmail.com wrote:

 as I understand, ARIN whois database does not contain route objects,
 which are used for example in RIPE region for automatic BGP prefix
 filter generation.

whois.arin.net:43 is for assignment/allocation information. Does not use RPSL.

rr.arin.net:43 is a routing registry that uses RPSL.

 How does this work in ARIN region? I know that at
 least some ISP's operating in ARIN region use their own whois
 databases(for example rr.level3.net) which mirror content from other
 RIR databases, but are there other methods how they update their
 internal databases with records?

My general advice for anybody who cares to listen is to use the RIPE db for 
your objects if you are based in the ARIN region. It saves time if/when you 
come to peer with an organisation based in the RIPE region, and it makes your 
objects easy to find for anybody who wants to look for them.

You can install a route in the RIPE db corresponding to number resources 
assigned elsewhere by authenticating against the RIPE-NCC-RPSL-MNT maintainer 
object, for which the plain-text password is RPSL. Since your new route 
object will specify mnt-by MAINT-YOURS you will also need to authenticate 
against that (my favourite method is PGP).


Joe

mntner: RIPE-NCC-RPSL-MNT
descr:  This maintainer may be used to create objects to represent
descr:  routing policy in the RIPE Database for number resources not
descr:  allocated or assigned from the RIPE NCC.
admin-c:RD132-RIPE
auth:   MD5-PW # Filtered
remarks:***
remarks:* The password for this object is 'RPSL', without the *
remarks:* quotes. Do NOT use this maintainer as 'mnt-by'. *
remarks:***
mnt-by: RIPE-DBM-MNT
referral-by:RIPE-DBM-MNT
source: RIPE # Filtered

Re: PGP/SSL/TLS really as secure as one thinks?

[Joe Abley]

On 2013-06-07, at 11:14, Jeroen Massar jer...@massar.ch wrote:

 On 2013-06-07 06:50, Dan White wrote:
 [..]
 
 A nice 'it is Friday' kind of thought
 
 OpenPGP and other end-to-end protocols protect against all nefarious
 actors, including state entities.
 
 If you can't trust the entities where your data is flowing through
 because you are unsure if and where they are tapping you, why do you
 trust any of the crypto out there that is allowed to exist? :)

Defence in depth. PGP-encrypt your transport stream and send it over TLS with 
client- and server-side certificate validation with a restricted CA list on 
each endpoint. Using IPSec. Through tor. With the plain-text littered with code 
words that are meaningless except to your intended recipient, taken from a 
pre-shared (in-person) code book that changes every day.

Then your facebook sessions will be secure.


Joe

Re: Single AS multiple Dirverse Providers

[Joe Abley]

On 2013-06-10, at 18:36, Dennis Burgess dmburg...@linktechs.net wrote:

 I have a network that has three peers, two are at one site and the third
 is geographically diverse, and there is NO connection between the two
 separate networks.
 
 
 
 Currently we are announcing several /24s out one network and other /24s
 out the second network, they do not overlap.  To the internet this works
 fine, however, providers a/b at site1 do not send us the two /24s from
 site b..   We have requested them to, but have not seen them come in,
 nor do we have any filters that would prohibit them from coming in. 
 
 
 
 Is this normal?

Yeah.

 Can we receive those routes even though they are from
 our own AS?

You can stop them from being suppressed inbound by using neigh x.x.x.x 
allowas-in on a cisco, or set neigh x.x.x.x allowas-in on JunOS.

 What is the best practice in this case?  

I don't know. Above seems reasonable. I've seen people join their sites with 
tunnels plumbed to router loopbacks in different sites and run IGPs over them 
before; this gives them inter-site connectivity which makes the question moot. 
But it involves tunnels.


Joe

Re: Single AS multiple Dirverse Providers

[Joe Abley]

On 2013-06-10, at 18:43, Joe Abley jab...@hopcount.ca wrote:

 [...] neigh x.x.x.x allowas-in on JunOS.

Actually, I think that's JunOSe. Or however you capitalise it.


Joe

Re: Canadian Hosting Providers - how do you handle copyright and trademark complaints

[Joe Abley]

Hi Landon,

On 2013-06-04, at 19:44, Landon landonstew...@gmail.com wrote:

 I'm wondering how other Canadian Hosting Providers handle copyright and
 trademark complaints about customers on their network.

This is perhaps not directly related to your question (it concerns the 
application of copyright law in Canada on customers of an access provider) but 
it might give you some background.

  http://blogs.teksavvy.com/2012/11/30/copyrightlaw/
  
http://blogs.teksavvy.com/2012/12/10/firm-seeks-customer-information-in-copyright-infringement-lawsuit/
  
http://www.teksavvy.com/en/why-teksavvy/in-the-news/teksavvy-customer-notices/copyright-law-in-canada/copyright-faqs


Joe

Re: NANOG58 - link to OpenFlow session slides

[Joe Abley]

On 2013-06-03, at 11:14, Phil Fagan philfa...@gmail.com wrote:

 Stupid questionthere's not a live stream for 58 is there?

There's a grey icon in the agenda for sessions that are being streamed, looks 
like. Click grey icon, video appears.


Joe

Re: Geoip lookup

[Joe Abley]

On 2013-05-23, at 15:47, shawn wilson ag4ve...@gmail.com wrote:

 What's the best way to find the networks in a country? I was thinking of
 writing some perl with Net::Whois::ARIN or some such module and loop
 through the block. But I think I'll have to be smarter than just a simple
 loop not to get blocked and I figure I'm not the first to want to do this.

If you are looking for registration data, try looking in one or more of

  ftp://ftp.apnic.net/public/apnic/stats/apnic/
  ftp://ftp.ripe.net/ripe/dbase/
  ftp://ftp.lacnic.net/pub/stats/lacnic/
  ftp://ftp.afrinic.net/stats/afrinic/
  ftp://ftp.arin.net/pub/stats/arin/

(poke around and see what you can find; I didn't spend much time trying, but 
several/all of the RIRs seem to mirror data from all the others)

Note that networks in a country is a funny phrase. The sets

 - address space assigned to all organisations located in country X
 - routes visible in country X (from some viewpoint)
 - all addresses assigned to devices physically located within country X
 - routes that are considered in-country in places where billing is aligned 
with the necessity to traverse a long bit of wet glass

are frequently incongruent. If this matters, you might want to consider a more 
detailed specification of networks in a country.


Joe

Re: Geoip lookup

[Joe Abley]

On 2013-05-23, at 16:56, shawn wilson ag4ve...@gmail.com wrote:

 It looks you're right and everyone does have the same data in
 historical format. Looks like RIPE has everything compiled into what
 is current. So if a block hasn't changed for 10 years, it'll be in the
 RIPE dataset vs with the others, I'd have to write something to
 overlay the data through out time to get current?

Could be. You've looked at this more than I have, now -- I was mainly trying to 
point out that bulk data retrieval is a possible option so you could avoid 
whois-hammering :-)


Joe

Re: Dear NANOG Gods

[Joe Abley]

Hi Warren,

On 2013-05-21, at 14:48, Warren Bailey wbai...@satelliteintelligencegroup.com 
wrote:

 I need to ship some Dell servers, and my google skills have gotten me 
 nowhere. Is there a decent place to find standard server size shipping boxes? 
 Located in Socal if anyone has an extra or two.. ;)

The last time I had to ship a box myself I went to the local UPS Canada office, 
since they evidently will pack and ship rather than just ship.

The last time we had to ship a number of (Dell, actually) boxes from ICANN in 
LA we bought some flight cases that we could rack the servers into. Our thought 
was to go for reusable, rather than one-off (and we had doubts about the state 
of the boxes upon arrival if they weren't securely packed; a flight case with 
19 rails inside seemed like a good bet).

We found the flight cases with only minimal googling, but if you're having 
trouble Mehmet could no doubt hook you up.

And if you're close to El Segundo and we can get the flight case back when 
you're done, you could probably just borrow ours :-)


Joe

Re: Dear NANOG Gods

[Joe Abley]

Since some people were interested (on- and off-list), see below.

On 2013-05-21, at 15:32, Mehmet Akcin meh...@icann.org wrote:

 hey there
 
 we have a case from http://www.skbcases.com 20U 20 
 
 they are really reliable (been using them since 6 years, shipped meeting 
 equipment for ICANN before and also servers as joe mentioned below
 
 let me know how we can help
 
 mehmet
 
 On May 21, 2013, at 12:27 PM, Joe Abley joe.ab...@icann.org wrote:
 
 Hey,
 
 Do you remember where you bought those flight cases we used to ship Dell 1Us 
 around the place?
 
 People on NANOG want to know :-)
 
 
 Joe
 
 Begin forwarded message:
 
 From: Jason Faraone jfara...@paulo.com
 Subject: RE: Dear NANOG Gods
 Date: 21 May 2013 15:10:32 EDT
 To: 'Joe Abley' jab...@hopcount.ca, Warren Bailey 
 wbai...@satelliteintelligencegroup.com
 Cc: NANOG list nanog@nanog.org
 
 Would you happen to have a link for a flight case that would fit a 1-2u 
 server? I was in the same situation a few days ago and ran the risky 
 proposition of building my own box.
 
 -Original Message-
 From: Joe Abley [mailto:jab...@hopcount.ca] 
 Sent: Tuesday, May 21, 2013 1:56 PM
 To: Warren Bailey
 Cc: NANOG list
 Subject: Re: Dear NANOG Gods
 
 Hi Warren,
 
 On 2013-05-21, at 14:48, Warren Bailey 
 wbai...@satelliteintelligencegroup.com wrote:
 
 I need to ship some Dell servers, and my google skills have gotten me 
 nowhere. Is there a decent place to find standard server size shipping 
 boxes? Located in Socal if anyone has an extra or two.. ;)
 
 The last time I had to ship a box myself I went to the local UPS Canada 
 office, since they evidently will pack and ship rather than just ship.
 
 The last time we had to ship a number of (Dell, actually) boxes from ICANN 
 in LA we bought some flight cases that we could rack the servers into. Our 
 thought was to go for reusable, rather than one-off (and we had doubts 
 about the state of the boxes upon arrival if they weren't securely packed; 
 a flight case with 19 rails inside seemed like a good bet).
 
 We found the flight cases with only minimal googling, but if you're having 
 trouble Mehmet could no doubt hook you up.
 
 And if you're close to El Segundo and we can get the flight case back when 
 you're done, you could probably just borrow ours :-)
 
 
 Joe
 
 

Re: Could not send email to office 365

[Joe Abley]

On 2013-05-02, at 02:42, Cathy Almond cat...@isc.org wrote:

 This may be a red herring, but I've heard of some dropping of DNS
 queries for the names within outlook.com domains where the queries are
 all coming from source port 53 (i.e. your recursive server doesn't use
 query source port randomization

... or there's a NAT or some other box in front of the recursive server which 
re-writes the source port...

 ).  Might be worth checking what the
 recursive server you're using is doing?
 
 See https://www.dns-oarc.net/oarc/services/porttest


Joe

Re: Google Public DNS Problems?

[Joe Abley]

On 2013-05-02, at 11:51, Jay Ashworth j...@baylink.com wrote:

 But since Perry's problem is *inability to resolve names in google's
 public zones*, the *path to the ZONE servers* is the thing diagnostics
 would require a trace to, no?

Blair's problem, I think. Perry was just being helpful. Blair's point was that 
if Google DNS is not able to resolve Google domains, then you know something is 
wrong.

 If 8.8.8.8 doesn't *answer* for google.com (and no one's told me it
 has), then how you get there is irrelevant.

Well, if you're trying to troubleshoot the performance or functionality of a 
service that is deployed using anycast, knowing what anycast node is giving 
problems is pretty useful. I say this as someone who has to help troubleshoot 
problems with anycast DNS services pretty regularly.

Since there's no obvious way (in the draft-jabley-dnsop-anycast-mapping sense) 
to identify a Google DNS anycast node in-band, traceroute and RTT are pretty 
much what we're left with.


Joe

Re: Google Public DNS Problems?

[Joe Abley]

On 2013-05-02, at 11:59, Charles Gucker cguc...@onesc.net wrote:

 That's not entirely true.You can easily do lookup for
 whoami.akamai.net and it will return the unicast address for the node
 in question (provided the local resolver is able to do the
 resolution).This is a frequent lookup that I do when I don't know
 what actual anycast node I'm using.

Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai 
authoritative server Google last used to answer that query.

If I can rely upon there being an Akamai auth server every place there's a 
Google 8.8.8.8 server, then that does seem fun and useful for identifying the 
Google node I'm using. Is that the case?

(If I ask 8.8.8.8, which is somewhere 30ms from Toronto, about 
identity.l.root-servers.org/IN/TXT then the answer I get just now is Paris, 
France. L-Root and Google/8.8.8.8 are not colocated. So the usefulness of this 
technique in general to identify Google nodes depends on deployment 
assumptions.)


Joe

Re: Google Public DNS Problems?

[Joe Abley]

On 2013-05-02, at 12:10, Joe Abley jab...@hopcount.ca wrote:

 On 2013-05-02, at 11:59, Charles Gucker cguc...@onesc.net wrote:
 
That's not entirely true.You can easily do lookup for
 whoami.akamai.net and it will return the unicast address for the node
 in question (provided the local resolver is able to do the
 resolution).This is a frequent lookup that I do when I don't know
 what actual anycast node I'm using.
 
 Using 8.8.8.8 to tell me about whoami.akamai.net tells me what Akamai 
 authoritative server Google last used to answer that query.

Oh, now that I poke at it, it seems like whoami.akamai.net is telling me about 
the address of the resolver I used, rather than the address of the akamai node 
I hit.

Never mind, I understand now :-)


Joe

Re: Andros Island Connectivity?

[Joe Abley]

On 2013-05-01, at 01:23, joseph.sny...@gmail.com wrote:

 Doesn't cable Bahamas sell in andros

BaTelCo has five retail stores on Andros too, which suggests they offer some 
kind of service there (whether wireline or wireless).

For a list whose subscribers have generally more experience on the ground in 
the Caribbean, perhaps try http://www.caribnog.org/mailing-list/.


Joe

Re: Google Public DNS Problems?

[Joe Abley]

On 2013-05-01, at 12:09, Blair Trosper blair.tros...@gmail.com wrote:

 Is anyone else seeing this?  From Santa Clara, CA, on Comcast
 Business...I'm getting SERVFAIL for any query I throw at 8.8.8.8 and
 8.8.4.4...
 
 Level 3's own public resolvers are fine for me, as are OpenDNS's resolvers.

Google just turned on validation across the whole of 8.8.8.8 and 8.8.4.4. The 
expected behaviour in the case where a response does not validate is to return 
SERVFAIL to the client.

You could check that the queries you are sending are not suffering from poor 
signing hygiene (e.g. use the handy-dandy dnsviz.net visualisation).

If this is a repeatable, consistent problem even for unsigned zones (or for 
zones that you've verified are signed correctly) and especially if it's 
widespread you might want to call google on the nanog courtesy phone and have 
them look for collateral damage from their recent foray into 8.8.8.8 validation.

Raw output from dig/drill and traceroutes to 8.8.8.8/8.8.4.4 are highly 
recommended if you need to take this further.


Joe

Re: KVM

[Joe Abley]

On 2013-04-23, at 17:36, shawn wilson ag4ve...@gmail.com wrote:

 I'm looking at an IP-KVM.

I have heard only good things about opengear.


Joe

Re: What do people use public suffix for?

[Joe Abley]

On 2013-04-19, at 14:17, Bjørn Mork bj...@mork.no wrote:

 It is already, isn't it?  The NS and SOA records will tell you all there
 is to know about zone splits and cross zone relations.

Not really.

In general, just because a zone is served by the same nameservers as another 
zone doesn't mean that they are administratively equivalent (e.g. for cookie 
hygiene purposes).

Just because two zones are served on different nameservers doesn't mean they 
are administratively separate. Lots of administratively-separate domains share 
the same nameservers.

Drawing related conclusions from similarity of SOA RDATA between zones, or the 
number of zone cuts between a particular zone and the root, or the number of 
labels in a domain name is similarly flawed.

If the rule was just the nameservers need to be the same and the SOA RDATA 
needs to be the same, for some well-documented meaning of 'same' then gaming 
that rule (e.g. for purposes of cookie injection) as a miscreant is 
unpleasantly straightforward.


Joe

Re: What do people use public suffix for?

[Joe Abley]

On 2013-04-15, at 12:00, Jay Ashworth j...@baylink.com wrote:

 Seems to me that it's a crock because *it should be in the DNS*.
 
 I should be able to retrieve the AS (administrative split) record 
 for .co.uk, and there should be one that says, yup, there's an
 administrative split below me; nothing under there is mine unless 
 you also get an exception record for a subdomain.

I've always quite liked that idea (if we accept for the point of discussion 
that there are use-cases like cookie naming that make identifying this kind of 
boundary useful).

There's a concern though that there are multiple ways to spoof such a DNS 
response, and do so in a distributed fashion that might not be easy to detect 
by an individual client application. If the AS (or whatever) record was signed, 
that would make things better. But only if you could rely upon clients to 
validate those responses (or have a sufficiently clean DNS path out that 
validation was even possible).

There's also the question of what to do with a TLD (or other part of the 
namespace) that doesn't include this record. Some of the zones we're talking 
about are generated by registry machinery with long software development 
lifecycles.

If your starting point is (a) the records might not be there, (b) we might not 
be able to find them even if they are there, and (c) if we get them we can't 
always be sure they are genuine, then the natural conclusion is that you can't 
rely on the mechanism to work and you look for another answer.

If you need the mechanism to work (say you're say a browser vendor who is going 
to get heat if cookie-leakage causes widespread privacy violations) then I can 
see why fetching and caching a browser list over SSL (and perhaps shipping with 
a baseline version of it) seems attractive.

And that I guess takes us back to where we are.


Joe

Re: Quad-A records in Network Solutions ?

[Joe Abley]

You have a choice of registrars. If you don't like the one you are using right 
now, choose a different one. There are lots to choose from.

http://www.icann.org/registrar-reports/accredited-list.html


Joe

Sent from my Ono-Sendai Cyberspace 7

On 2013-04-10, at 2:42, Alejandro Acosta alejandroacostaal...@gmail.com wrote:

 Hi Carlos, list,
  Today I entered to networksolutions.com and I remembered this
 thread. I had to administer a domain name and I sadly found they have
 done nothing in IPv6 during the last 12 month.
 
 Regards,
 
 ^Ao$
 
 On 3/28/12, Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote:
 Hello all,
 
 I just received a heads-up from a friend telling me that Network
 Solutions is unable/unwilling to configure 's for .com/.net domains.
 He works for a large media outlet who will be enabling IPv6 on their
 sites for World IPv6 Launch Day.
 
 I hope it's just a misunderstanding.  If it's not, I would love to know
 if there is a reason for this, and if they have a timeline for
 supporting 's.
 
 It's ok to contact me privately.
 
 regards
 
 Carlos
 

Re: route for linx.net in Level3?

[Joe Abley]

On 2013-04-04, at 15:53, Brian Dickson brian.peter.dick...@gmail.com wrote:

 Leo Bicknell wrote:
 
 Even if the exchange does not advertise the
 exchange LAN, it's probably the case that it is in the IGP (or at
 least IBGP) of everyone connected to it,

I have experience of several networks where that is not the case. IGP carries 
routes for loopback and internal-facing interfaces; external-facing interface 
routes are only known to the local router; pervasive next-hop-self for IBGP.

So, no great survey, but don't assume that everybody does things the same way.


Joe

public consultation on root zone KSK rollover

[Joe Abley]

Hi all,

As advised a month or so ago, the following public comment period is open:

  
http://www.icann.org/en/news/public-comment/root-zone-consultation-08mar13-en.htm

We have received a small number of responses which are accessible from that 
page.

The topic at hand and the specific questions that have been asked as part of 
the consultation are important ones; the decisions taken will have operational 
consequences to any user of the Internet who validates DNS responses with 
DNSSEC.

If you have experience, opinions or expertise to contribute, it would be 
greatly appreciated. The window for being able to submit comments closes on 12 
April 2013 at 23:59 UTC.

Many thanks,


Joe

Re: Open Resolver Problems

[Joe Abley]

On 2013-04-03, at 11:25, Jerry Dent effinjd...@gmail.com wrote:

 I think that is .2% - .3%, no?

Oh, you're right -- it does seem substantially closer to zero when you put the 
decimal point in the right place :-)


Joe

Re: Open Resolver Problems

[Joe Abley]

On 2013-04-03, at 12:52, Jay Ashworth j...@baylink.com wrote:

 - Original Message -
 From: Joe Abley jab...@hopcount.ca
 
 On 2013-04-03, at 11:25, Jerry Dent effinjd...@gmail.com wrote:
 
 I think that is .2% - .3%, no?
 
 Oh, you're right -- it does seem substantially closer to zero when you
 put the decimal point in the right place :-)
 
 Huh?
 
 23 in 1000 is in fact 2.3%.

That's it, no more e-mail for me today.


Joe

Re: Open Resolver Problems

[Joe Abley]

On 2013-04-02, at 18:18, John Kristoff j...@cymru.com wrote:

 I would expect from stubs this will be close enough to zero to be
 effectively zero.  At least I would hope so.

This (below) is one of four resolvers, together providing service for two 
recursive DNS servers used by residential DSL and cable internet users at a 
medium-sized ISP in Canada. These resolvers are running unbound, which will 
never choose a source port of 53 on an outbound query; hence anything we see 
here with src port = dst port = 53 is one of those effective zeros.

[dns1-p1:~]% sudo tcpdump -i em0 -n -c 1 -w sample.pcap udp port 53   
tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
1 packets captured
10267 packets received by filter
0 packets dropped by kernel
[dns1-p1:~]% tcpdump -r sample.pcap -q udp src port 53 and udp dst port 53 | wc 
-l
reading from file sample.pcap, link-type EN10MB (Ethernet)
  26
[dns1-p1:~]% 

26/1000 is more than zero but still quite small. Subsequent samples with bigger 
sizes give 332/10, 3017/100.

No science here, but 2% - 3% is what it looks like, which is big enough to be a 
noticeable support cost for a medium-scale provider if the customer damage is 
not robo-mediated in some way (e.g. whitelist known offenders to avoid the 
support phone glowing red when you first turn it on).


Joe

Re: Open Resolver Problems

[Joe Abley]

On 2013-04-01, at 14:19, Jay Ashworth j...@baylink.com wrote:

 From: Roland Dobbins rdobb...@arbor.net
 
 On Apr 1, 2013, at 11:18 PM, Patrick W. Gilmore wrote:
 Of course, since users shouldn't be using off-net name servers
 anyway, this isn't really a problem! :)
 
 ;
 
 It's easy enough to construct ACLs to restrict the broadband consumer
 access networks from doing so. Additional egress filtering would catch
 any reflected attacks, per your previous comments.
 
 So, how would Patrick's caveat affect me, whose recursive resolver *is 
 on my Linux laptop*?  Would not that recursor be making queries he 
 advocates blocking?

The badness that Patrick is talking about blocking are DNS responses being sent 
from consumer devices to the Internet, answering DNS queries being sent from 
the Internet towards consumer devices. (I think. This thread is sufficiently 
circular that I feel a bit dizzy, and could be mistaken.) The DNS traffic 
outbound from your laptop will be DNS queries (not responses) and the inbound 
traffic will be DNS responses (not queries). The traffic profiles are different.

The case where infected consumer devices originate source-spoofed queries 
towards open resolvers, feeding a query stream to an amplifier for delivery to 
a victim, is mitigated by preventing those consumer devices from spoofing their 
source address, so BCP38.

The case where infected consumer devices originate non-source-spoofed queries 
towards DNS servers in order to overwhelm the servers themselves with perfectly 
legitimate-looking queries is a harder problem to solve at the edge, and is 
most easily mitigated for DNS server operators by the approach ensure great 
headroom.


Joe

Re: Open Resolver Problems

[Joe Abley]

On 2013-03-27, at 09:47, William Herrin b...@herrin.us wrote:

 On Tue, Mar 26, 2013 at 10:07 PM, Tom Paseka t...@cloudflare.com wrote:
 Authoritative DNS servers need to implement rate limiting. (a client
 shouldn't query you twice for the same thing within its TTL).
 
 Right now that's a complaint for the mainstream software authors, not
 for the system operators. When the version of Bind in Debian Stable
 implements this feature, I'll surely turn it on.

RRL is a moving target, although a promising one.

There are currently three implementations of RRL which all behave slightly 
differently. There is active discussion between the vendors who have 
implemented RRL, and between early adopters and the vendors. The specification 
is not yet stable, and changes in the functionality and the rate-limiting 
behaviour continue to be made.

My assessment is that the implementations I have seen are ready for production 
use, but I think it's understandable given the moving goalpoasts that some 
vendors have not yet promoted the code to be included in stable releases.

As an operator, I understand the benefits of using packaged, stable releases of 
code. However, we also have a responsibility to deal with operational problems 
in a timely way. I think it's worth considering that it may well be worth 
deviating from internal policies about code deployment in this instance; the 
benefits of doing so can be substantial, and the costs of doing so (especially 
if we expect them to be time-limited) are not that high.


Joe

Re: Open Resolver Problems

[Joe Abley]

On 2013-03-27, at 14:52, Jared Mauch ja...@puck.nether.net wrote:

 I am very concerned about examples such as this possibly being implemented by 
 a well intentioned sysadmin or neteng type without understanding their query 
 load and patterns.  bind with the rrl patch does log when things are 
 happening.  While the data is possible to extract from iptables, IMHO it's 
 not quite as easy to audit as a syslog.

For an authoritative-only server, people can expect coarse rate-limits such as 
those quoted earlier with iptables to give false positives and to reject 
legitimate queries. RRL is far safer.

For a recursive server, I agree you need a much better understanding of your 
traffic patterns before you try something like the iptables example. Dropping 
queries from your own clients' stub resolvers has an immediate support cost. 
You *really* don't want false positives, there.


Joe

Re: Open Resolver Problems

[Joe Abley]

On 2013-03-27, at 17:59, Jack Bates jba...@brightok.net wrote:

 DNS is UDP for a reason.

Not a great reason, as it turns out. But hindsight is 20/20.

 The infrastructure to switch it to TCP is prohibitive and completely destroys 
 the anycast mechanisms.

No.


Joe