Re: Please, talk me down.

2012-10-17 Thread John Levine
In article 2801f5f8-b8e2-4a9f-9a89-02d7783cc...@josephholsten.com you write:
I want to like IPv6. I do. But I'm seriously considering turning off
IPv6 support from our servers.

First off, I'm using djbdns internally and it doesn't support 
records. So we really aren't using it internally.

I'm a long time djbdns user.  But about a year ago, I switched from
using dnscache to unbound for my cache, because it does useful stuff
that dnscache doesn't do.  I had a bunch of wacky local stuff
configured into dnscache, like querying local servers for local-only
domains, and substituting a local reject-all for some nasty outside
domains, and it took about an hour to figure out how to do it all with
unbound.  I run it under daemontools.

My authoritative servers are still tinydns, even though I do support
IPv6.  Since tinydns-data compiles stuff from a text source file, I
have a perl script that translates lines with  records in a normal
format into the escape codes that tinydns uses for arbitrary record
types.  It's gross, but it works.

So anyway, use unbound for your cache, no need to change away from
tinydns unless you want to use DNSSEC, which it'll never support.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies,
Please consider the environment before reading this e-mail. http://jl.ly



DNS hostnames with a duplicate CNAME and A record - which should be removed?

2012-10-17 Thread Landon Stewart
Hi Y'all Nanogites,

We are changing over to PowerDNS from djbdns (tinydns) and I'm taking this
opportunity to fix as much of our zone data as we can.  Under tinydns
things work fine despite these errors because tinydns lets you get away
with stuff like this and still responds even though a zone might
technically be broken because of it.

The problem is that we have some zones that have records with the same
hostname that have both a CNAME as well as an A record, MX record, SOA
record and/or NS record.  Is there an easy answer for what should be
removed?  I'm inclined to say that the CNAME should be removed in all these
cases but I can't find any definitive information on this and after doing
some tests it doesn't always seem straightforward.

I've been reading various sites and information including RFC 1034 but
it's difficult to decide what to do when it's already an issue.  For
example in RFC 1034 section 3.6.2 the use of CNAME's with NS and MX records
is not permitted but other research shows this is widely used even though
its technically invalid.  IMHO it should have never happened in the first
place (where an A record already exists a CNAME should not have been
allowed to get added for example) but what can be done now that it's
already an issue?

In the case of the A,NS,MX,SOA and CNAME duplicates an example of how our
old/current name server's responses are:
(*note: not all of this is real data, customer zones have been obfuscated)*
*
*
# dig @ns1.superb.net +nocmd mail.customerzone.com A +noques +answer
;; ANSWER SECTION:
mail.customerzone.com. 14342 IN CNAME mail.superb.net.
mail.customerzone.com. 86342 IN A xx.xx.246.9

# dig @ns1.superb.net +nocmd superbcolo.biz NS +noques +answer
;; ANSWER SECTION:
superbcolo.biz. 86400 IN NS ns1.superb.net.
superbcolo.biz. 86400 IN NS ns2.superb.net.
superbcolo.biz. 86400 IN NS ns3.superb.net.
superbcolo.biz. 86400 IN CNAME superbenterprise.net.

# dig @ns1.superb.net +nocmd superbcolo.biz mx +noques +answer
;; ANSWER SECTION:
superbcolo.biz. 86400 IN MX 10 superbcolo.biz.
superbcolo.biz. 86400 IN CNAME superbenterprise.net.

 dig @ns1.superb.net +nocmd customerzone2.com SOA +noques +answer
;; ANSWER SECTION:
customerzone2.com. 86400 IN CNAME superbenterprise.net.
customerzone2.com. 86400 IN SOA ns1.superb.net. hostmaster.superb.net.
1350501302 0 0 0 0

Should the CNAME just get nuked in all of these cases?

-- 
Landon Stewart lstew...@superb.net
Sr. Administrator
Systems Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more Ahead of the Rest: http://www.superbhosting.net


Re: DNS hostnames with a duplicate CNAME and A record - which should be removed?

2012-10-17 Thread Andrew Sullivan
On Wed, Oct 17, 2012 at 12:25:49PM -0700, Landon Stewart wrote:
 hostname that have both a CNAME as well as an A record, MX record, SOA
 record and/or NS record.  Is there an easy answer for what should be
 removed? 

