Re: named mystery
At 12:57 AM 12/10/2007, jekillen wrote: Hello: I have two name servers for four domains. The primary name server is running FreeBSD v 6.0 and the secondary is running v 6.2. I have an MX record for each of the four registered domains. I have set up Postfix to act as a smart host mail hub (the MX host). One of the named record database is for one of the sites. When I try to send an E-mail from this message to list e-mail address. The messages bounce for dns lookup failure. The name that is being looked up is mxhost.domainName.tld.targetDomainName.tld Some how the two names are being mashed together and then looked up, causing the resolution failure. dig targetDomainName.com -t MX produces the record according to my ISP's name servers, which is the mashed version. Possibly they have it wrong? Someone is screwing up the lookup for this. There was a period missing after the MX host name record. I added that and rebooted the machine with the primary name server just to insure that named got the change and checked the secondary record and it has the change I did dig @targerDomainName.com -t MX and got my secondary name server responding. I checked the primary server to see that it is actually running at the time, it was and is. but the bak file on the secondary server has clip IN MX 10 host.domain.tld. $ORIGIN targetDomain.tld. /clip when the record on primary server is clip @ IN MX 10 host.domain.tld. /clip @ in this context should reference the domain this file is for. If anyone is a wiz at dns record and problems can you make any suggestions or recommendations? thank you in advance Jeff K Jeff, I just checked how my DNS files look on two 6.2 servers. The primary zone files will have the: @ while the secondary zone files will not have these. In my zone files the MX appears on the primary as a the lines: ; MX Record @ IN MX 10 mail.mydomain.com. Note the last period after the domain suffix is there to show it is a fully qualified name, with that name defined earlier in this zone file. On the secondary server the zone files has: MX 10 mail.mydomain.com. In both files the 10 is the weight for the MX record. If you have multiple servers you want to accept email, you would use this number to designate the order they should get mail, smaller numbers are primary to get email. When you make a change on the primary DNS server zone file be sure to change the serial number in that zone file. Also I usually stop and start named on the primary. I also remove the backup files on the secondary servers and stop and start named on those too to see that the new files are transferred and thus being used. Hope this helps. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named mystery
On Tue, Dec 11, 2007 at 18:23 , while impersonating an expert on the internet, [EMAIL PROTECTED] sent this to stdout: Date: Tue, 11 Dec 2007 06:09:11 -0600 From: Derek Ragona [EMAIL PROTECTED] Subject: Re: named mystery To: jekillen [EMAIL PROTECTED], User Questions freebsd-questions@freebsd.org At 12:57 AM 12/10/2007, jekillen wrote: Hello: I have two name servers for four domains. The primary name server is running FreeBSD v 6.0 and the secondary is running v 6.2. I have an MX record for each of the four registered domains. I have set up Postfix to act as a smart host mail hub (the MX host). One of the named record database is for one of the sites. When I try to send an E-mail from this message to list e-mail address. The messages bounce for dns lookup failure. The name that is being looked up is mxhost.domainName.tld.targetDomainName.tld Some how the two names are being mashed together and then looked up, causing the resolution failure. As the other respondent noted, that was because of the missing period. I've found that 'nslint' in the /usr/ports/dns hierarchy is a nice little program that will tell you all your errors. I actually run it's output through a 'filter' to get rid of extranous things such as 'in use by .xxx' as i have several sites that respond to the same IP. dig targetDomainName.com -t MX produces the record according to my ISP's name servers, which is the mashed version. Possibly they have it wrong? Someone is screwing up the lookup for this. There was a period missing after the MX host name record. I added that and rebooted the machine with the primary name server just to insure that named got the change and checked the secondary record and it has the change You don't have to reboot Unix systems for almost all things which don't require a kernel change. named.restart will do the job. I did dig @targerDomainName.com -t MX and got my secondary name server responding. I checked the primary server to see that it is actually running at the time, it was and is. but the bak file on the secondary server has clip IN MX 10 host.domain.tld. $ORIGIN targetDomain.tld. /clip when the record on primary server is clip @ IN MX 10 host.domain.tld. /clip @ in this context should reference the domain this file is for. If anyone is a wiz at dns record and problems can you make any suggestions or recommendations? thank you in advance Jeff K Jeff, I just checked how my DNS files look on two 6.2 servers. The primary zone files will have the: @ while the secondary zone files will not have these. In my zone files the MX appears on the primary as a the lines: ; MX Record @ IN MX 10 mail.mydomain.com. Note the last period after the domain suffix is there to show it is a fully qualified name, with that name defined earlier in this zone file. On the secondary server the zone files has: MX 10 mail.mydomain.com. In both files the 10 is the weight for the MX record. If you have multiple servers you want to accept email, you would use this number to designate the order they should get mail, smaller numbers are primary to get email. When you make a change on the primary DNS server zone file be sure to change the serial number in that zone file. Also I usually stop and start named on the primary. I also remove the backup files on the secondary servers and stop and start named on those too to see that the new files are transferred and thus being used. I have about 250 zones in my DNS and I've done something which makes sure that I always have the correct date, but all the domains will show the same date. I've extracted much of what you put in a zone file and put it in a file called named.soa . And in each file is used the $INCLUDE directive [quite handy] that is $INCLUDE named.soa Then I just update the serial number in the one file. It saves a lot of time, particualary yesterday when one client of a support house that uses our servers decided he needed all the standard variants .com, .net, .biz, .mobi, .info, .org, and .tv - plus 5 variants on his domain. I'd just dupe the zone file and make global changes in 'vi' and only have to update the serial number in the named.soa just one time. Bill -- Bill Vermillion - bv @ wjv . com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: named mystery
At 01:24 PM 12/11/2007, Bill Vermillion wrote: On Tue, Dec 11, 2007 at 18:23 , while impersonating an expert on the internet, [EMAIL PROTECTED] sent this to stdout: Date: Tue, 11 Dec 2007 06:09:11 -0600 From: Derek Ragona [EMAIL PROTECTED] Subject: Re: named mystery To: jekillen [EMAIL PROTECTED], User Questions freebsd-questions@freebsd.org At 12:57 AM 12/10/2007, jekillen wrote: Hello: I have two name servers for four domains. The primary name server is running FreeBSD v 6.0 and the secondary is running v 6.2. I have an MX record for each of the four registered domains. I have set up Postfix to act as a smart host mail hub (the MX host). One of the named record database is for one of the sites. When I try to send an E-mail from this message to list e-mail address. The messages bounce for dns lookup failure. The name that is being looked up is mxhost.domainName.tld.targetDomainName.tld Some how the two names are being mashed together and then looked up, causing the resolution failure. As the other respondent noted, that was because of the missing period. I've found that 'nslint' in the /usr/ports/dns hierarchy is a nice little program that will tell you all your errors. I actually run it's output through a 'filter' to get rid of extranous things such as 'in use by .xxx' as i have several sites that respond to the same IP. dig targetDomainName.com -t MX produces the record according to my ISP's name servers, which is the mashed version. Possibly they have it wrong? Someone is screwing up the lookup for this. There was a period missing after the MX host name record. I added that and rebooted the machine with the primary name server just to insure that named got the change and checked the secondary record and it has the change You don't have to reboot Unix systems for almost all things which don't require a kernel change. named.restart will do the job. I did dig @targerDomainName.com -t MX and got my secondary name server responding. I checked the primary server to see that it is actually running at the time, it was and is. but the bak file on the secondary server has clip IN MX 10 host.domain.tld. $ORIGIN targetDomain.tld. /clip when the record on primary server is clip @ IN MX 10 host.domain.tld. /clip @ in this context should reference the domain this file is for. If anyone is a wiz at dns record and problems can you make any suggestions or recommendations? thank you in advance Jeff K Jeff, I just checked how my DNS files look on two 6.2 servers. The primary zone files will have the: @ while the secondary zone files will not have these. In my zone files the MX appears on the primary as a the lines: ; MX Record @ IN MX 10 mail.mydomain.com. Note the last period after the domain suffix is there to show it is a fully qualified name, with that name defined earlier in this zone file. On the secondary server the zone files has: MX 10 mail.mydomain.com. In both files the 10 is the weight for the MX record. If you have multiple servers you want to accept email, you would use this number to designate the order they should get mail, smaller numbers are primary to get email. When you make a change on the primary DNS server zone file be sure to change the serial number in that zone file. Also I usually stop and start named on the primary. I also remove the backup files on the secondary servers and stop and start named on those too to see that the new files are transferred and thus being used. I have about 250 zones in my DNS and I've done something which makes sure that I always have the correct date, but all the domains will show the same date. I've extracted much of what you put in a zone file and put it in a file called named.soa . And in each file is used the $INCLUDE directive [quite handy] that is $INCLUDE named.soa Then I just update the serial number in the one file. It saves a lot of time, particualary yesterday when one client of a support house that uses our servers decided he needed all the standard variants .com, .net, .biz, .mobi, .info, .org, and .tv - plus 5 variants on his domain. I'd just dupe the zone file and make global changes in 'vi' and only have to update the serial number in the named.soa just one time. Bill Bill, I didn't know about the include statement, I will do that with my zone files too. Good to know about the nslint utility too. I am one who makes typos, so it will be a good way to make sure the files are at least syntax correct. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any
Re: named mystery
Derek Ragona, the prominent pundit, on Tue, Dec 11, 2007 at 13:36 while half mumbling, half-witicized: At 01:24 PM 12/11/2007, Bill Vermillion wrote: On Tue, Dec 11, 2007 at 18:23 , while impersonating an expert on the internet, [EMAIL PROTECTED] sent this to stdout: Date: Tue, 11 Dec 2007 06:09:11 -0600 From: Derek Ragona [EMAIL PROTECTED] Subject: Re: named mystery To: jekillen [EMAIL PROTECTED], User Questions freebsd-questions@freebsd.org At 12:57 AM 12/10/2007, jekillen wrote: Hello: [lots of stuff snipped - wjv] I have two name servers for four domains. The primary name server is running FreeBSD v 6.0 and the secondary is running v 6.2. I have an MX record for each of the four registered domains. I have set up Postfix to act as a smart host mail hub (the MX host). One of the named record database is for one of the sites. When I try to send an E-mail from this message to list e-mail address. The messages bounce for dns lookup failure. The name that is being looked up is mxhost.domainName.tld.targetDomainName.tld Some how the two names are being mashed together and then looked up, causing the resolution failure. As the other respondent noted, that was because of the missing period. I've found that 'nslint' in the /usr/ports/dns hierarchy is a nice little program that will tell you all your errors. I actually run it's output through a 'filter' to get rid of extranous things such as 'in use by .xxx' as i have several sites that respond to the same IP. There was a period missing after the MX host name record. I added that and rebooted the machine with the primary name server just to insure that named got the change and checked the secondary record and it has the change You don't have to reboot Unix systems for almost all things which don't require a kernel change. named.restart will do the job. Jeff, I just checked how my DNS files look on two 6.2 servers. The primary zone files will have the: @ while the secondary zone files will not have these. In my zone files the MX appears on the primary as a the lines: ; MX Record @ IN MX 10 mail.mydomain.com. Note the last period after the domain suffix is there to show it is a fully qualified name, with that name defined earlier in this zone file. When you make a change on the primary DNS server zone file be sure to change the serial number in that zone file. Also I usually stop and start named on the primary. I also remove the backup files on the secondary servers and stop and start named on those too to see that the new files are transferred and thus being used. I have about 250 zones in my DNS and I've done something which makes sure that I always have the correct date, but all the domains will show the same date. I've extracted much of what you put in a zone file and put it in a file called named.soa . And in each file is used the $INCLUDE directive [quite handy] that is $INCLUDE named.soa Then I just update the serial number in the one file. It saves a lot of time, particualary yesterday when one client of a support house that uses our servers decided he needed all the standard variants .com, .net, .biz, .mobi, .info, .org, and .tv - plus 5 variants on his domain. I'd just dupe the zone file and make global changes in 'vi' and only have to update the serial number in the named.soa just one time. Bill Bill, I didn't know about the include statement, I will do that with my zone files too. There are many shortcuts availabe and I don't use many of them. I first had to learn and put up DNS on an SCO server back in about 1994 when a local community-college for whom I was doing data base work, needed to get an internet connection. So it was sendmail on SCO - in the 4.x variety and then I took the best parts of the O'Reily book and the SCO docs and came up with my own variant. The SCO system did use the $INCLUDE. And I've used that ever since. I also have machines in our own domain - plus others - so I have the named.conf pointing to a sub-directory called 'sites' that are domains that don't belong to us. And I always found the xx.xx.xx.xx.in-addr.arpa a bit confusing to look at in a directory so I map that to files called named.rev.63.209.114 [and others] so when I search the directory the last relative quad in the listing is last. So when I need to change the reverse file it is just vi *.114. I'm lazy!! The named.hosts has all the IP addresses in it, and the only ones that are 'active' are the domains we control, BUT I have the domain listing for others with a leading ; but the name and IP in the list. This way I can scan that and find out just what IPs are in use. Little things like that make admininstering things much easier, at least for me. Good to know about the nslint utility too. I am one who makes typos, so it will be a good way to make sure the files are at least syntax
Re: named mystery
On Dec 11, 2007, at 11:24 AM, Bill Vermillion wrote: On Tue, Dec 11, 2007 at 18:23 , while impersonating an expert on the internet, [EMAIL PROTECTED] sent this to stdout: Date: Tue, 11 Dec 2007 06:09:11 -0600 From: Derek Ragona [EMAIL PROTECTED] Subject: Re: named mystery To: jekillen [EMAIL PROTECTED], User Questions freebsd-questions@freebsd.org At 12:57 AM 12/10/2007, jekillen wrote: Hello: I have two name servers for four domains. The primary name server is running FreeBSD v 6.0 and the secondary is running v 6.2. I have an MX record for each of the four registered domains. I have set up Postfix to act as a smart host mail hub (the MX host). One of the named record database is for one of the sites. When I try to send an E-mail from this message to list e-mail address. The messages bounce for dns lookup failure. The name that is being looked up is mxhost.domainName.tld.targetDomainName.tld Some how the two names are being mashed together and then looked up, causing the resolution failure. As the other respondent noted, that was because of the missing period. I've found that 'nslint' in the /usr/ports/dns hierarchy is a nice little program that will tell you all your errors. I actually run it's output through a 'filter' to get rid of extranous things such as 'in use by .xxx' as i have several sites that respond to the same IP. dig targetDomainName.com -t MX produces the record according to my ISP's name servers, which is the mashed version. Possibly they have it wrong? Someone is screwing up the lookup for this. There was a period missing after the MX host name record. I added that and rebooted the machine with the primary name server just to insure that named got the change and checked the secondary record and it has the change You don't have to reboot Unix systems for almost all things which don't require a kernel change. named.restart will do the job. Happy day This is the first time I've seen this command. All the stuff I have uses rndc reload etc. Right now rndc isn't working (access denied, if it does that for me, I don't think I have anything to worry about) and I do not want to fool with it at the moment. Maybe sometime when I've won the lottery and am bored to death with chasing women. So my quick (impatient) approach was just to reboot. Any how dig turns up the right stuff now, accept that I was still getting a reject message from my ISP's server for lookup failure; with no explanation. So I did [EMAIL PROTECTED] and related my sad tail. I think they may be caching responses and rejecting based on a cached response. I will have to see. Jeff K I did dig @targerDomainName.com -t MX and got my secondary name server responding. I checked the primary server to see that it is actually running at the time, it was and is. but the bak file on the secondary server has clip IN MX 10 host.domain.tld. $ORIGIN targetDomain.tld. /clip when the record on primary server is clip @ IN MX 10 host.domain.tld. /clip @ in this context should reference the domain this file is for. If anyone is a wiz at dns record and problems can you make any suggestions or recommendations? thank you in advance Jeff K Jeff, I just checked how my DNS files look on two 6.2 servers. The primary zone files will have the: @ while the secondary zone files will not have these. In my zone files the MX appears on the primary as a the lines: ; MX Record @ IN MX 10 mail.mydomain.com. Note the last period after the domain suffix is there to show it is a fully qualified name, with that name defined earlier in this zone file. On the secondary server the zone files has: MX 10 mail.mydomain.com. In both files the 10 is the weight for the MX record. If you have multiple servers you want to accept email, you would use this number to designate the order they should get mail, smaller numbers are primary to get email. When you make a change on the primary DNS server zone file be sure to change the serial number in that zone file. Also I usually stop and start named on the primary. I also remove the backup files on the secondary servers and stop and start named on those too to see that the new files are transferred and thus being used. I have about 250 zones in my DNS and I've done something which makes sure that I always have the correct date, but all the domains will show the same date. I've extracted much of what you put in a zone file and put it in a file called named.soa . And in each file is used the $INCLUDE directive [quite handy] that is $INCLUDE named.soa Then I just update the serial number in the one file. It saves a lot of time, particualary yesterday when one client of a support house that uses our servers decided he needed all the standard variants .com, .net, .biz, .mobi, .info, .org, and .tv - plus 5 variants on his domain. I'd just dupe the zone file and make global changes in 'vi
Re: named mystery
On Dec 11, 2007, at 4:09 AM, Derek Ragona wrote: At 12:57 AM 12/10/2007, jekillen wrote: Hello: I have two name servers for four domains. The primary name server is running FreeBSD v 6.0 and the secondary is running v 6.2. I have an MX record for each of the four registered domains. I have set up Postfix to act as a smart host mail hub (the MX host). One of the named record database is for one of the sites. When I try to send an E-mail from this message to list e-mail address. The messages bounce for dns lookup failure. The name that is being looked up is mxhost.domainName.tld.targetDomainName.tld Some how the two names are being mashed together and then looked up, causing the resolution failure. dig targetDomainName.com -t MX produces the record according to my ISP's name servers, which is the mashed version. Possibly they have it wrong? Someone is screwing up the lookup for this. There was a period missing after the MX host name record. I added that and rebooted the machine with the primary name server just to insure that named got the change and checked the secondary record and it has the change I did dig @targerDomainName.com -t MX and got my secondary name server responding. I checked the primary server to see that it is actually running at the time, it was and is. but the bak file on the secondary server has clip IN MX 10 host.domain.tld. $ORIGIN targetDomain.tld. /clip when the record on primary server is clip @ IN MX 10 host.domain.tld. /clip @ in this context should reference the domain this file is for. If anyone is a wiz at dns record and problems can you make any suggestions or recommendations? thank you in advance Jeff K Jeff, I just checked how my DNS files look on two 6.2 servers. The primary zone files will have the: @ while the secondary zone files will not have these. In my zone files the MX appears on the primary as a the lines: ; MX Record @ IN MX 10 mail.mydomain.com. Note the last period after the domain suffix is there to show it is a fully qualified name, with that name defined earlier in this zone file. On the secondary server the zone files has: MX 10 mail.mydomain.com. In both files the 10 is the weight for the MX record. If you have multiple servers you want to accept email, you would use this number to designate the order they should get mail, smaller numbers are primary to get email. When you make a change on the primary DNS server zone file be sure to change the serial number in that zone file. Also I usually stop and start named on the primary. I also remove the backup files on the secondary servers and stop and start named on those too to see that the new files are transferred and thus being used. Yes, I did increment the serial number and put in the final dot. I am still getting test messages rejected for name service lookup failure--with no explanation. I contacted the isp about it. It seems as though the rejection was base on a cached response. Thanks for the info; Jeff K ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
named mystery
Hello: I have two name servers for four domains. The primary name server is running FreeBSD v 6.0 and the secondary is running v 6.2. I have an MX record for each of the four registered domains. I have set up Postfix to act as a smart host mail hub (the MX host). One of the named record database is for one of the sites. When I try to send an E-mail from this message to list e-mail address. The messages bounce for dns lookup failure. The name that is being looked up is mxhost.domainName.tld.targetDomainName.tld Some how the two names are being mashed together and then looked up, causing the resolution failure. dig targetDomainName.com -t MX produces the record according to my ISP's name servers, which is the mashed version. Possibly they have it wrong? Someone is screwing up the lookup for this. There was a period missing after the MX host name record. I added that and rebooted the machine with the primary name server just to insure that named got the change and checked the secondary record and it has the change I did dig @targerDomainName.com -t MX and got my secondary name server responding. I checked the primary server to see that it is actually running at the time, it was and is. but the bak file on the secondary server has clip IN MX 10 host.domain.tld. $ORIGIN targetDomain.tld. /clip when the record on primary server is clip @ IN MX 10 host.domain.tld. /clip @ in this context should reference the domain this file is for. If anyone is a wiz at dns record and problems can you make any suggestions or recommendations? thank you in advance Jeff K ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
