Re: dns interceptors
Am 15.02.2010 um 04:29 schrieb Randy Bush: > and i presume i have to dump all client.crt files in the server's > ../openvpn dir, but under what names? or does it just wantonly trust > anyone under that ca? Any cert signed by that CA. Use --cclient-config-dir to limit which CNs are acceptable, and to add custom configs per client on the server. On the client, use --tls-remote to limit which CN the client will accept when connecting to the server. On the server, you can also roll your own script to inspected the certificate presented by the client, and act on that. Stefan -- Stefan BethkeFon +49 151 14070811
Re: dns interceptors
Randy Bush wrote: just normal certs can be text, pem, der, ... randy Randy, pem format.
Re: dns interceptors
>> having probs with certs, i.e. what --outform it wants. > They are just normal cert's just normal certs can be text, pem, der, ... randy
Re: dns interceptors
>> having probs with certs, i.e. what --outform it wants. not finding in >> docs. tried raw, but now guessing pem. same for client and server > Use the easy-rsa stuff and it will do all the hard work for you. > http://openvpn.net/index.php/open-source/documentation/howto.html we have a pki we know and love but i am trying/disecting easy-rsa to see what it is doing randy
Re: dns interceptors
On Sun, Feb 14, 2010 at 7:29 PM, Randy Bush wrote: > end user to network > > having probs with certs, i.e. what --outform it wants. not finding in > docs. tried raw, but now guessing pem. same for client and server Use the easy-rsa stuff and it will do all the hard work for you. http://openvpn.net/index.php/open-source/documentation/howto.html Scott
Re: dns interceptors
Yes. Easy rsa is the way to go. They are normal certs. Check the scripts if you want to roll your own openssl wrapper scripts. --Original Message-- From: Larry Brower To: nanog@nanog.org Subject: Re: dns interceptors Sent: Feb 14, 2010 7:44 PM Randy Bush wrote: > end user to network > > having probs with certs, i.e. what --outform it wants. not finding in > docs. tried raw, but now guessing pem. same for client and server > > server > ca.crt > server.crt > server.key > > client > ca.crt > client.crt > client.key > > and i presume i have to dump all client.crt files in the server's > ../openvpn dir, but under what names? or does it just wantonly trust > anyone under that ca? > > randy > > What error is getting logged? They are just normal cert's and should be in the keys directory under openvpn's user directory. OpenVPN includes scripts that can make the certificates for you under the directory easy-rsa Sent via BlackBerry from T-Mobile
Re: Time out for a terminology check--"resolver" vs "server".
In message <6eb799ab1002141824s652c4f31od02cb750912a0...@mail.gmail.com>, James Hess writes: > > Also, BIND implements the EXPIRE value in the SOA. > But other DNS server software applications widely ignore this value, > and the zone stays authoritative on all servers, no matter how much > time elapses between updates (in that case). And if there are loops in the zone transfer graph slaves can stay alive even if they are checking the serial of the master to see if they need to expire the zone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: dns interceptors
Randy Bush wrote: end user to network having probs with certs, i.e. what --outform it wants. not finding in docs. tried raw, but now guessing pem. same for client and server server ca.crt server.crt server.key client ca.crt client.crt client.key and i presume i have to dump all client.crt files in the server's ../openvpn dir, but under what names? or does it just wantonly trust anyone under that ca? randy What error is getting logged? They are just normal cert's and should be in the keys directory under openvpn's user directory. OpenVPN includes scripts that can make the certificates for you under the directory easy-rsa
Re: dns interceptors
end user to network having probs with certs, i.e. what --outform it wants. not finding in docs. tried raw, but now guessing pem. same for client and server server ca.crt server.crt server.key client ca.crt client.crt client.key and i presume i have to dump all client.crt files in the server's ../openvpn dir, but under what names? or does it just wantonly trust anyone under that ca? randy
Re: dns interceptors
Not familiar with --outform argument. Will have to look into it. Presume you are doing site to site/network to network? Or are you setting this up for end users to terminate to? I've done the latter many many times, but not net to net. Happy to provide docs if you/nanog like. I think that everyone should run a vpn to secure remote access to services they are operating. You integrating this with an existing ski infrastructure? If so is it openssl based? Or maybe ad based? Lots of openvpn variables Might be worth starting a new thread on the subject. As I said, I feel its vital for folks to have a deep familiarity with openvpn and best practices etc. --Original Message-- From: Randy Bush To: Charles Wyble Cc: nanog@nanog.org Subject: Re: dns interceptors Sent: Feb 14, 2010 7:10 PM > I run openvpn on my linux box to do exactly that. i am in the midst of setting up some openvpn servers now, westin, ashburn, tokyo, but westin first. having problems sorting in what --outform it wants the bleeping certs. randy Sent via BlackBerry from T-Mobile
Re: dns interceptors
> I run openvpn on my linux box to do exactly that. i am in the midst of setting up some openvpn servers now, westin, ashburn, tokyo, but westin first. having problems sorting in what --outform it wants the bleeping certs. randy
Re: Time out for a terminology check--"resolver" vs "server".
On 2/14/2010 8:14 PM, Jon Lewis wrote: >> The glue and all of that stuff won't expire at TTL=0? > > No. Authoratative data on your server (a locally configured zone) doesn't > require glue. I really should have scrapped that reply and started over--by the time I got to this part I realized that authority delegation is a matter of what is in the zone file, not what has been learned. >> Seems like the zone file shold have been replaced to reflect the >> authority change. > > Should have been removed...but if everything that should happen did > happen, things would be so much simpler. Trudat. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Time out for a terminology check--"resolver" vs "server".
On Sun, Feb 14, 2010 at 7:55 PM, Larry Sheldon wrote: > I understand that--but it the TTL is being managed correctly the server > answering authoritatively ought to stop doing so when the TTL runs out, > since it will not have had its authority renewed. The TTL can never "run out" on an authoritative nameserver, the TTL given for a query response is always the full TTL of the RR that a dns admin populated the zone with. The only way an authoritative nameserver should expire and become non-authoritative (without administrative action) for a record is the case where it is a slave server, and it fails to receive updates from the master for an entire zone before the "EXPIRE" period defined in the zone's SOA (in seconds) elapses. After the expire value, then, the zone is no longer authoritative on the slave. This is normally set to a very large number, such as 604800 or 2419200 (7 or 30 days, respectively). > The glue and all of that stuff won't expire at TTL=0? > I'll have to study that a bit. Which type of glue are you referring to? TTL only indicates the expiration time of resolver cached information after the resolver has already returned the complete response. Additional sections provided expire from resolver cache, when TTL of the RR in the additional secretion is decremented from zero. SOAs always have a TTL of zero, anyways. A TTL of zero just prohibits caching (and some unruly resolvers or web browsers violate the standard ignore the prohibition against caching).. DNS pinning, and they call this breach of standard a "security" feature. Also, BIND implements the EXPIRE value in the SOA. But other DNS server software applications widely ignore this value, and the zone stays authoritative on all servers, no matter how much time elapses between updates (in that case). -- -J
Re: Time out for a terminology check--"resolver" vs "server".
On Sun, 14 Feb 2010, Larry Sheldon wrote: I understand that--but it the TTL is being managed correctly the server answering authoritatively ought to stop doing so when the TTL runs out, since it will not have had its authority renewed. That's not how things work. If you configure bind to be authoratative for example.com, your zone file has a serial number, and various other SOA fields, some of which tell caching servers how long you'd like them to cache hits and misses. Some will totally ignore those TTLs, but that's an entirely different rant. Now consider example.com moves and the gtld-servers point NS for it at my server. I set it up differently than you did (different NS records, different A record IPs, etc.). Unless you remove example.com from your bind config, your server will still think it's authoratative for it. If your server is a locally used caching server and an authoratative server (as used to be quite common, esp. for smaller networks), the clients using your DNS server will still see the old example.com records from your outdated authoratative data. The glue and all of that stuff won't expire at TTL=0? No. Authoratative data on your server (a locally configured zone) doesn't require glue. Seems like the zone file shold have been replaced to reflect the authority change. Should have been removed...but if everything that should happen did happen, things would be so much simpler. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: Recommendations for router with routed copper gig-e ports?
I actually think the 912 is different then the 904 and 906, as I was discouraged from buying the 912, and I REALLY wanted the extra ports. That's not to say that the 904/906 doesn't have the same problems. I use it for a router with a bunch of connected networks, DHCP relay, and BGP. Other then the below mentioned DHCP-relay bug, and an FTP command bug (which was also quickly fixed) they have served us well. Eric RR Morin -Original Message- From: Jason Lixfeld [mailto:ja...@lixfeld.ca] Sent: Sunday, February 14, 2010 9:54 PM To: Eric Morin Cc: North American Network Operators Group Subject: Re: Recommendations for router with routed copper gig-e ports? The OS906 may be different than the OS912, but be warned that I had major issues with OS912 relating to LDP and OSPF. Constant crashes of both LDP and OSPF made the device totally unusable. We had to ship all 20 back to them. It was really messy. This was about 6 months ago, and their code may have been fixed, so YMMV. On 2010-02-14, at 8:47 PM, "Eric Morin" wrote: > I have found the MRV OS906 (6 port 10/100/1000/SFP + Eth OBM) to be a > very cost effective and an extremely flexible device. It's a linux > based > device with a router shell but all forwarding is done in hardware > (ASICs). It has a very flexible implementation of many L2 features > (QnQ, > inner or outer tag swapping, eth OAM, ERP) but also sports standard > routing switch features and protocols like BGP, OSPF, even IS-IS! > > The cost of the device is 1/4 of a 3560G (etc). > > MRV's support has been very good. We found a bug in the DHCP-Relay > function where it would not broadcast back to a client that > discovered/requested with the broadcast bit set. They provided a new > spin of code with the fix within days! > > http://www.mrv.com/product/MRV-OS-OS900-SDB > > I hope this helps > Eric RR Morin > > -Original Message- > From: Lorell Hathcock [mailto:lor...@hathcock.org] > Sent: Sunday, February 14, 2010 4:42 PM > To: 'North American Network Operators Group' > Subject: Recommendations for router with routed copper gig-e ports? > > All: > > > > I'm involved in a project where we are cutting over a WISP from > being a > single broadcast domain into the grownup real world of routing between > tower > nodes. Of course the equipment is all Mikrotik and the single > broadcast > domain was easy to implement, so that's why it was done this way. > > > > My problem on the redesign is I want to provide routed, copper gig-e > ports > at a reasonable price per port. > > > > My thought is to provide one copper gig-e port for all of the APs at a > tower > and a copper gig-e port for each backhaul to other towers (typically 2 > to > 4). On the core nodes, I want to have one fiber gig-e port for the > internet > connection. BGP would be implemented on the routers that connect to > the > internet. OSPF would be implemented on all of the backhaul ports. > > > > So number of routed, copper gig-e ports at each tower would be: > > > > 1 - AP network (need suggestion for cost effective gig-e switch) > > 2 to 4 - back haul ports > > 1 - internet port (on one out of every 4 towers or so) (and most > likely > fiber instead of copper) > > > > Does anyone have any suggestions? > > > > Sincerely, > > > > Lorell Hathcock > > > > OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | > lor...@officeconnect.net > > Texas State Security Contractor License | ONSSI Certified Channel > Partner > > Axis Communications Channel Partner | BICSI Corporate Member > > Leviton Authorized Installer > > > > > -- > This message has been scanned by MailScanner > > -- This message has been scanned by MailScanner
Re: Time out for a terminology check--"resolver" vs "server".
On 2/14/2010 7:48 PM, Scott Howard wrote: > On Sun, Feb 14, 2010 at 5:19 PM, Larry Sheldon wrote: >>> It is possibly to run both Authoritative and Recursive server on the >>> same IP, but it's generally not recommended for many reasons (the most >>> simple being that of stale data if your server is no longer the >>> correct nameserver for a domain, but it's still configured to be >>> authoritative for that domain). >> >> Seems like TTL management would take care of that but I think the issues >> of recursion are now different from the safe world I thought I lived in >> 20 years ago. > > TTL's play no part in how any Authoritative server answers a request. I understand that--but it the TTL is being managed correctly the server answering authoritatively ought to stop doing so when the TTL runs out, since it will not have had its authority renewed. > Consider what happens if your DNS server was authoritative for > example.com, and the .com nameservers pointed to you for that domain. > Your customer who owns the domain then changes the delegation to > another provider (and/or the domain expires, etc) but doesn't tell > you. > > At this point, your server is still answering all requests for > example.com - because that's what authoritative servers do. It won't > check to make sure that the domain is still delegated to it, and doing > so would make no sense in a generic sense (eg, it might be an internal > only domain, or testing a new domain that hasn't yet been delegated to > you, etc). The glue and all of that stuff won't expire at TTL=0? I'll have to study that a bit. Seems like the zone file shold have been replaced to reflect the authority change. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Recommendations for router with routed copper gig-e ports?
The OS906 may be different than the OS912, but be warned that I had major issues with OS912 relating to LDP and OSPF. Constant crashes of both LDP and OSPF made the device totally unusable. We had to ship all 20 back to them. It was really messy. This was about 6 months ago, and their code may have been fixed, so YMMV. On 2010-02-14, at 8:47 PM, "Eric Morin" wrote: I have found the MRV OS906 (6 port 10/100/1000/SFP + Eth OBM) to be a very cost effective and an extremely flexible device. It's a linux based device with a router shell but all forwarding is done in hardware (ASICs). It has a very flexible implementation of many L2 features (QnQ, inner or outer tag swapping, eth OAM, ERP) but also sports standard routing switch features and protocols like BGP, OSPF, even IS-IS! The cost of the device is 1/4 of a 3560G (etc). MRV's support has been very good. We found a bug in the DHCP-Relay function where it would not broadcast back to a client that discovered/requested with the broadcast bit set. They provided a new spin of code with the fix within days! http://www.mrv.com/product/MRV-OS-OS900-SDB I hope this helps Eric RR Morin -Original Message- From: Lorell Hathcock [mailto:lor...@hathcock.org] Sent: Sunday, February 14, 2010 4:42 PM To: 'North American Network Operators Group' Subject: Recommendations for router with routed copper gig-e ports? All: I'm involved in a project where we are cutting over a WISP from being a single broadcast domain into the grownup real world of routing between tower nodes. Of course the equipment is all Mikrotik and the single broadcast domain was easy to implement, so that's why it was done this way. My problem on the redesign is I want to provide routed, copper gig-e ports at a reasonable price per port. My thought is to provide one copper gig-e port for all of the APs at a tower and a copper gig-e port for each backhaul to other towers (typically 2 to 4). On the core nodes, I want to have one fiber gig-e port for the internet connection. BGP would be implemented on the routers that connect to the internet. OSPF would be implemented on all of the backhaul ports. So number of routed, copper gig-e ports at each tower would be: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | lor...@officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer -- This message has been scanned by MailScanner
Re: Time out for a terminology check--"resolver" vs "server".
On Sun, Feb 14, 2010 at 5:19 PM, Larry Sheldon wrote: >> It is possibly to run both Authoritative and Recursive server on the >> same IP, but it's generally not recommended for many reasons (the most >> simple being that of stale data if your server is no longer the >> correct nameserver for a domain, but it's still configured to be >> authoritative for that domain). > > Seems like TTL management would take care of that but I think the issues > of recursion are now different from the safe world I thought I lived in > 20 years ago. TTL's play no part in how any Authoritative server answers a request. Consider what happens if your DNS server was authoritative for example.com, and the .com nameservers pointed to you for that domain. Your customer who owns the domain then changes the delegation to another provider (and/or the domain expires, etc) but doesn't tell you. At this point, your server is still answering all requests for example.com - because that's what authoritative servers do. It won't check to make sure that the domain is still delegated to it, and doing so would make no sense in a generic sense (eg, it might be an internal only domain, or testing a new domain that hasn't yet been delegated to you, etc). If one of your clients queries the server - in the context of it being a recursive server - it will respond with your view of the world for example.com, which is incorrect. If the server was configured as authoritative only, and another server (or a different IP on the same server) was acting as the recursive server then your authoritative server will still return the incorrect answers if asked - but nobody will ever ask it for a domain that isn't correctly delegated to it. There are (poor) solutions to this, such as regular checks that all domains you're serving are actually delegated to you - but simply separating the functions is a far better solution. Scott.
RE: Recommendations for router with routed copper gig-e ports?
I have found the MRV OS906 (6 port 10/100/1000/SFP + Eth OBM) to be a very cost effective and an extremely flexible device. It's a linux based device with a router shell but all forwarding is done in hardware (ASICs). It has a very flexible implementation of many L2 features (QnQ, inner or outer tag swapping, eth OAM, ERP) but also sports standard routing switch features and protocols like BGP, OSPF, even IS-IS! The cost of the device is 1/4 of a 3560G (etc). MRV's support has been very good. We found a bug in the DHCP-Relay function where it would not broadcast back to a client that discovered/requested with the broadcast bit set. They provided a new spin of code with the fix within days! http://www.mrv.com/product/MRV-OS-OS900-SDB I hope this helps Eric RR Morin -Original Message- From: Lorell Hathcock [mailto:lor...@hathcock.org] Sent: Sunday, February 14, 2010 4:42 PM To: 'North American Network Operators Group' Subject: Recommendations for router with routed copper gig-e ports? All: I'm involved in a project where we are cutting over a WISP from being a single broadcast domain into the grownup real world of routing between tower nodes. Of course the equipment is all Mikrotik and the single broadcast domain was easy to implement, so that's why it was done this way. My problem on the redesign is I want to provide routed, copper gig-e ports at a reasonable price per port. My thought is to provide one copper gig-e port for all of the APs at a tower and a copper gig-e port for each backhaul to other towers (typically 2 to 4). On the core nodes, I want to have one fiber gig-e port for the internet connection. BGP would be implemented on the routers that connect to the internet. OSPF would be implemented on all of the backhaul ports. So number of routed, copper gig-e ports at each tower would be: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | lor...@officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer -- This message has been scanned by MailScanner
Re: Time out for a terminology check--"resolver" vs "server".
On 2/14/2010 6:21 PM, Scott Howard wrote: > A "resolver" is basically a client. > > There's two types of resolvers - recursive resolvers (that look after > doing the full resolution themselves - starting at the root servers > and working down), and "stub resolvers" which are only smart enough > pass the entire request onto another server to handle. > > On most system, the "code in your local machine" will be a stub > resolver. That's why you need to configure it to point to another > server that looks after the actual recursion for you. That is another piece that I had glossed over--the "client" side of a server. > > The "DNS Server" running at your ISP that your stub resolver connects > to is acting as both a server (to accept requests from your client), > and as a resolver (to actually resolve those requests), and almost > certainly also as a cache for results. For simplicity, many people > simply refer to them as Resolvers, whilst others call them Recursive > servers or Caching servers. Calling any form of server a "resolver" seems new to me--or my lack of understanding is older that I like to admit. > > The server actually answering the requests for your domain is an > Authoritative Server. An Authorative-only server doesn't ever act as a > client, so it isn't a resolver. > > It is possibly to run both Authoritative and Recursive server on the > same IP, but it's generally not recommended for many reasons (the most > simple being that of stale data if your server is no longer the > correct nameserver for a domain, but it's still configured to be > authoritative for that domain). Seems like TTL management would take care of that but I think the issues of recursion are now different from the safe world I thought I lived in 20 years ago. Thanks. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: Time out for a terminology check--"resolver" vs "server".
On 2/14/2010 6:10 PM, Rob Austein wrote: > At Sun, 14 Feb 2010 18:02:48 -0600, Laurence F Sheldon, Jr wrote: >> >> I thought I understood but from recent contexts here it is clear that I >> do not. >> >> I thought a resolver was code in your local machine that provide >> hostname (FQDN?), given address; or address, given host name (with >> assists to build FQDN). >> >> And I thought a "server" was a separate program, might be on the same >> machine, might be on another machine (might be on the local net, might >> be distant) that the resolver code called for information that was not >> in local cache. >> >> Just what is the straight scoop? > > No doubt Olafur will beat me up yet again for not having written the > DNS lexicon years ago, but: > > - A "resolver" is something that implements the "resolver" (ie, > client) role in the DNS protocol. It might be a stub resolver, the > client side of a recursive nameserver, a pure iterative resolver, > > > The defining characteristic is that it send queries (QR=0) and > receives responses (QR=1). > > - A "name sever" is something that implements the "nameserver" (ie, > server) role in the DNS protocol. It might be an authoritative > nameserver, the server side of a recursive nameserver, > > The defining characteristic is that it receives queries (QR=0) and > sends responses (QR=1). > > Clear enough? Yes--tracks with what I thought, pretty much--I was missing the clientness of the resolver code to go with the serverness of the server. > Mapping protocol definitions onto the plethora of terms used by > operators in the field is left as an exercise for the reader, no > sarcasm intended. DNS is an old protocol, there are an awful lot of > people who think they understand it, I am one of those is sure he understands it--which belief crumbles when I try to explain it to somebody else. and each of those people has > their own set of terms that they're comfortable using. The > definitions above are what I rammed through the IETF during several > rounds of standards writing, but I would be the first to admit that > not everybody uses the terms the same way as I do. DNS arcana is one of the things that somebody should document on the internet-history list while there are still people around who can do so with some authority. Thanks. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
abuse reporting (was Re: Yahoo abuse)
On Feb 11, 2010, at 6:45 PM, James Hess wrote: > That said, XML makes a terrible data interchange format for > communications where humans are supposed to understand the message, > using standard software (such as a legacy e-mail client). Exactly what we said when developing ARF. -- J.D. Falk Return Path Inc
Re: Time out for a terminology check--"resolver" vs "server".
A "resolver" is basically a client. There's two types of resolvers - recursive resolvers (that look after doing the full resolution themselves - starting at the root servers and working down), and "stub resolvers" which are only smart enough pass the entire request onto another server to handle. On most system, the "code in your local machine" will be a stub resolver. That's why you need to configure it to point to another server that looks after the actual recursion for you. The "DNS Server" running at your ISP that your stub resolver connects to is acting as both a server (to accept requests from your client), and as a resolver (to actually resolve those requests), and almost certainly also as a cache for results. For simplicity, many people simply refer to them as Resolvers, whilst others call them Recursive servers or Caching servers. The server actually answering the requests for your domain is an Authoritative Server. An Authorative-only server doesn't ever act as a client, so it isn't a resolver. It is possibly to run both Authoritative and Recursive server on the same IP, but it's generally not recommended for many reasons (the most simple being that of stale data if your server is no longer the correct nameserver for a domain, but it's still configured to be authoritative for that domain). Scott. On Sun, Feb 14, 2010 at 4:02 PM, Larry Sheldon wrote: > I thought I understood but from recent contexts here it is clear that I > do not. > > I thought a resolver was code in your local machine that provide > hostname (FQDN?), given address; or address, given host name (with > assists to build FQDN). > > And I thought a "server" was a separate program, might be on the same > machine, might be on another machine (might be on the local net, might > be distant) that the resolver code called for information that was not > in local cache. > > Just what is the straight scoop? > -- > "Government big enough to supply everything you need is big enough to > take everything you have." > > Remember: The Ark was built by amateurs, the Titanic by professionals. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > >
Re: Time out for a terminology check--"resolver" vs "server".
At Sun, 14 Feb 2010 18:02:48 -0600, Laurence F Sheldon, Jr wrote: > > I thought I understood but from recent contexts here it is clear that I > do not. > > I thought a resolver was code in your local machine that provide > hostname (FQDN?), given address; or address, given host name (with > assists to build FQDN). > > And I thought a "server" was a separate program, might be on the same > machine, might be on another machine (might be on the local net, might > be distant) that the resolver code called for information that was not > in local cache. > > Just what is the straight scoop? No doubt Olafur will beat me up yet again for not having written the DNS lexicon years ago, but: - A "resolver" is something that implements the "resolver" (ie, client) role in the DNS protocol. It might be a stub resolver, the client side of a recursive nameserver, a pure iterative resolver, The defining characteristic is that it send queries (QR=0) and receives responses (QR=1). - A "name sever" is something that implements the "nameserver" (ie, server) role in the DNS protocol. It might be an authoritative nameserver, the server side of a recursive nameserver, The defining characteristic is that it receives queries (QR=0) and sends responses (QR=1). Clear enough? Mapping protocol definitions onto the plethora of terms used by operators in the field is left as an exercise for the reader, no sarcasm intended. DNS is an old protocol, there are an awful lot of people who think they understand it, and each of those people has their own set of terms that they're comfortable using. The definitions above are what I rammed through the IETF during several rounds of standards writing, but I would be the first to admit that not everybody uses the terms the same way as I do.
Re: History of 4.2.2.2. What's the story?
On Feb 14, 2010, at 6:55 PM, John Orthoefer wrote: > At the time I was involved it did have an SLA, and was considered critical > infrastructure for Genuitity customers. Once we started to deploy 4.2.2.1, > we gave customers time to swap over, but we started turning off our existing > DNS servers. Sorry for the confusion, I should have said "for non-customers of L3". I was responding the statement that the name servers were controlled by "*one* external route". If you are a customer, IGP matters, not BGP, and SLAs obviously are a different situation. For people who are not customers, SLAs are unusual. -- TTFN, patrick > One reason we did it was that we kept having to deploy more servers, and > getting customers to swing there hosts over to the new machines was all but > impossible.With NetNews, and SMTP we used a Cisco Distributed Director. > But we needed another solution for DNS. > > johno > > On Feb 14, 2010, at 5:20 PM, Patrick W. Gilmore wrote: > >>> >> >> It's an open recursive name server, it is free, has no SLA, and is not >> critical infrastructure. >> >> >> > >
Time out for a terminology check--"resolver" vs "server".
I thought I understood but from recent contexts here it is clear that I do not. I thought a resolver was code in your local machine that provide hostname (FQDN?), given address; or address, given host name (with assists to build FQDN). And I thought a "server" was a separate program, might be on the same machine, might be on another machine (might be on the local net, might be distant) that the resolver code called for information that was not in local cache. Just what is the straight scoop? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: dns interceptors
On Feb 14, 2010, at 6:54 PM, Mark Andrews wrote: > > In message , Sean > Donel > an writes: >> On Sun, 14 Feb 2010, Randy Bush wrote: ssh tunnels to IP address >>> i am often on funky networks in funky places. e.g. the wireless in >>> changi really sucked friday night. if i ssh tunneled, it would multiply >>> the suckiness as tcp would have puked at the loss rate. >>> smb whacked me that i should use non-tcp tunnels. >> >> Their network, their rules; your network, your rules; my network, my >> rules. > > There is also "truth in advertising" laws. If they advertise > "Internet" access then you should get the "Internet" not a cut down / > filtered version. Yes -- and as a reward for your expertise, you get to explain the problem with a transparent DNS proxy to the judge. For bonus points, explain it to a jury --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: History of 4.2.2.2. What's the story?
At the time I was involved it did have an SLA, and was considered critical infrastructure for Genuitity customers. Once we started to deploy 4.2.2.1, we gave customers time to swap over, but we started turning off our existing DNS servers. One reason we did it was that we kept having to deploy more servers, and getting customers to swing there hosts over to the new machines was all but impossible.With NetNews, and SMTP we used a Cisco Distributed Director. But we needed another solution for DNS. johno On Feb 14, 2010, at 5:20 PM, Patrick W. Gilmore wrote: >> > > It's an open recursive name server, it is free, has no SLA, and is not > critical infrastructure. > > >
Re: dns interceptors
In message , Sean Donel an writes: > On Sun, 14 Feb 2010, Randy Bush wrote: > >> ssh tunnels to IP address > > i am often on funky networks in funky places. e.g. the wireless in > > changi really sucked friday night. if i ssh tunneled, it would multiply > > the suckiness as tcp would have puked at the loss rate. > > smb whacked me that i should use non-tcp tunnels. > > Their network, their rules; your network, your rules; my network, my > rules. There is also "truth in advertising" laws. If they advertise "Internet" access then you should get the "Internet" not a cut down / filtered version. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: History of 4.2.2.2. What's the story?
I'll add to what Johno writes. I worked on the anycast routing side to the server side which he describes. The 4.2.0.0/16 prefix was set aside by John Hawkinson in our reservation system under the label "Numerology" since he had the wisdom to see that the numbers in themselves could be valuable. He really wanted 4.4.4.4. Unfortunately someone had already taken 4.4.0.0/16 for some of our first DSL assignments (when it still seemed suprising that anyone would need tens of thousands of IP addresses at a shot). The first two /16s in 4/8 were already used for infrastucture. I don't necessarily recall the service being intended for non-customers (hence no care about seeing multiple paths outside the AS which originates it.) The real gains were: - More graceful failover - Shorter trips to resolvers (quicker lookups) - Ability to split load w/o re-configuring clients That's the story. Others did it before and since but jhawk really deserves the credit for squatting on super-easy to type and remember addresses. I use it to this day for a quick thing to ping when I need to test connectivity. Cheers, Tony On Sun, Feb 14, 2010 at 09:16:13AM -0500, John Orthoefer wrote: > Since I'm watching B5 again on DVD > > I was there at the dawning of the age of 4.2.2.1 :) > > We did it, and we I mean Brett McCoy and my self. But most of the > credit/blame goes to Brett... I helped him, but at the time I was > mostly working on getting out Mail relays working right. This was > about 12 years ago, about 1998, I left Geunitity in 2000, and am back > at BBN/Raytheon now. I remember we did most of the work after we > moved out of Cambridge and into Burlington. > > Genuity/GTEI/Planet/BBN owned 4/8. Brett went looking for an IP that > was simple to remember, I think 4.4.4.4 was in use by neteng already. > But it was picked to be easy to remember, I think jhawk had put a hold > on the 4.2.2.0/24 block, we got/grabbed 3 address 4.2.2.1, 4.2.2.2, > and 4.2.2.3 so people had 3 address to go to.At the time people > had issues with just using a single resolver. We also had issues with > both users and registers since clearly they aren't geographically > diverse, trying to explain routing tricks to people KNOW all IPs come > in and are routed as Class A/B/C blocks is hard. > > NIC.Near.Net which was our primary DNS server for years before I > transferred to planet from BBN. It wasn't even in 4/8, I think it was > 128.89 (BBN Corp space), but I'm not sure. BBN didn't start to use > 4/8 till the Planet build out, and NIC.near.net predates that by at > least 10 years. > > I still have the power cord from NIC.near.net in my basement. That > machine grew organically with every service known to mankind running > on it, and special one-off things for customers on it. It took us > literally YEARS to get that machine turned off, when we finally got it > off I took the power cord so no one would help us by turning it back > on, I gave the cord to Chris Yetman, who was the director of > operations and told him if a customer screams he has the power to turn > it back on. A year or so later, he gave the cord back to me. > > Yes we set up 4.2.2.1 as a public resolver. We figured trying to > filter it was larger headache than just making it public. > > It was always pretty robust due to the BIND code, thanks to ISC, and > the fact it was always IPV4 AnyCast. > > I don't know about now, but originally it was IPV4 AnyCast. Each > server advertised a routes for 4.2.2.1, .2, and .3 at different costs > and the routers would listen to the routes. Originally the start up > code was, basically: advertise route to 4.2.2.1, 4.2.2.2, and 4.2.2.3 > run bind in foreground mode > drop route to 4.2.2.1, 4.2.2.2, and 4.2.2.3 > > then we had a Tivoli process that tried to restart bind, but rate > limited the restarts. But that way if the bind died the routes would > drop. > > johno > > On Feb 14, 2010, at 4:16 AM, Sean Reifschneider wrote: > > > I've wondered about this for years, but only this evening did I start > > searching for details. And I really couldn't find any. > > > > Can anyone point me at distant history about how 4.2.2.2 came to be, in my > > estimation, the most famous DNS server on the planet? > > > > I know that it was originally at BBN, what I'm looking for is things like: > > > > How the IP was picked. (I'd guess it was one of the early DNS servers, > > and the people behind it realized that if there was one IP address > > that really needed to be easy to remember, it was the DNS server, > > for obvious reasons). > > Was it always meant to be a public resolver? > > How it continued to remain an open resolver, even in the face of > > amplifier attacks using DNS resolvers. Perhaps it has had > > rate-limiting on it for a long time. > > There's a lot of conjecture about it using anycast, anyone know anything > > about it's current c
Re: dns interceptors
On Sun, 14 Feb 2010, Randy Bush wrote: ssh tunnels to IP address i am often on funky networks in funky places. e.g. the wireless in changi really sucked friday night. if i ssh tunneled, it would multiply the suckiness as tcp would have puked at the loss rate. smb whacked me that i should use non-tcp tunnels. Their network, their rules; your network, your rules; my network, my rules. If you visit lots of funky places, its probably time to learn about tunnelling protocols. If you don't like their network rules, tunnel to a different network with rules you prefer. Ports 80/443 seem to work as the universal tunnelling ports, along with SSH, VPN, PPTP, IPnIP/IPSEC, etc. Sometimes proxy-tunnel software which encapsulates packets inside HTTP works. AOL and SKYPE seem to successfully tunnel through a lot of stuff. Of course, if you are on a network which doesn't want allow tunnels, e.g. an internal enterprise network, you may not want to do that. Per-application stuff work sometimes (DNSSEC/TSIG-forwarders, HTTPS, etc), but when allowed I immediately create a tunnel and don't spend time debugging local networks. Some people always use tunnels even when using networks such as the NANOG or IETF conference networks.
Re: History of 4.2.2.2. What's the story?
On 2010-02-14, at 17:43, Mark Andrews wrote: Using three consecutive addresses doesn't remove single points of failure in the routing system. That depends on how the routes for those destinations are chosen, and what routing system you're talking about. For distribution of a service using anycast inside a single AS, and with one route per service, it makes no difference whether the addresses are adjacent. Two /24 routes are no more stable than two /32 routes within an IGP. There's no prefix filtering convention to accommodate, here. If their goal is distribute a service for the benefit of their own = customers, then keeping all anycast nodes associated with that service = on-net seems entirely sensible. Which only helps if *all* customers of those servers are also on net. Whether it helps depends on what Level3's goals are. This is not public infrastructure; this is a service operated by a commercial company. For what it's worth, I have never heard of an ISP, big or small, deciding to place resolvers used by their customers in someone else's network. Perhaps I just need to get out more. Joe
Re: Recommendations for router with routed copper gig-e ports?
Chuck Anderson wrote: On Sun, Feb 14, 2010 at 02:41:51PM -0600, Lorell Hathcock wrote: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Juniper EX3200. L2/L3 line rate GigE, partial or full PoE options available. Fiber uplink options. 24T version w/8 ports of PoE. The last 4 copper ports are shared with 1 Gig uplink module ports (but they aren't shared if you use 10 GigE uplink modules). [1]http://www.juniper.net/us/en/local/pdf/datasheets/1000216-en.pdf Well just make sure the current Mikrotik's in place don't have gig-e ports as the newer Mikrotik's do. In that case converting over to a routing environment should be as simple as some software changes in the Mikrotik's. As for fiber you'd need some media converters. We run a Mikrotik's in our network using OSPF with a bunch of Cisco's and Riverstone routers without any problems. Bret References 1. http://www.juniper.net/us/en/local/pdf/datasheets/1000216-en.pdf
Re: History of 4.2.2.2. What's the story?
In message , Scott Howard writes: > I'd also be interested in knowing where you consider the "single > points of failure" for their announcement of 4/8 is, but that's > probably for another thread... You mean you have never seen traffic following a route annuncement go into a black hole. :-) > Scott. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: History of 4.2.2.2. What's the story?
On Sun, Feb 14, 2010 at 2:37 PM, Richard Golodner wrote: > Cisco tech support tells their customers (us) to use it when testing. > Perhaps this is not such a good practice. No doubt because they are easier to remember than Cisco's own two "public" DNS resolvers : 64.102.255.44 128.107.241.185 Scott.
Re: History of 4.2.2.2. What's the story?
On Feb 14, 2010, at 5:43 PM, Mark Andrews wrote: > In message <10be7b64-46ff-46d8-a428-268897413...@hopcount.ca>, Joe Abley > writes > : >> On 2010-02-14, at 17:17, Mark Andrews wrote: >> >>> I don't care what internal routing tricks are used, they are still >>> under the *one* external route and as such subject to single points >>> of failure and as such don't have enough independence. >> >> Are you asserting architectural control over what Level3 decide to do = >> with their own servers, Mark? :-) > > No. The reason for multiple nameservers is to remove single points > of failures. Using three consecutive addresses doesn't remove > single points of failure in the routing system. > >> If their goal is distribute a service for the benefit of their own = >> customers, then keeping all anycast nodes associated with that service = >> on-net seems entirely sensible. > > Which only helps if *all* customers of those servers are also on net. All _customers_ are. People using a service which was not announced or support are not customers. -- TTFN, patrick
Re: History of 4.2.2.2. What's the story?
On Sun, Feb 14, 2010 at 2:17 PM, Mark Andrews wrote: > I don't care what internal routing tricks are used, they are still > under the *one* external route and as such subject to single points > of failure and as such don't have enough independence. Where has Level 3 ever claimed that these servers were ever for *external* use? As a Level 3 customer who uses these servers, I'm seeing multiple *internal* routes to these servers. Of course, if 4/8 disappears from the global routing tables then Level 3 has a bit bigger problem than their DNS resolvers not being accessible from non-customers. I'd also be interested in knowing where you consider the "single points of failure" for their announcement of 4/8 is, but that's probably for another thread... Scott.
Re: Recommendations for router with routed copper gig-e ports?
On Sun, Feb 14, 2010 at 02:41:51PM -0600, Lorell Hathcock wrote: > 1 - AP network (need suggestion for cost effective gig-e switch) > > 2 to 4 - back haul ports > > 1 - internet port (on one out of every 4 towers or so) (and most likely > fiber instead of copper) > > > > Does anyone have any suggestions? Juniper EX3200. L2/L3 line rate GigE, partial or full PoE options available. Fiber uplink options. 24T version w/8 ports of PoE. The last 4 copper ports are shared with 1 Gig uplink module ports (but they aren't shared if you use 10 GigE uplink modules). http://www.juniper.net/us/en/local/pdf/datasheets/1000216-en.pdf
Re: History of 4.2.2.2. What's the story?
In message <10be7b64-46ff-46d8-a428-268897413...@hopcount.ca>, Joe Abley writes : > On 2010-02-14, at 17:17, Mark Andrews wrote: > > > I don't care what internal routing tricks are used, they are still > > under the *one* external route and as such subject to single points > > of failure and as such don't have enough independence. > > Are you asserting architectural control over what Level3 decide to do = > with their own servers, Mark? :-) No. The reason for multiple nameservers is to remove single points of failures. Using three consecutive addresses doesn't remove single points of failure in the routing system. > If their goal is distribute a service for the benefit of their own = > customers, then keeping all anycast nodes associated with that service = > on-net seems entirely sensible. Which only helps if *all* customers of those servers are also on net. > Joe -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: History of 4.2.2.2. What's the story?
On Sun, 2010-02-14 at 17:20 -0500, Patrick W. Gilmore wrote: > Besides, it is quicker / better to use your local ISP's RNS. If > something goes wrong, you can fall back to OpenDNS or L3, and, of > course, yell at the _company_you_are_paying_ when their stuff doesn't > work. :) The best advice I have read all day. I have recently been on a few networks that will not allow 4.2.2.2 to resolve for the clients. Cisco tech support tells their customers (us) to use it when testing. Perhaps this is not such a good practice. Patrick is correct. Use your own stuff and yell when it does not work.
Re: History of 4.2.2.2. What's the story?
On 2010-02-14, at 17:17, Mark Andrews wrote: > I don't care what internal routing tricks are used, they are still > under the *one* external route and as such subject to single points > of failure and as such don't have enough independence. Are you asserting architectural control over what Level3 decide to do with their own servers, Mark? :-) If their goal is distribute a service for the benefit of their own customers, then keeping all anycast nodes associated with that service on-net seems entirely sensible. Joe
Re: History of 4.2.2.2. What's the story?
On Feb 14, 2010, at 5:17 PM, Mark Andrews wrote: > In message <182e6e76-f12a-41d9-800a-e5e40f3c3...@direwolf.com>, John > Orthoefer > writes: >> Genuity/GTEI/Planet/BBN owned 4/8. Brett went looking for an IP that = >> was simple to remember, I think 4.4.4.4 was in use by neteng already. = >> But it was picked to be easy to remember, I think jhawk had put a hold = >> on the 4.2.2.0/24 block, we got/grabbed 3 address 4.2.2.1, 4.2.2.2, and = >> 4.2.2.3 so people had 3 address to go to.At the time people had = >> issues with just using a single resolver. We also had issues with both = >> users and registers since clearly they aren't geographically diverse, = >> trying to explain routing tricks to people KNOW all IPs come in and are = >> routed as Class A/B/C blocks is hard. > > I don't care what internal routing tricks are used, they are still > under the *one* external route and as such subject to single points > of failure and as such don't have enough independence. It's an open recursive name server, it is free, has no SLA, and is not critical infrastructure. Besides, it is quicker / better to use your local ISP's RNS. If something goes wrong, you can fall back to OpenDNS or L3, and, of course, yell at the _company_you_are_paying_ when their stuff doesn't work. :) -- TTFN, patrick
Re: History of 4.2.2.2. What's the story?
In message <182e6e76-f12a-41d9-800a-e5e40f3c3...@direwolf.com>, John Orthoefer writes: > Genuity/GTEI/Planet/BBN owned 4/8. Brett went looking for an IP that = > was simple to remember, I think 4.4.4.4 was in use by neteng already. = > But it was picked to be easy to remember, I think jhawk had put a hold = > on the 4.2.2.0/24 block, we got/grabbed 3 address 4.2.2.1, 4.2.2.2, and = > 4.2.2.3 so people had 3 address to go to.At the time people had = > issues with just using a single resolver. We also had issues with both = > users and registers since clearly they aren't geographically diverse, = > trying to explain routing tricks to people KNOW all IPs come in and are = > routed as Class A/B/C blocks is hard. I don't care what internal routing tricks are used, they are still under the *one* external route and as such subject to single points of failure and as such don't have enough independence. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: History of 4.2.2.2. What's the story?
On Sun, Feb 14, 2010 at 1:19 PM, Sean Reifschneider wrote: >> Why "conjecture"? Examining the /32s from inside and outside of 3356 > > I said conjecture because every person I found in my searches said things > like "I think it might be anycasted" or "they could be using anycast". > Until this thread, I didn't see any that spoke with authority on the > subject. http://www.traceroute.org (and/or http://lg.level3.net, etc) will show pretty readily confirm that it's anycast. They will also show that in some parts of the world the various 4.2.2.1-6 addresses go to different locations. eg, from Level 3 in London I'm seeing 4.2.2.1, .3 and .5 going to London, but .2, .4 and .6 all go to Frankfurt. Personally I've moved away from using 4.2.2.1 and .2 after we had a few issues with them, especially in Europe. 4.2.2.5 and .6 seem to be far more stable, although obviously that might vary depending on region. Scott.
Re: History of 4.2.2.2. What's the story?
On 02/14/2010 07:16 AM, John Orthoefer wrote: > Since I'm watching B5 again on DVD Awesome. Thanks for taking the time to reply, I really enjoyed the story. Have fun with the B5. The only time I watched it was on a VHS borrowed from a friend. It was a 3'x3' cabinet full of them. :-) Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability signature.asc Description: OpenPGP digital signature
Re: History of 4.2.2.2. What's the story?
On 02/14/2010 07:41 AM, Joe Provo wrote: > I don't think anyone else can help you determine your estimaation... Sorry, I was being kind of flippant and paying homage to the "Peggy Hill" character in _King_of_the_Hill_. > That is a question for folks at L3. Any publicly-sharable data might > be interesting presentation-fodder. Good idea, I'll have to see if I have any links into L3 that can help. > Why "conjecture"? Examining the /32s from inside and outside of 3356 I said conjecture because every person I found in my searches said things like "I think it might be anycasted" or "they could be using anycast". Until this thread, I didn't see any that spoke with authority on the subject. Thanks for the reply. Sean -- Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability signature.asc Description: OpenPGP digital signature
Re: Recommendations for router with routed copper gig-e ports?
We use Cisco WS-3560G-24-PS-S (Catalyst 3560G's with POE Ports). Provides POE on each port too to eliminate having to use POE bricks to radios. We actually give each AP it's own group. It's better to break them all up rather than keep them in their own broadcast domain, because from subscriber to subscriber, you can still have a big broadcast problem that could hose the entire tower. we run backhauls off of it too on different ports, and it comes with 4 ports that you can use to plug in different modules for fiber. YMMV. -S Lorell Hathcock wrote: > All: > > > > I'm involved in a project where we are cutting over a WISP from being a > single broadcast domain into the grownup real world of routing between tower > nodes. Of course the equipment is all Mikrotik and the single broadcast > domain was easy to implement, so that's why it was done this way. > > > > My problem on the redesign is I want to provide routed, copper gig-e ports > at a reasonable price per port. > > > > My thought is to provide one copper gig-e port for all of the APs at a tower > and a copper gig-e port for each backhaul to other towers (typically 2 to > 4). On the core nodes, I want to have one fiber gig-e port for the internet > connection. BGP would be implemented on the routers that connect to the > internet. OSPF would be implemented on all of the backhaul ports. > > > > So number of routed, copper gig-e ports at each tower would be: > > > > 1 - AP network (need suggestion for cost effective gig-e switch) > > 2 to 4 - back haul ports > > 1 - internet port (on one out of every 4 towers or so) (and most likely > fiber instead of copper) > > > > Does anyone have any suggestions? > > > > Sincerely, > > > > Lorell Hathcock > > > > OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | > lor...@officeconnect.net > > Texas State Security Contractor License | ONSSI Certified Channel Partner > > Axis Communications Channel Partner | BICSI Corporate Member > > Leviton Authorized Installer > > > >
Re: History of 4.2.2.2. What's the story?
* John Levine: >>It was always pretty robust due to the BIND code, thanks to ISC, and >>the fact it was always IPV4 AnyCast. > > $ asp 4.2.2.2 # look it up in routeviews > 4.0.0.0/9 ASN 3356, path 3549 -> 3356 > > Wow, that's a heck of an anycast block. You can do anycast with your IGP, too. 8-)
Re: dns interceptors
>Hrm.. Maybe I misunderstood. Are the packets being intercepted, or >is the problem the local resolvers? Both, probably. Hotel networks often intercept all port 53 traffic not out of malice, but so that they won't get support calls from people whose PCs have poorly configured DNS often pointing at caches that won't accept requests from random places. Of course, once they do that, it's hard to resist the pressure from the marketers to Enance their User Experience. R's, John
Recommendations for router with routed copper gig-e ports?
All: I'm involved in a project where we are cutting over a WISP from being a single broadcast domain into the grownup real world of routing between tower nodes. Of course the equipment is all Mikrotik and the single broadcast domain was easy to implement, so that's why it was done this way. My problem on the redesign is I want to provide routed, copper gig-e ports at a reasonable price per port. My thought is to provide one copper gig-e port for all of the APs at a tower and a copper gig-e port for each backhaul to other towers (typically 2 to 4). On the core nodes, I want to have one fiber gig-e port for the internet connection. BGP would be implemented on the routers that connect to the internet. OSPF would be implemented on all of the backhaul ports. So number of routed, copper gig-e ports at each tower would be: 1 - AP network (need suggestion for cost effective gig-e switch) 2 to 4 - back haul ports 1 - internet port (on one out of every 4 towers or so) (and most likely fiber instead of copper) Does anyone have any suggestions? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 713-992-2343 (f) | lor...@officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer
Re: History of 4.2.2.2. What's the story?
On Sun, Feb 14, 2010 at 12:43:12PM -0600, John Palmer (NANOG Acct) wrote a message of 42 lines which said: > A more useful resolver is ASLAN [199.5.157.128] which is an > inclusive namespace resolver which shows users a complete map of the > internet, There are many crooks which sell dummy TLDs. At least, they make an effort to have more than two name servers for the root. But 199.5.157.128 is better, it does not just add dummy TLDs, it adds every possible TLD: % dig @199.5.157.128 A www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O ; <<>> DiG 9.5.1-P3 <<>> @199.5.157.128 A www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53344 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O. IN A ;; ANSWER SECTION: www.TJTYRMYYT67DFR453.FFDD5GCXXFFRA8O. 7195 IN A 199.5.157.33 ;; AUTHORITY SECTION: . 87988 IN NS b.worldroot.net. . 87988 IN NS a.worldroot.net. ;; Query time: 146 msec ;; SERVER: 199.5.157.128#53(199.5.157.128) ;; WHEN: Sun Feb 14 21:28:54 2010 ;; MSG SIZE rcvd: 125
Re: History of 4.2.2.2. What's the story?
On 2/14/10 11:43 AM, John Palmer (NANOG Acct) wrote: 4.2.2.2 is stunted just like any other resolvers that use only the USG root. A more useful resolver is ASLAN [199.5.157.128] which is an inclusive namespace resolver which shows users a complete map of the internet, not just what ICANN wants them to see. I feel a headache coming on... Is this more of the fun from years ago where everyone thought it would be great to create a bunch of custom TLDs then try and convince everyone to use their name servers to 'enable' these (for lack of a better word) site-local domains? I tried the OpenDNS koolaid, and well, was horribly disappointed. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: History of 4.2.2.2. What's the story?
On 14. feb. 2010, at 19.43, John Palmer (NANOG Acct) wrote: > 4.2.2.2 is stunted just like any other resolvers that use only the USG root. > A more useful resolver is ASLAN [199.5.157.128] which is an inclusive > namespace resolver which shows users a complete map of the internet, not just > what ICANN wants them > to see. So you don't think that 4.2.2.2, being easier then 199.5.157.128 to remember, has something to do with that? -- Joachim Tingvold joac...@tingvold.com
Re: dns interceptors
Larry Sheldon(larryshel...@cox.net)@Sun, Feb 14, 2010 at 11:54:25AM -0600: > On 2/14/2010 11:42 AM, Patrick W. Gilmore wrote: > > On Feb 14, 2010, at 12:37 PM, Jason Frisvold wrote: > >> On Feb 13, 2010, at 4:58 PM, Randy Bush wrote: > >>> i am often on funky networks in funky places. e.g. the wireless in > >>> changi really sucked friday night. if i ssh tunneled, it would multiply > >>> the suckiness as tcp would have puked at the loss rate. > >> > >> You can always run your own local resolver... Or is there a reason that's > >> unacceptable? > > > > How does that help? It still sends port 53 requests to the authorities, > > which will be intercepted. > > I don't have access to a trustable network to tunnel to. (Or at least I > don't know how to.) http://www.cotse.net/ provides that kind of service at a pretty reasonable price. I have no financial interest in that service. I know the guy who runs it, and I've used the service before and been really happy with it. -- Bill Weiss
Re: History of 4.2.2.2. What's the story?
4.2.2.2 is stunted just like any other resolvers that use only the USG root. A more useful resolver is ASLAN [199.5.157.128] which is an inclusive namespace resolver which shows users a complete map of the internet, not just what ICANN wants them to see. - Original Message - From: "Steve Ryan" To: Sent: Sunday, February 14, 2010 6:43 AM Subject: Re: History of 4.2.2.2. What's the story? I think around 10 years ago Slashdot had a few stories (and still do, actually) about how great these resolvers were. I think that propelled quite a bit of their growth and popularity. On 2/14/2010 1:16 AM, Sean Reifschneider wrote: I've wondered about this for years, but only this evening did I start searching for details. And I really couldn't find any. Can anyone point me at distant history about how 4.2.2.2 came to be, in my estimation, the most famous DNS server on the planet? I know that it was originally at BBN, what I'm looking for is things like: How the IP was picked. (I'd guess it was one of the early DNS servers, and the people behind it realized that if there was one IP address that really needed to be easy to remember, it was the DNS server, for obvious reasons). Was it always meant to be a public resolver? How it continued to remain an open resolver, even in the face of amplifier attacks using DNS resolvers. Perhaps it has had rate-limiting on it for a long time. There's a lot of conjecture about it using anycast, anyone know anything about it's current configuration? So, if anyone has any stories about 4.2.2.2, I'd love to hear them. Thanks, Sean
Re: dns interceptors
I run openvpn on my linux box to do exactly that. Already running apache/bind/postfix/xmpp with legacy Im bridges so adding openvpn was a logical next step. #protip run it on port 443. :) makes it much easier to get around firewalls. Even with deep packet inspection, SSL traffic is expected on that port. I have business class att dsl and 7 static ip addresses. I run a dell optiplex desktop 24x7 and it sips power. You could also just host services in a Colo for around 20.00 a month for dedicated virtual server. You would probably pay that anyway to a company who provided the services you mentioned. Lots of risk with being smtp relay for the world. Just ask yahoo/sbc who provide large swaths of southern California with net access. They provide dns and authenticated/encrypted smtp outbound and charge 14.95 a month for the cheap package. Sent via BlackBerry from T-Mobile
Re: dns interceptors
On Feb 14, 2010, at 12:53 PM, Jason Frisvold wrote: > On Feb 14, 2010, at 12:42 PM, Patrick W. Gilmore wrote: >> How does that help? It still sends port 53 requests to the authorities, >> which will be intercepted. > > Hrm.. Maybe I misunderstood. Are the packets being intercepted, or is the > problem the local resolvers? While I admit I have not read every post in the thread, I note the subject line. :) > Well, in either case, another option would be to use something like openvpn, > cisco vpn, etc. with very limited routes. Set it up so only your dns traffic > is sent over the tunnel. Then you can still use the local network, crappy as > it may be, without having to deal with the added overhead of ssh and the like. ISTM Randy's comment about SSH tunnels would have the same effect. -- TTFN, patrick
Re: dns interceptors
On 2/14/2010 11:42 AM, Patrick W. Gilmore wrote: > On Feb 14, 2010, at 12:37 PM, Jason Frisvold wrote: >> On Feb 13, 2010, at 4:58 PM, Randy Bush wrote: >>> i am often on funky networks in funky places. e.g. the wireless in >>> changi really sucked friday night. if i ssh tunneled, it would multiply >>> the suckiness as tcp would have puked at the loss rate. >> >> You can always run your own local resolver... Or is there a reason that's >> unacceptable? > > How does that help? It still sends port 53 requests to the authorities, > which will be intercepted. I don't have access to a trustable network to tunnel to. (Or at least I don't know how to.) I wish some enteprenure would start a subscription service to provide honest DNS (and maybe authenticatrd outbound email) that I could point to regardless of to where I may have wandered. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Re: dns interceptors
On Feb 14, 2010, at 12:42 PM, Patrick W. Gilmore wrote: > How does that help? It still sends port 53 requests to the authorities, > which will be intercepted. Hrm.. Maybe I misunderstood. Are the packets being intercepted, or is the problem the local resolvers? Well, in either case, another option would be to use something like openvpn, cisco vpn, etc. with very limited routes. Set it up so only your dns traffic is sent over the tunnel. Then you can still use the local network, crappy as it may be, without having to deal with the added overhead of ssh and the like. > -- > TTFN, > patrick -- Jason 'XenoPhage' Frisvold xenopha...@gmail.com http://blog.godshell.com
Re: dns interceptors
On Feb 14, 2010, at 12:37 PM, Jason Frisvold wrote: > On Feb 13, 2010, at 4:58 PM, Randy Bush wrote: >> i am often on funky networks in funky places. e.g. the wireless in >> changi really sucked friday night. if i ssh tunneled, it would multiply >> the suckiness as tcp would have puked at the loss rate. > > You can always run your own local resolver... Or is there a reason that's > unacceptable? How does that help? It still sends port 53 requests to the authorities, which will be intercepted. -- TTFN, patrick >> smb whacked me that i should use non-tcp tunnels. >> >> randy >> > > -- > Jason 'XenoPhage' Frisvold > xenopha...@gmail.com > http://blog.godshell.com > >
Re: dns interceptors
On Feb 13, 2010, at 4:58 PM, Randy Bush wrote: > i am often on funky networks in funky places. e.g. the wireless in > changi really sucked friday night. if i ssh tunneled, it would multiply > the suckiness as tcp would have puked at the loss rate. You can always run your own local resolver... Or is there a reason that's unacceptable? > smb whacked me that i should use non-tcp tunnels. > > randy > -- Jason 'XenoPhage' Frisvold xenopha...@gmail.com http://blog.godshell.com
Re: History of 4.2.2.2. What's the story?
>It was always pretty robust due to the BIND code, thanks to ISC, and >the fact it was always IPV4 AnyCast. $ asp 4.2.2.2 # look it up in routeviews 4.0.0.0/9 ASN 3356, path 3549 -> 3356 Wow, that's a heck of an anycast block. R's, John
Re: History of 4.2.2.2. What's the story?
On Sun, Feb 14, 2010 at 02:16:30AM -0700, Sean Reifschneider wrote: > I've wondered about this for years, but only this evening did I start > searching for details. And I really couldn't find any. > > Can anyone point me at distant history about how 4.2.2.2 came to be, in my > estimation, the most famous DNS server on the planet? I don't think anyone else can help you determine your estimaation... > I know that it was originally at BBN, what I'm looking for is things like: 4/8 was originally BBN. Anycasted DNS resolvers came to many networks somewhen 98-00 [I can't be more precise as my archive of 1994-2007 work and events is naturally out of my reach, being that employer's data]. But I seem to recall that was Rodeny's babye form the Genuity days. >How the IP was picked. (I'd guess it was one of the early DNS servers, > and the people behind it realized that if there was one IP address > that really needed to be easy to remember, it was the DNS server, > for obvious reasons). >Was it always meant to be a public resolver? >How it continued to remain an open resolver, even in the face of > amplifier attacks using DNS resolvers. Perhaps it has had > rate-limiting on it for a long time. That is a question for folks at L3. Any publicly-sharable data might be interesting presentation-fodder. >There's a lot of conjecture about it using anycast, anyone know anything > about it's current configuration? Why "conjecture"? Examining the /32s from inside and outside of 3356 clearly shows the whole set still is, and those who have been customers or worked with the 3356 folks over the years know it has historically been as well. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: History of 4.2.2.2. What's the story?
Since I'm watching B5 again on DVD I was there at the dawning of the age of 4.2.2.1 :) We did it, and we I mean Brett McCoy and my self. But most of the credit/blame goes to Brett... I helped him, but at the time I was mostly working on getting out Mail relays working right. This was about 12 years ago, about 1998, I left Geunitity in 2000, and am back at BBN/Raytheon now. I remember we did most of the work after we moved out of Cambridge and into Burlington. Genuity/GTEI/Planet/BBN owned 4/8. Brett went looking for an IP that was simple to remember, I think 4.4.4.4 was in use by neteng already. But it was picked to be easy to remember, I think jhawk had put a hold on the 4.2.2.0/24 block, we got/grabbed 3 address 4.2.2.1, 4.2.2.2, and 4.2.2.3 so people had 3 address to go to.At the time people had issues with just using a single resolver. We also had issues with both users and registers since clearly they aren't geographically diverse, trying to explain routing tricks to people KNOW all IPs come in and are routed as Class A/B/C blocks is hard. NIC.Near.Net which was our primary DNS server for years before I transferred to planet from BBN. It wasn't even in 4/8, I think it was 128.89 (BBN Corp space), but I'm not sure. BBN didn't start to use 4/8 till the Planet build out, and NIC.near.net predates that by at least 10 years. I still have the power cord from NIC.near.net in my basement. That machine grew organically with every service known to mankind running on it, and special one-off things for customers on it. It took us literally YEARS to get that machine turned off, when we finally got it off I took the power cord so no one would help us by turning it back on, I gave the cord to Chris Yetman, who was the director of operations and told him if a customer screams he has the power to turn it back on. A year or so later, he gave the cord back to me. Yes we set up 4.2.2.1 as a public resolver. We figured trying to filter it was larger headache than just making it public. It was always pretty robust due to the BIND code, thanks to ISC, and the fact it was always IPV4 AnyCast. I don't know about now, but originally it was IPV4 AnyCast. Each server advertised a routes for 4.2.2.1, .2, and .3 at different costs and the routers would listen to the routes. Originally the start up code was, basically: advertise route to 4.2.2.1, 4.2.2.2, and 4.2.2.3 run bind in foreground mode drop route to 4.2.2.1, 4.2.2.2, and 4.2.2.3 then we had a Tivoli process that tried to restart bind, but rate limited the restarts. But that way if the bind died the routes would drop. johno On Feb 14, 2010, at 4:16 AM, Sean Reifschneider wrote: > I've wondered about this for years, but only this evening did I start > searching for details. And I really couldn't find any. > > Can anyone point me at distant history about how 4.2.2.2 came to be, in my > estimation, the most famous DNS server on the planet? > > I know that it was originally at BBN, what I'm looking for is things like: > > How the IP was picked. (I'd guess it was one of the early DNS servers, > and the people behind it realized that if there was one IP address > that really needed to be easy to remember, it was the DNS server, > for obvious reasons). > Was it always meant to be a public resolver? > How it continued to remain an open resolver, even in the face of > amplifier attacks using DNS resolvers. Perhaps it has had > rate-limiting on it for a long time. > There's a lot of conjecture about it using anycast, anyone know anything > about it's current configuration? > > So, if anyone has any stories about 4.2.2.2, I'd love to hear them. > > Thanks, > Sean > -- > Microsoft treats objects like women, man... > -- Kevin Fenzi, paraphrasing the Dude, 1998 > Sean Reifschneider, Member of Technical Staff > tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability > >
Re: History of 4.2.2.2. What's the story?
I think around 10 years ago Slashdot had a few stories (and still do, actually) about how great these resolvers were. I think that propelled quite a bit of their growth and popularity. On 2/14/2010 1:16 AM, Sean Reifschneider wrote: I've wondered about this for years, but only this evening did I start searching for details. And I really couldn't find any. Can anyone point me at distant history about how 4.2.2.2 came to be, in my estimation, the most famous DNS server on the planet? I know that it was originally at BBN, what I'm looking for is things like: How the IP was picked. (I'd guess it was one of the early DNS servers, and the people behind it realized that if there was one IP address that really needed to be easy to remember, it was the DNS server, for obvious reasons). Was it always meant to be a public resolver? How it continued to remain an open resolver, even in the face of amplifier attacks using DNS resolvers. Perhaps it has had rate-limiting on it for a long time. There's a lot of conjecture about it using anycast, anyone know anything about it's current configuration? So, if anyone has any stories about 4.2.2.2, I'd love to hear them. Thanks, Sean
Re: AT&T Mind Boggles...
On 14 Feb 2010, at 01:16, goe...@anime.net wrote: This is a bit more accessible, and free: http://www.hulu.com/watch/4163/saturday-night-live-ernestine Not if you are outside of the USA as the OP is... f
History of 4.2.2.2. What's the story?
I've wondered about this for years, but only this evening did I start searching for details. And I really couldn't find any. Can anyone point me at distant history about how 4.2.2.2 came to be, in my estimation, the most famous DNS server on the planet? I know that it was originally at BBN, what I'm looking for is things like: How the IP was picked. (I'd guess it was one of the early DNS servers, and the people behind it realized that if there was one IP address that really needed to be easy to remember, it was the DNS server, for obvious reasons). Was it always meant to be a public resolver? How it continued to remain an open resolver, even in the face of amplifier attacks using DNS resolvers. Perhaps it has had rate-limiting on it for a long time. There's a lot of conjecture about it using anycast, anyone know anything about it's current configuration? So, if anyone has any stories about 4.2.2.2, I'd love to hear them. Thanks, Sean -- Microsoft treats objects like women, man... -- Kevin Fenzi, paraphrasing the Dude, 1998 Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