You should remove the one that you don't need.  A CNAME may not be
at the same owner name as any other RR.  If you need an alias, then
you want a CNAME.  If you need some other record, you need not to have
a CNAME.

If you think about what a CNAME is, it is obvious that it can't exist
at the same name as any other RR, because it says this name is
actually that name over there.

 Should the CNAME just get nuked in all of these cases?

Probably.

A

-- 
Andrew Sullivan
Dyn Labs
asulli...@dyn.com



Re: DNS hostnames with a duplicate CNAME and A record - which should be removed?

2012-10-17 Thread William Herrin
On Wed, Oct 17, 2012 at 3:25 PM, Landon Stewart lstew...@superb.net wrote:
 The problem is that we have some zones that have records with the same
 hostname that have both a CNAME as well as an A record, MX record, SOA
 record and/or NS record.  Is there an easy answer for what should be
 removed?  I'm inclined to say that the CNAME should be removed in all these
 cases but I can't find any definitive information on this and after doing
 some tests it doesn't always seem straightforward.

If you have a CNAME record for a particular name, you should not have
any other record of any type for that same name. Which you should
remove depends on the details of the particular circumstance. If you
really mean identical to that other name with respect to all records
and record types then there's nothing inherently wrong with the
CNAME. If you don't, then you shouldn't use a CNAME there.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004



Re: Please, talk me down.

2012-10-17 Thread Nicolai
On Wed, Oct 17, 2012 at 03:35:11AM +, Joseph Anthony Pasquale Holsten wrote:

 First off, I'm using djbdns internally and it doesn't support 
 records. So we really aren't using it internally.

I assume you mean stock djbdns doesn't support ip6, because it does
indeed support  records.  I use both dnscache and tinydns from
djbdns and  records work fine for me.  Note: I'm not using Felix von
Leitner's ip6 patch.

$ dig  chocolatine.org +short
2610:130:103:e00:201:2ff:fe45:8308

Resolver is dnscache, authoritate server is tinydns.  No problem.

I think the problem you're experiencing, if there is one, is not related
to either djbdns or ip6.

Nicolai



Re: Detection of Rogue Access Points

2012-10-17 Thread John Kristoff
On Sun, 14 Oct 2012 16:59:12 -0400
Jonathan Rogers quantumf...@gmail.com wrote:

 I'm looking for innovative ideas on how to find such a rogue device,

Here is an old post that describes some techniques, while date, should
still be at least partially effective and help form part of a more
comprehensive solution:

  http://www.merit.edu/mail.archives/nanog/2003-02/msg00247.html

John



Re: Please, talk me down.

2012-10-17 Thread Jimmy Hess
On 10/16/12, Randy Bush ra...@psg.com wrote:
 First off, I'm using djbdns internally and it doesn't support 
 records. So we really aren't using it internally.
 if the clutch in my car is broken, should i stop using vehicles?
 dump djbdns or get some diehard to tell you how to fix it.

Ah, but the clutch is not actually broken;  it works perfectly,  and
it is a very robust clutch, not likely to break,  it's just that the
car was designed,  so you need a wrench with you while at all times
while driving, to actuate the clutch,  and you need a screwdriver
onhand as well to adjust gears.They have a raw record format,
that allows you to enter a raw record into your tinydns data file,
containing anything, including  data.

However, djbdns also lacks support for DNSSEC validation.  the stock
package 1.05,  when installed on a 64-bit OS, contained an unpatched
security vulnerability.

The car was also designed with no electric ignition switch, and no
headlights.   You want to start your car, you need a manual crank.
It's good enough;  but  probably the time comes soon to retire it.

Electronic ignitions and headlights became the 'standard' a long time
ago,  but the car design was never improved to include the features
(not necessarily an easy feat) --meanwhile,the person in
charge of maintaining the design;   spent  many hours writing  essays
about   the problem of light pollution caused by headlights,
insisting that road lights instead would be better,and  calling up
issues about  the extra  weight and space required for batteries,
danger of  batteries leaking,  or failing,  leaving motorists
stranded,   etc,
thus spending time  not updating the design to incorporate beneficial,
new standards.


 randy
-- 
-JH