Do we have anyone here who is a bind/dns wizard? I've been under the impression my dns setup which I've used for so many years on a bsd machine is now considered lame. If there is someone who would not mind taking a look at my configuration to see where I'm missing something, or where the difference lies between bind 9 and previous bind 8 configs? I'd prefer to do this off list via direct e-mail. The zone is very small, and the files are small too..
Sam
On 12/29/05, Sam Drinkard sam@wa4phy.net wrote:
Do we have anyone here who is a bind/dns wizard? I've been under the impression my dns setup which I've used for so many years on a bsd machine is now considered lame. If there is someone who would not mind taking a look at my configuration to see where I'm missing something, or where the difference lies between bind 9 and previous bind 8 configs? I'd prefer to do this off list via direct e-mail. The zone is very small, and the files are small too..
I don't consider myself an expert, but I'd be willing to help. I would prefer to do it on-list if it's at all possible for a couple reasons.
1. It may help others who have questions about bind but haven't asked yet. 2. It will provide (assuming this is a productive thread) a reference to link people to in the future. 3. Help from multiple people can be offered, so you get the best overall advice via discussion style suggestion/revision. There's probably something I'll miss that another person might pick up on. ( Someone else has done it, and done it better)
The only real downside is that your network topography is moderately exposed. This can be mitigated by cleansing the files of domain names etc, or it may be a completely internal home network and won't matter.
my $0.02.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
On Thu, 2005-12-29 at 15:35 -0500, Jim Perrin wrote:
On 12/29/05, Sam Drinkard sam@wa4phy.net wrote:
Do we have anyone here who is a bind/dns wizard? I've been under the impression my dns setup which I've used for so many years on a bsd machine is now considered lame. If there is someone who would not mind taking a look at my configuration to see where I'm missing something, or where the difference lies between bind 9 and previous bind 8 configs? I'd prefer to do this off list via direct e-mail. The zone is very small, and the files are small too..I don't consider myself an expert, but I'd be willing to help. I would prefer to do it on-list if it's at all possible for a couple reasons.
- It may help others who have questions about bind but haven't asked yet.
- It will provide (assuming this is a productive thread) a reference
to link people to in the future. 3. Help from multiple people can be offered, so you get the best overall advice via discussion style suggestion/revision. There's probably something I'll miss that another person might pick up on. ( Someone else has done it, and done it better)
The only real downside is that your network topography is moderately exposed. This can be mitigated by cleansing the files of domain names etc, or it may be a completely internal home network and won't matter.
my $0.02.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center _______________________________________________
Ok.. I don't have a problem doing it on list. Just thought it might be more appropriate off list, but I agree, there may be others it might help. I'll start out by just throwing the whole mess in here since they are relatively short files. Not a home network, but a single server in a co-lo site. Here we go...
First, the config file, which is from bind8 of the old BSD machine which worked without problems, and was not considered lame, and I, being the lazy type, just used the same configuration files throughout. My upstream DNS are listed in the zone file, but there are some problems with them also, according to dns reports.
// $Id: named.conf,v 1.5 1998/12/23 06:06:13 dillon Exp $ // // Refer to the named(8) man page for details. If you are ever going // to setup a primary server, make sure you've understood the hairy // details of how DNS is working. Even with simple mistakes, you can // break connectivity for affected parties, or cause huge amount of // useless Internet traffic.
options { directory "/var/named";
// In addition to the "forwarders" clause, you can force your name // server to never initiate queries of its own, but always ask its // forwarders only, by enabling the following line: // // forward only;
// If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet.
/* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53;
/* * If running in a sandbox, you may have to specify a different * location for the dumpfile. */ // dump-file "s/named_dump.db"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; };
// Note: the following will be supported in a future release. /* host { any; } { topology { 127.0.0.0/8; }; }; */
// Setting up secondaries is way easier and the rough picture for this // is explained below. // // If you enable a local name server, don't forget to enter 127.0.0.1 // into your /etc/resolv.conf so this server will be queried first. // Also, make sure to enable it in /etc/rc.conf.
zone "." IN { type hint; file "named.ca"; };
zone "0.0.127.IN-ADDR.ARPA" { type master; file "localhost.rev"; };
zone "wa4phy.net" { type master; file "wa4phynet"; };
zone "158.104.216.in-addr.arpa" { type master; file "wa4phy.rev"; };
Next, the zone file, which is called "wa4phynet"
$TTL 3600 @ IN SOA wa4phy.net. root.wa4phy.net. ( 2005112501 ; Serial, todays date + todays serial # 8H ; Refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds @ IN NS 216.104.158.222 @ IN NS 216.104.128.37 @ IN NS 216.104.128.38
wa4phy.net. A 216.104.158.222 vortex.wa4phy.net. A 216.104.158.222 ns.wa4phy.net. A 216.104.158.222 localhost A 127.0.0.1 MX 10 wa4phy.net. ;Primary Mail Exchanger MX 20 smtp7.bagger.usbn.net. ;Secondary MX
www CNAME wa4phy.net. ftp CNAME wa4phy.net.
Next the reverse zone
$TTL 3600 @ IN SOA wa4phy.net. root.wa4phy.net. ( 2005112501 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400 ) ; Minimum TTL @ IN NS wa4phy.net.
222 PTR wa4phy.net.
And last, the localhost.rev file
@ IN SOA wa4phy.net. root.vortex.wa4phy.net. ( 2005112501 ;Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600 ) ; minimum IN NS wa4phy.net. 1 IN PTR localhost.wa4phy.net.
I'm sure the formatting is not going to be right from the looks of things, but maybe it's close.
Snowman
@ IN NS 216.104.158.222 @ IN NS 216.104.128.37 @ IN NS 216.104.128.38
Specifying IP's for NS'es is illegal - NS'es should be hostnames - themselves posessing A or AAAA records (for the interest of quick lookup times these hostnames should be from within the domain they're NS'ing for...) In other words, you should have:
@ IN NS ns1 @ IN NS ns2 @ IN NS ns3 ns1 IN A 216.104.158.222 ns2 IN A 216.104.128.37 ns3 IN A 216.104.128.38
wa4phy.net. A 216.104.158.222
this is just "@ A ..."
vortex.wa4phy.net. A 216.104.158.222
this is just "vortex A ..."
ns.wa4phy.net. A 216.104.158.222
this is just "ns A ..."
localhost A 127.0.0.1
this is weird because it is localhost.wa4phy.net. A 127.0.0.1
1 IN PTR localhost.wa4phy.net.
Ah so maybe the weird localhost is what you wanted?
Cheers, MaZe.
@ IN NS 216.104.158.222 @ IN NS 216.104.128.37 @ IN NS 216.104.128.38
Specifying IP's for NS'es is illegal - NS'es should be hostnames - themselves posessing A or AAAA records (for the interest of quick lookup times these
Note: $ host -t ns wa4phy.net wa4phy.net name server 216.104.128.37.wa4phy.net. wa4phy.net name server 216.104.128.38.wa4phy.net. wa4phy.net name server 216.104.158.222.wa4phy.net.
Probably not what you wanted ;) Cheers, MaZe.
Maciej ¯enczykowski maze@cela.pl wrote:
Note: $ host -t ns wa4phy.net wa4phy.net name server 216.104.128.37.wa4phy.net. wa4phy.net name server 216.104.128.38.wa4phy.net. wa4phy.net name server 216.104.158.222.wa4phy.net. Probably not what you wanted ;)
Excellent catch! I totally missed that!
Yes, BIND v9 is far more anal on the requirement of terminating any record with a period to avoid appending the ORIGIN.
On Thu, 2005-12-29 at 13:35 -0800, Bryan J. Smith wrote:
Maciej ¯enczykowski maze@cela.pl wrote:
Note: $ host -t ns wa4phy.net wa4phy.net name server 216.104.128.37.wa4phy.net. wa4phy.net name server 216.104.128.38.wa4phy.net. wa4phy.net name server 216.104.158.222.wa4phy.net. Probably not what you wanted ;)
Excellent catch! I totally missed that!
Yes, BIND v9 is far more anal on the requirement of terminating any record with a period to avoid appending the ORIGIN.
Ok.. I'm assuming you mean the "." after localhost. I missed it too. As for the names vs. ip's is that a change in the bind 9 stuff? Any other errors or mistakes you see?
Snowman
Ok.. I'm assuming you mean the "." after localhost. I missed it too. As for the names vs. ip's is that a change in the bind 9 stuff? Any other errors or mistakes you see?
Well the lack of a dot after localhost is weird, of course with the '.' there it wouldn't work (it would be a reference outside of it's zone), normally I handle localhost in a different zone file, or just rely on /etc/hosts to do it [although normally I use djbdns so I don't actually have a bind server set up anywhere...])
The main problem though is something else: it is ILLEGAL (and has always been) to specify a quad-dotted-IP for an NS record - NS records must point to HOSTNAMES, and only these HOSTNAMES, can have A or AAAA or AWHATEVER records to provide HOSTNAME to IPv4/IPv6/IPwhatever mappings.
That's why I suggested:
#!/bin/bash for i in ns1 ns2 ns3; do echo "@ NS $i" echo "$i A place.ip.number.here" done
Which makes the NS records for domain.com point to ns[123].domain.com, and makes A records for ns[123].domain.com point to the actual IPs.
That's the ONLY correct and sure way to do it.
Having records of the "domain.com NS ip.address.placed.here" form SHOULD never work - or rather it WILL work if you happen to hit upon a buggy dns server/cache somewhere along the way which is behaving out of spec with the RFCs. Since for some (few) dns servers it will work and for others it won't, your domain will be accessible to some and inaccessible to others... pretty randomly - unless you know what to look for.
In your case, stuff works - but only because the .net domain servers are returning different (correct) info. So basically your NS entries are being ignored and the entries from your provider are winning out - lucky you.
Cheers, MaZe.
Ok.. I'm assuming you mean the "." after localhost. I missed it too.
Actually, I meant the dot after your NS entries. Because the NS entries are IPs, they are assumed to be hostnames. So the ORIGIN is appended.
That's why you use names in the NS entries, not IP addresses. Don't know what happens if you append a dot after the IP address. It might work, it might not.
Sam Drinkard sam@wa4phy.net wrote:
Ok.. I'm assuming you mean the "." after localhost. I missed it too. As for the names vs. ip's is that a change in the bind 9 stuff? Any other errors or mistakes you see?
It's not really a BIND v9 change, but a BIND v9 enforcement of IETF standards for DNS records. There are Best Common Practices (BCP) when it comes to default (@), nameserver (NS) and mailexchange (MX) records, among others.
On Thu, 2005-12-29 at 22:07 +0100, Maciej Żenczykowski wrote:
@ IN NS 216.104.158.222 @ IN NS 216.104.128.37 @ IN NS 216.104.128.38
Specifying IP's for NS'es is illegal - NS'es should be hostnames - themselves posessing A or AAAA records (for the interest of quick lookup times these hostnames should be from within the domain they're NS'ing for...) In other words, you should have:
@ IN NS ns1 @ IN NS ns2 @ IN NS ns3 ns1 IN A 216.104.158.222 ns2 IN A 216.104.128.37 ns3 IN A 216.104.128.38
wa4phy.net. A 216.104.158.222
this is just "@ A ..."
vortex.wa4phy.net. A 216.104.158.222
this is just "vortex A ..."
ns.wa4phy.net. A 216.104.158.222
this is just "ns A ..."
localhost A 127.0.0.1
this is weird because it is localhost.wa4phy.net. A 127.0.0.1
1 IN PTR localhost.wa4phy.net.
Ah so maybe the weird localhost is what you wanted?
Cheers, MaZe.
If I remember correctly, the format I used came from the book associated with FreeBSD 2.3 or perhaps earlier. Pretty much verbatim from the old days of the berkely format of the 80's
I'm no bind guru by any sort of means, and I know there were significant changes between bind 8 and bind 9. I was more curious why it was considered lame server whereas prior to CentOS, it worked well, and was not considered lame under BSD. Everything still works, but there are some warnings if you look at the report from http://dnsreport.com plugging in my domain name. Part of that problem is upstream, which I can get corrected *I think* :-)
Snowman
On Thu, 2005-12-29 at 15:18, Sam Drinkard wrote:
I'm no bind guru by any sort of means, and I know there were significant changes between bind 8 and bind 9. I was more curious why it was considered lame server whereas prior to CentOS, it worked well, and was not considered lame under BSD. Everything still works, but there are some warnings if you look at the report from http://dnsreport.com plugging in my domain name. Part of that problem is upstream, which I can get corrected *I think* :-)
A 'lame server' means you are delegating (vs NS records) to servers that don't respond for the zone you've specified. NS records in the wrong form would give that effect.
Sam Drinkard sam@wa4phy.net wrote:
I was more curious why it was considered lame server
whereas
prior to CentOS, it worked well, and was not considered
lame
under BSD.
No difference.
ISC BIND v8 (used by both Linux and BSD IIRC) had a lot of buffer overflows and other holes. I personally got hit by one in 8.2.1 -- although that was my fault. I stupidly hadn't updated for 4 months since the first BIND shell exploits became available, which was 5 months later than when the patches/upgrades appeared (meaning I was out-of-date by 9 months total). It took me a bit, but I discovered a rootkit was installed -- but only because the original compromiser left his original BIND shell running.
Luckily the system was in its own DMZ, and I did not use the same passwords for anything else.
Today I use both host and network IDSes, and catch these things when they happen -- even at home.
Jesse ras1@jamrockmusic.com wrote:
Just curious what you use for this.
Depends on the budget. ;->
I'm partial to Nokia solutions for financial sectors, although I _never_ put all my eggs in one basket. I typically and _always_ use Snort for the network IDS, including the free update subscription. It can't hurt to have Snort (or even their SourceFire subscription) in addition to non-freedom solutions.
For a freedom host IDS, a combination of Snort IDS and then Portsentry targetting active (or commonly targetted) services.
For layer-7 services, I shouve out some serious money when I can (i.e., 5 figures). When I can't, I make sure it's in a DMZ. I'm still looking for a freedom layer-7 scanning service.
It's never a matter of whether you will be hacked, it's a matter of when. Updating only goes so far (although it's clearly the best move).
Basic 1, 2 and 3 sigma statistics generally apply here (I appologize for my over-simplistic application of risk analysis -- but I'm an engineer after all ;-).
Updating only gets you to 1 (~67%).
I prefer the "defense-in-depth" of adding network and host IDS as well, getting me to 2 (~96%) and letting me know when I've been compromised (like even my wife's system home Windows system was c/o some spyware earlier this year).
Ideally, anytime you have any layer-7 application service (or even client -- such as a resident virus scanner that scans specific, incoming/outgoing ports), active scanning is ideal. That's more 3 sigma (>99%), assuming you use network and host IDS too.
-- Bryan "I've definitely done too much [Practices] today" Smith
P.S. For defense, there are MIL-STD and CCEA -- and MAC/RBAC is required by default (and must be explained with exceptions if not). And such networks _never_ go on publicly accessible networks -- although that's still 70% of the battle (although MAC/RBAC addresses it fairly well).
On Thu, 2005-12-29 at 22:07 +0100, Maciej Żenczykowski wrote:
@ IN NS 216.104.158.222 @ IN NS 216.104.128.37 @ IN NS 216.104.128.38
Specifying IP's for NS'es is illegal - NS'es should be hostnames - themselves posessing A or AAAA records (for the interest of quick lookup times these hostnames should be from within the domain they're NS'ing for...) In other words, you should have:
@ IN NS ns1 @ IN NS ns2 @ IN NS ns3 ns1 IN A 216.104.158.222 ns2 IN A 216.104.128.37 ns3 IN A 216.104.128.38
wa4phy.net. A 216.104.158.222
this is just "@ A ..."
vortex.wa4phy.net. A 216.104.158.222
this is just "vortex A ..."
ns.wa4phy.net. A 216.104.158.222
this is just "ns A ..."
localhost A 127.0.0.1
this is weird because it is localhost.wa4phy.net. A 127.0.0.1
1 IN PTR localhost.wa4phy.net.
Ah so maybe the weird localhost is what you wanted?
Cheers, MaZe.
Ok.. I made some edits, and before I do a restart, if you don't mind, take a look at the revised zone file. I think I got the idea what you were talking about. here's the edited file......
@ IN SOA wa4phy.net. root.wa4phy.net. ( 2005122901 ; Serial, todays date + todays serial # 8H ; Refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds @ IN NS ns.wa4phy.net. @ IN NS ns5.gabn.net. @ IN NS ns6.gabn.net.
ns1 IN A 216.104.158.222 ns2 IN A 216.104.128.37 ns3 IN A 216.104.128.38
wa4phy.net. A 216.104.158.222 vortex.wa4phy.net. A 216.104.158.222 ns.wa4phy.net. A 216.104.158.222 localhost. A 127.0.0.1 MX 10 wa4phy.net. ;Primary Mail Exchanger MX 20 smtp7.bagger.usbn.net. ;Secondary MX
www CNAME wa4phy.net. ftp CNAME wa4phy.net.
What I would use:
@ SOA wa4phy.net. root.wa4phy.net. ( 2005122901 ; Serial, todays date + todays serial # 8H ; Refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds @ NS ns NS ns2 NS ns3
ns A 216.104.158.222 ns2 A 216.104.128.37 ns3 A 216.104.128.38
@ A 216.104.158.222 vortex A 216.104.158.222 @ MX 10 wa4phy.net. ;Primary Mail Exchanger MX 20 smtp7.bagger.usbn.net. ;Secondary MX www CNAME wa4phy.net. ftp CNAME wa4phy.net.
'IN' can be dropped - it's the default. Please note the lack of an entry for localhost, localhost. would need to go into a seperate zone file (for the localhost. domain) or leave it up to /etc/hosts to resolve localhost.
Cheers, MaZe.
On Thu, 2005-12-29 at 23:05 +0100, Maciej Żenczykowski wrote:
What I would use:
@ SOA wa4phy.net. root.wa4phy.net. ( 2005122901 ; Serial, todays date + todays serial # 8H ; Refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds @ NS ns NS ns2 NS ns3
ns A 216.104.158.222 ns2 A 216.104.128.37 ns3 A 216.104.128.38
@ A 216.104.158.222 vortex A 216.104.158.222 @ MX 10 wa4phy.net. ;Primary Mail Exchanger MX 20 smtp7.bagger.usbn.net. ;Secondary MX www CNAME wa4phy.net. ftp CNAME wa4phy.net.
'IN' can be dropped - it's the default. Please note the lack of an entry for localhost, localhost. would need to go into a seperate zone file (for the localhost. domain) or leave it up to /etc/hosts to resolve localhost.
Cheers, MaZe.
Thanks Maze.. pretty much what I finally wound up with. Guess things tend to change over time and I don't try to keep up with everything when it all still works.
Snowman
On Thu, 2005-12-29 at 18:17, Sam Drinkard wrote:
@ A 216.104.158.222 vortex A 216.104.158.222 @ MX 10 wa4phy.net. ;Primary Mail Exchanger MX 20 smtp7.bagger.usbn.net. ;Secondary MX www CNAME wa4phy.net. ftp CNAME wa4phy.net.
Thanks Maze.. pretty much what I finally wound up with. Guess things tend to change over time and I don't try to keep up with everything when it all still works.
One other thing that might not be obvious: CNAMEs aren't just for the A record, they get all associated data too so you are providing an MX record for www.wa4phy.net and ftp.wa4phy.net. It doesn't hurt anything but it might not be what you expect.
Les Mikesell wrote:
On Thu, 2005-12-29 at 18:17, Sam Drinkard wrote:
@ A 216.104.158.222 vortex A 216.104.158.222 @ MX 10 wa4phy.net. ;Primary Mail Exchanger MX 20 smtp7.bagger.usbn.net. ;Secondary MX www CNAME wa4phy.net. ftp CNAME wa4phy.net.
Thanks Maze.. pretty much what I finally wound up with. Guess things tend to change over time and I don't try to keep up with everything when it all still works.
One other thing that might not be obvious: CNAMEs aren't just for the A record, they get all associated data too so you are providing an MX record for www.wa4phy.net and ftp.wa4phy.net. It doesn't hurt anything but it might not be what you expect.
Not sure I follow what you are talking about Les. Can you be a bit more specific?
On Thu, 2005-12-29 at 21:18, Sam Drinkard wrote:
@ A 216.104.158.222 vortex A 216.104.158.222 @ MX 10 wa4phy.net. ;Primary Mail Exchanger MX 20 smtp7.bagger.usbn.net. ;Secondary MX www CNAME wa4phy.net. ftp CNAME wa4phy.net.
Thanks Maze.. pretty much what I finally wound up with. Guess things tend to change over time and I don't try to keep up with everything when it all still works.
One other thing that might not be obvious: CNAMEs aren't just for the A record, they get all associated data too so you are providing an MX record for www.wa4phy.net and ftp.wa4phy.net. It doesn't hurt anything but it might not be what you expect.
Not sure I follow what you are talking about Les. Can you be a bit more specific?
Cnames are effectively the same as the record they point to. You probably intend for any mail sent to user@wa4phy.net to be sent to the primary/secondary MX receivers you specified, but as a side effect of the CNAME, mail sent to user@www.wa4phy.net or user@ftp.wa4phy.net would go to the same places because the MX records also apply to them. It isn't likely to matter in this case, but someday you might want to direct mail to those addresses elsewhere and be surprised that you can't give them a different MX. Or if you actually want mail to go to those addresses you might be surprised when they sometimes hit the secondary MX that might not be configured for them.
Les Mikesell wrote:
On Thu, 2005-12-29 at 21:18, Sam Drinkard wrote:
One other thing that might not be obvious: CNAMEs aren't just for the A record, they get all associated data too so you are providing an MX record for www.wa4phy.net and ftp.wa4phy.net. It doesn't hurt anything but it might not be what you expect.
Not sure I follow what you are talking about Les. Can you be a bit more specific?
Cnames are effectively the same as the record they point to. You probably intend for any mail sent to user@wa4phy.net to be sent to the primary/secondary MX receivers you specified, but as a side effect of the CNAME, mail sent to user@www.wa4phy.net or user@ftp.wa4phy.net would go to the same places because the MX records also apply to them. It isn't likely to matter in this case, but someday you might want to direct mail to those addresses elsewhere and be surprised that you can't give them a different MX. Or if you actually want mail to go to those addresses you might be surprised when they sometimes hit the secondary MX that might not be configured for them.
I've almost never use CNAMES and really am wondering about a truly useful application. In this day of spam, it seems like less is best with regards to subdomains, such as the example above. CNAMES also require at least one extra loop in the lookup.. so why are they so widely used when an A record does the more defined and more limited task? There certainly seems to be some useful wizardry in CNAMEs, but darned if I can think of a use for basic web hosting types of situations.
Best, John Hinton
John Hinton wrote:
Les Mikesell wrote:
On Thu, 2005-12-29 at 21:18, Sam Drinkard wrote:
One other thing that might not be obvious: CNAMEs aren't just for the A record, they get all associated data too so you are providing an MX record for www.wa4phy.net and ftp.wa4phy.net. It doesn't hurt anything but it might not be what you expect.
Not sure I follow what you are talking about Les. Can you be a bit more specific?
Cnames are effectively the same as the record they point to. You probably intend for any mail sent to user@wa4phy.net to be sent to the primary/secondary MX receivers you specified, but as a side effect of the CNAME, mail sent to user@www.wa4phy.net or user@ftp.wa4phy.net would go to the same places because the MX records also apply to them. It isn't likely to matter in this case, but someday you might want to direct mail to those addresses elsewhere and be surprised that you can't give them a different MX. Or if you actually want mail to go to those addresses you might be surprised when they sometimes hit the secondary MX that might not be configured for them.
I've almost never use CNAMES and really am wondering about a truly useful application. In this day of spam, it seems like less is best with regards to subdomains, such as the example above. CNAMES also require at least one extra loop in the lookup.. so why are they so widely used when an A record does the more defined and more limited task? There certainly seems to be some useful wizardry in CNAMEs, but darned if I can think of a use for basic web hosting types of situations.
Best, John Hinton
What would really be neat, as well as useful, would be to take a live domain (I've effectually published mine) set everything in it proper, with full explainations, much in the way the dns how-to tried to do from prior Linux how-to days. Even tho this list is archived, I'd bet there could be some place where sample working configuration files could be placed for public access. Better to see and read than experiment and still not know what one is doing.
Just like me trying to remember all the stuff I needed to do to have a working xterm from remote, and getting into .xdefaults, X.resources, etc... when you don't use stuff all the time, you tend to forget the minor, but sometimes disasterous consequences. It's not fun getting old and forgetting things, trust me!
On Thu, 2005-12-29 at 21:43, John Hinton wrote:
I've almost never use CNAMES and really am wondering about a truly useful application. In this day of spam, it seems like less is best with regards to subdomains, such as the example above. CNAMES also require at least one extra loop in the lookup.. so why are they so widely used when an A record does the more defined and more limited task? There certainly seems to be some useful wizardry in CNAMEs, but darned if I can think of a use for basic web hosting types of situations.
There are a couple of reasons. First it is a good idea to give different DNS names to different services (ftp, www, mail, etc.) from the start even if they are originally hosted on a single box. Then if you have some reason later to move a service to a different machine, all you have to do is make that CNAME point there and you don't have to notify any clients.
Another case is where you want a name to appear in your domain, but it is really a host managed by someone else. In this case you can CNAME to his dns name and not need to be aware if he subsequently changes the IP address.
In the web world, you might have hosts at several locations for load balancing and redundancy and multiple A records with the same name. Then you might run many sites on all of these servers as named virtual hosts. This is much easier to manage if you have a single stack of
realhost IN A ip.address.1 realhost IN A ip.address.2 realhost IN A ip.address.3 etc.
and then one CNAME per vhost (these would each be in their own domain zone file) www.domain1.com IN CNAME realhost.realdomain.com. www.domain2.com IN CNAME realhost.realdomain.com. www.domain3.com IN CNAME realhost.realdomain.com.
When you look up one of the CNAMEs, you get all the A records so the load balances across them. If you need to change the real servers or take one out of service, you only have to do it in one place.
John Hinton wrote:
I've almost never use CNAMES and really am wondering about a truly useful application. In this day of spam, it seems like less is best with regards to subdomains, such as the example above. CNAMES also require at least one extra loop in the lookup.. so why are they so widely used when an A record does the more defined and more limited task? There certainly seems to be some useful wizardry in CNAMEs, but darned if I can think of a use for basic web hosting types of situations.
I tend to agree, although there are places where CNAMEs are necessary like classless reverse delegation (RFC 2317) or when you don't control the zone where the target A record(s) live.
I tend to agree, although there are places where CNAMEs are necessary like classless reverse delegation (RFC 2317) or when you don't control the zone where the target A record(s) live.
Classless reverse delegations in now way requires CNAMEs this is really only a BIND-limitation (and not so much a limitation but a combination of administrators laziness and BIND's mindset/zone-file structure).
Cheers, MaZe.
Maciej Żenczykowski wrote:
I tend to agree, although there are places where CNAMEs are necessary like classless reverse delegation (RFC 2317) or when you don't control the zone where the target A record(s) live.
Classless reverse delegations in now way requires CNAMEs this is really only a BIND-limitation (and not so much a limitation but a combination of administrators laziness and BIND's mindset/zone-file structure).
I suppose this is rather off topic but I'm very interested. Could you elaborate?
Classless reverse delegations in now way requires CNAMEs this is really only a BIND-limitation (and not so much a limitation but a combination of administrators laziness and BIND's mindset/zone-file structure).
I suppose this is rather off topic but I'm very interested. Could you elaborate?
Basically in BIND format what you do is:
Assume we want to serve up the hostnames of IP address of 1.2.3.4-1.2.3.9.
So we want to serve PTR records for 4.3.2.1.in-addr.arpa. all the way to 9.3.2.1.in-addr.arpa.
'Normally' (in BIND) what you would do is the server which is hosting the 3.2.1.in-addr.arpa. domain would delegate:
ORIGIN is 3.2.1.in-addr.arpa.
4-9 NS our.nameserver.hostname1. 4-9 NS our.nameserver.hostname1. 4 CNAME 4.4-9 5 CNAME 5.4-9 6 CNAME 6.4-9 7 CNAME 7.4-9 8 CNAME 8.4-9 9 CNAME 9.4-9
and then our nameserver would have:
ORIGIN is 4-9.3.2.1.in-addr.arpa.
4 PTR some-hostname. 5 PTR different-hostname. ... 9 PTR some-otherhostname.
Obviously this is the weird (some call it normal) way to do things using CNAME's.
Now - let's do it without CNAME's.
The 3.2.1.in-addr.arpa. server does:
ORIGIN is 3.2.1.in-addr.arpa.
4 NS our.nameserver.hostname1. 4 NS our.nameserver.hostname2. 5 NS our.nameserver.hostname1. 5 NS our.nameserver.hostname2. 6 NS our.nameserver.hostname1. 6 NS our.nameserver.hostname2. 7 NS our.nameserver.hostname1. 7 NS our.nameserver.hostname2. 8 NS our.nameserver.hostname1. 8 NS our.nameserver.hostname2. 9 NS our.nameserver.hostname1. 9 NS our.nameserver.hostname2.
which _CAN_ be written in two lines with a 'for-loop' [can't remember the bind syntax, I think it's: $GENERATE 4-9 $ NS our.namserver.hostname1. $GENERATE 4-9 $ NS our.namserver.hostname2. ]
Okay so the stuff is delegated to us. Now we could simply (or not so simply if we're using BIND, since we effectively have to create 9-4+1=6 zones) delegate normally, like so:
for each x in 4..9: ORIGIN is x.3.2.1.in-addr.arpa. x PTR some-hostname. //+ SOA record for the zone
OR
we could decide that bind is screwed anyway and DNS servers and cache's are two fundamentally different animals and shouldn't be mixed anyway (ie. no DNS server should ever be a cache and vice versa) and we could simply stick everything in one zone-file (possibly even the root zone if we're extremely lazy).
The reason why CNAME's are used for reverse delegation is because administrators are lazy and BIND makes the proper non-CNAME using solution tiresome to implement. It's a breeze with tinydns/djbdns (once you get to know the program, but that's normal).
Further reading, using djbdns syntax (not very legible for those used only to BIND syntax and not willing to learn):
http://cr.yp.to/djbdns/dot-arpa.html
Cheers, MaZe.
On Mon, 2006-01-02 at 10:22, Maciej Żenczykowski wrote:
we could decide that bind is screwed anyway and DNS servers and cache's are two fundamentally different animals and shouldn't be mixed anyway (ie. no DNS server should ever be a cache and vice versa)
Except that decision doen't make a lot of sense.
The reason why CNAME's are used for reverse delegation is because administrators are lazy and BIND makes the proper non-CNAME using solution tiresome to implement. It's a breeze with tinydns/djbdns (once you get to know the program, but that's normal).
If there is some advantage to delegating NS's for individual addresses instead of using CNAME's I think you forgot to mention it. CNAME's inherit the robustness of the referenced domain. If you do it by delegation, you'll have to provide multiple NS records for every address, and the admin of the delegating zone must track any changes. The point of using CNAMEs is for the delegating zone to not need to track anything about the real names - if they did they could just supply the correct PTR address in the first place.
This place isn't the place to get into a DNS discussion (the protocol has big flaws in it anyway), but I will comment one last time.
we could decide that bind is screwed anyway and DNS servers and cache's are two fundamentally different animals and shouldn't be mixed anyway (ie. no DNS server should ever be a cache and vice versa)
Except that decision doen't make a lot of sense.
It does from a security standpoint - take a look at how many bugs there are/were in BIND - how many breakins have happened through BIND. And consider that having server and cache running as the same servers makes it a good deal harder to implement both correctly and to prevent cross-poisoning and other attacks - it's a matter of simplicity giving bug-freeness and security.
The reason why CNAME's are used for reverse delegation is because administrators are lazy and BIND makes the proper non-CNAME using solution tiresome to implement. It's a breeze with tinydns/djbdns (once you get to know the program, but that's normal).
If there is some advantage to delegating NS's for individual addresses instead of using CNAME's I think you forgot to mention it. CNAME's inherit the robustness of the referenced domain. If you do it by delegation, you'll have to provide multiple NS records for every address, and the admin of the delegating zone must track any changes. The point of using CNAMEs is for the delegating zone to not need to track anything about the real names - if they did they could just supply the correct PTR address in the first place.
I don't see where your argument lies. Using CNAME's require specifying NS'es for the domain you CNAME too - using NS'es requires exactly the same amount of entries at the delegating server - indeed using CNAMEs requires more entries at the delegating server (1 line per NS for CNAME domain + 1 line for generating the CNAMEs, versus, 1 line per NS for generating NS'es). As for what happens at the client domain nameserver (the one being delegated too) - this is indeed where CNAME's are easier - but that's due to BIND and not integral to the DNS protocol at all (in tinydns it's far easier to set up zones, etc. and indeed CNAME's cause all sorts of extra headaches since automatic reverse-IP delegation doesn't (and can't) work for them...).
As for robustness - I see no difference either way - in both cases there's exactly one NS referring line per nameserver.
And the second half of your paragraph (about tracking changes) makes no sense whatsoever - are you sure you've understood what I've written? There's no need to track any changes once it's set up -- all changes are made by wherever the stuff has been delegated to (unless you want to change the nameservers but that's EXACTLY the same with CNAMEs).
Cheers, MaZe.
PS. I won't be replying on-list to this thread anymore - it's not CentOS'ish enough.
On Mon, 2006-01-02 at 12:04, Maciej Żenczykowski wrote:
we could decide that bind is screwed anyway and DNS servers and cache's are two fundamentally different animals and shouldn't be mixed anyway (ie. no DNS server should ever be a cache and vice versa)
Except that decision doen't make a lot of sense.
It does from a security standpoint - take a look at how many bugs there are/were in BIND - how many breakins have happened through BIND. And consider that having server and cache running as the same servers makes it a good deal harder to implement both correctly and to prevent cross-poisoning and other attacks - it's a matter of simplicity giving bug-freeness and security.
The reason why CNAME's are used for reverse delegation is because administrators are lazy and BIND makes the proper non-CNAME using solution tiresome to implement. It's a breeze with tinydns/djbdns (once you get to know the program, but that's normal).
If there is some advantage to delegating NS's for individual addresses instead of using CNAME's I think you forgot to mention it. CNAME's inherit the robustness of the referenced domain. If you do it by delegation, you'll have to provide multiple NS records for every address, and the admin of the delegating zone must track any changes. The point of using CNAMEs is for the delegating zone to not need to track anything about the real names - if they did they could just supply the correct PTR address in the first place.
I don't see where your argument lies. Using CNAME's require specifying NS'es for the domain you CNAME too - using NS'es requires exactly the same amount of entries at the delegating server - indeed using CNAMEs requires more entries at the delegating server (1 line per NS for CNAME domain + 1 line for generating the CNAMEs, versus, 1 line per NS for generating NS'es). As for what happens at the client domain nameserver (the one being delegated too) - this is indeed where CNAME's are easier - but that's due to BIND and not integral to the DNS protocol at all (in tinydns it's far easier to set up zones, etc. and indeed CNAME's cause all sorts of extra headaches since automatic reverse-IP delegation doesn't (and can't) work for them...).
As for robustness - I see no difference either way - in both cases there's exactly one NS referring line per nameserver.
And the second half of your paragraph (about tracking changes) makes no sense whatsoever - are you sure you've understood what I've written? There's no need to track any changes once it's set up -- all changes are made by wherever the stuff has been delegated to (unless you want to change the nameservers but that's EXACTLY the same with CNAMEs).
Cheers, MaZe.
PS. I won't be replying on-list to this thread anymore - it's not CentOS'ish enough. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Saturday 31 December 2005 07:54 am, Vic Ricker wrote:
when you don't control the zone where the target A record(s) live.
That's the _right_ place to use a CNAME. Unfortunately back in the days when we did everything manually a lot of us started using CNAME to avoid having to change IP#s in lots of places in our own zone files on those hopefully few occasions when we have to renumber.
Jeff
On Tue, 2006-01-03 at 13:32, Jeff Lasman wrote:
On Saturday 31 December 2005 07:54 am, Vic Ricker wrote:
when you don't control the zone where the target A record(s) live.
That's the _right_ place to use a CNAME. Unfortunately back in the days when we did everything manually a lot of us started using CNAME to avoid having to change IP#s in lots of places in our own zone files on those hopefully few occasions when we have to renumber.
But there is no down side to a CNAME as long as you remember that it really is an alias for the target name and thus inherits any other data (like MX records) associated with it.
But there is no down side to a CNAME as long as you remember that it really is an alias for the target name and thus inherits any other data (like MX records) associated with it.
The downsides to CNAMEs is that they increase look-up times - instead of getting an IP, you get a hostname which you have to look-up - again (ie. basically if your unlucky it's double the hostname -> IP/MX/whatever lookup time). ie. back to square one. Furthermore anything which is a CNAME point to a CNAME is dangerous - and those have a tendency to automagically crop up. Depending on the DNS library/cache etc you are using already 3 CNAME's in a row may result in failed lookups (others have higher limits - sometimes 4 sometimes as high as 10, sometimes none...)
Cheers, MaZe.
Les Mikesell wrote:
On Thu, 2005-12-29 at 21:18, Sam Drinkard wrote:
@ A 216.104.158.222 vortex A 216.104.158.222 @ MX 10 wa4phy.net. ;Primary Mail Exchanger MX 20 smtp7.bagger.usbn.net. ;Secondary MX www CNAME wa4phy.net. ftp CNAME wa4phy.net.
Thanks Maze.. pretty much what I finally wound up with. Guess things tend to change over time and I don't try to keep up with everything when it all still works.
One other thing that might not be obvious: CNAMEs aren't just for the A record, they get all associated data too so you are providing an MX record for www.wa4phy.net and ftp.wa4phy.net. It doesn't hurt anything but it might not be what you expect.
Not sure I follow what you are talking about Les. Can you be a bit more specific?
Cnames are effectively the same as the record they point to. You probably intend for any mail sent to user@wa4phy.net to be sent to the primary/secondary MX receivers you specified, but as a side effect of the CNAME, mail sent to user@www.wa4phy.net or user@ftp.wa4phy.net would go to the same places because the MX records also apply to them. It isn't likely to matter in this case, but someday you might want to direct mail to those addresses elsewhere and be surprised that you can't give them a different MX. Or if you actually want mail to go to those addresses you might be surprised when they sometimes hit the secondary MX that might not be configured for them.
Actually, I probably should remove the ftp entry anyhow as I don't allow ftp from anywhere except for myself and a couple of others, via sftp. As for the web entry, don't really have any issue with mail going to it, as it winds up going to root, which eventually winds up getting to me either way. The Cnames there were intended to prevent one from having to enter an ip address more so than anything else. Not a big deal the way I see it, but since I'm the only person receiving mail from here, that really makes it less of an issue. I really need to peruse the bind 9 docs, as well as the RFC's pertaining. I'm sure much has changed in 20 years.
Ok.. I don't have a problem doing it on list. Just thought it might be more appropriate off list, but I agree, there may be others it might help. I'll start out by just throwing the whole mess in here since they are relatively short files. Not a home network, but a single server in a co-lo site. Here we go...
And the list proves me right. 3 people all responding with good info before I had a chance to get my first reply out.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
Jim Perrin jperrin@gmail.com wrote:
And the list proves me right. 3 people all responding with good info before I had a chance to get my first reply out.
Still, the DNS questions have come up enough, it's probably time to designate this as a topic that should be explicit to the "Practies" list.
Just a suggestion.
On Thu, 2005-12-29 at 15:35 -0500, Jim Perrin wrote:
On 12/29/05, Sam Drinkard sam@wa4phy.net wrote:
Do we have anyone here who is a bind/dns wizard? I've been under the impression my dns setup which I've used for so many years on a bsd machine is now considered lame. If there is someone who would not mind taking a look at my configuration to see where I'm missing something, or where the difference lies between bind 9 and previous bind 8 configs? I'd prefer to do this off list via direct e-mail. The zone is very small, and the files are small too..I don't consider myself an expert, but I'd be willing to help. I would prefer to do it on-list if it's at all possible for a couple reasons.
I did not include the named.ca since that is more or less updated by a script, and the current version I believe is OK.
Snowman
-
Bryan J. Smith -
Jeff Lasman -
Jesse -
Jim Perrin -
John Hinton -
Les Mikesell -
Maciej Żenczykowski -
Sam Drinkard -
Vic Ricker