named mystery

jekillen jekillen at
Tue Dec 11 16:14:45 PST 2007

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, freebsd-questions-request at sent this to 
> stdout:
>> Date: Tue, 11 Dec 2007 06:09:11 -0600
>> From: Derek Ragona <derek at>
>> Subject: Re: named mystery
>> To: jekillen <jekillen at>,	User Questions > 
>> <freebsd-questions at>
>> 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' as i have
> several sites that respond to the same IP.
>>> dig -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 postmaster at 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 -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
>> 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
>> 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 at mailing list
> To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe at"

More information about the freebsd-questions mailing list