Oh - the original thought was to re-shuffle/clean-up zone(s) on Master...and
since Slave(s) has this "nice" $ORIGIN paragraphs - would be nice to combine
all these unique $ORIGINs back on Master...
Thanks,
WS
p.s.
By-the-way --- is there any simple way (WITHOUT modifying named.conf) to "axfr"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2011 04:19 PM, Chuck Swiger wrote:
> The adberr count looks like it can only be incremented by two code sections
> in lib/dns/resolver.c:
>
> if (result != ISC_R_SUCCESS) {
> if (result == DNS_R_ALIAS) {
>
On Feb 10, 2011, at 12:39 PM, Ryan Novosielski wrote:
> health.nyc.gov query-errors:
>
> 10-Feb-2011 15:32:30.682 query-errors: debug 1: client
> 130.219.34.129#55935: query failed (SERVFAIL) for health.nyc.gov/IN/MX
> at query.c:4630
> 10-Feb-2011 15:32:30.682 query-errors: debug 2: fetch complet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/10/2011 03:23 PM, Chuck Swiger wrote:
> On Feb 10, 2011, at 11:26 AM, Ryan Novosielski wrote:
>> dig: isc_socket_create: address family not supported
>>
>> I've read that I shouldn't let this error message lead me anywhere in
>> particular. Does
On Feb 10, 2011, at 11:26 AM, Ryan Novosielski wrote:
> dig: isc_socket_create: address family not supported
>
> I've read that I shouldn't let this error message lead me anywhere in
> particular. Does anyone have some advice for where to start
> troubleshooting?
The error message you mention is
On 2/10/2011 10:11 AM, Walter Smith wrote:
> So - I want to combine and sort unique $ORIGINs without seeing same
> $ORIGIN again and again.
The question was asked, but I didn't see an answer... What are you doing
with the zones on the slave server that you think is actually safe to do?
Why not j
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi folks,
I am running into a problem with the Oracle Solaris-delivered BIND9
(BIND 9.6-ESV-R3) that I have running on four DNS servers. I have to
admit my BIND troubleshooting skills aren't what they could be, given
that the product normally "just wo
The order of records in the zone is always going to be determined by a
lexicographical sort by label, the same sort order as would be used by NSEC
records if you were using them.
The $ORIGIN statements are just somebody's idea of a good time. But again,
really inconsequential unless you are act
Yes!
So - I want to combine and sort unique $ORIGINs without seeing same $ORIGIN
again and again.
Like in your example, I would prefer to see just _ONE_ time this sorted
paragraph:
<<$ORIGIN admin.cam.ac.uk. >> and not having multiple entries...
$ORIGIN cam.ac.uk.
admin M
On Feb 10 2011, Barry Margolin wrote:
When writing the zone file on a slave, BIND uses $ORIGIN so that all
records just have a single label. So instead of writing:
foo.bar IN A 1.2.3.4
it will write:
$ORIGIN bar
foo IN A 1.2.3.4
If you have a zone with lots of levels of subdomain, the fil
On 2/10/2011 8:40 AM, Walter Smith wrote:
> Oh Thanks - I understand that - I can't comprehend the logic behind
> composing _same_ $ORIGIN paragraphs over-and-over again - this is an
> example [...]
I'd recommend using "masterfile-format raw;" on the slaves and then you
don't care how BIND takes t
Is it possible to have just single sorted paragraph(s) within all these
repeating $ORIGINs?
Like this:
$ORIGIN bar.
a A 1.2.3.4
b A 1.2.3.5
c A 1.2.3.6
$ORIGIN foo.bar.
a A 1.2.3.44
b A 1.2.3.55
c A 1.2.3.66
$ORIGIN cd-to.bar.
a A 1.2.3.444
b A 1.2.3.555
c A 1.2.3.666
...'cause in my
Oh Thanks - I understand that - I can't comprehend the logic behind composing
_same_ $ORIGIN paragraphs over-and-over again - this is an example:
$ORIGIN bar
irish A 1.2.3.4
brit A 1.2.3.5
$ORIGIN bar2
irish2 A 1.2.3.42
brit2 A 1.2.3.52
$ORIGIN bar
irish3 A 1.2.3.43
brit3 A 1.2.3.53
$ORI
13 matches
Mail list logo
