Stealth dns and SOA record

[Nicholas Lee]

I was wondering about a small detail in setting up an unpublished dns
primary.

In the SOA record:

@ IN SOA ns.domain nic.domain (...)

Should the ns.domain entry be the published primary nameserver or the server
(unpublished primary) that the domain zone file is served from.

Thanks,
Nicholas

[Barry Margolin]

In article <949540022.216669 at shelley.paradise.net.nz>,

Post by Nicholas Lee
I was wondering about a small detail in setting up an unpublished dns
primary.
@ IN SOA ns.domain nic.domain (...)
Should the ns.domain entry be the published primary nameserver or the server
(unpublished primary) that the domain zone file is served from.

Unless you're doing Dynamic DNS Updating, nothing cares about the
nameserver in the SOA record. If you are, it should be the unpublished
primary, since that's where you want dynamic updates sent, right?

[Nicholas Lee]

"Barry Margolin" <barmar at bbnplanet.com> wrote in message

Post by Barry Margolin
Unless you're doing Dynamic DNS Updating, nothing cares about the
nameserver in the SOA record. If you are, it should be the unpublished
primary, since that's where you want dynamic updates sent, right?

Furthermore, would I be correct in say that NOTIFYs wont work if the
published primary is in the SOA entry and the other published secondaries
slave off it.

So the unpublished primary wont ever decide to send NOTIFY messages out.

Nicholas

[Cricket Liu]

Post by Nicholas Lee
Furthermore, would I be correct in say that NOTIFYs wont work if the
published primary is in the SOA entry and the other published secondaries
slave off it.
So the unpublished primary wont ever decide to send NOTIFY messages out.

No, I think the primary master just uses the intrazone NS records to
determine
where to send NOTIFY messages.

cricket

Acme Byte & Wire
cricket at acmebw.com
www.acmebw.com

Attend the next Internet Software Consortium/Acme Byte & Wire
DNS and BIND class! See www.acmebw.com/training.htm for
the schedule and to register for upcoming classes.

[Nicholas Lee]

"Cricket Liu" <cricket at acmebw.com> wrote in message

Post by Cricket Liu

Post by Nicholas Lee
Furthermore, would I be correct in say that NOTIFYs wont work if the
published primary is in the SOA entry and the other published secondaries
slave off it.
So the unpublished primary wont ever decide to send NOTIFY messages out.

No, I think the primary master just uses the intrazone NS records to
determine
where to send NOTIFY messages.

Huh?

" DNS NOTIFY works like this: [...]. It determines which servers are the
slaves for the zone by looking at the list of NS records in the zone and
*taking out* the one that points to the name server listed in the first
record-specific field in the zone's SOA record as well as the local host."


So I'd be correct in saying that the SOA record is used only by: dynamic
updates, NOTIFYs and zone tranfers?


BTW good book, its saved me a lot of pain.

Nicholas

[Barry Margolin]

In article <949609442.47822 at shelley.paradise.net.nz>,

Post by Nicholas Lee
"Cricket Liu" <cricket at acmebw.com> wrote in message

Post by Cricket Liu

Post by Nicholas Lee
Furthermore, would I be correct in say that NOTIFYs wont work if the
published primary is in the SOA entry and the other published

secondaries

Post by Cricket Liu

Post by Nicholas Lee
slave off it.
So the unpublished primary wont ever decide to send NOTIFY messages out.

No, I think the primary master just uses the intrazone NS records to
determine
where to send NOTIFY messages.

Huh?
" DNS NOTIFY works like this: [...]. It determines which servers are the
slaves for the zone by looking at the list of NS records in the zone and
*taking out* the one that points to the name server listed in the first
record-specific field in the zone's SOA record as well as the local host."

If you're going to put something in the SOA record other than the
unpublished primary, make sure it's not one of the published servers. I'm
not sure what you mean by the distinction between "published primary" and
"published secondary" -- all the published servers are slaves, so none of
them are primary. Ignore the fact that Network Solutions's registration
form still calls the first server "Primary" -- it's a meaningless
distinction.

Post by Nicholas Lee
So I'd be correct in saying that the SOA record is used only by: dynamic
updates, NOTIFYs and zone tranfers?

The MinTTL field is used by caching servers as the negative cache time.
And some lame delegation warning scripts use the point of contact as the
destination for mail.

[Nicholas Lee]

"Barry Margolin" <barmar at bbnplanet.com> wrote in message

Post by Barry Margolin
If you're going to put something in the SOA record other than the
unpublished primary, make sure it's not one of the published servers. I'm

Sure given what people are telling me, unless you want dynamic updates to
works, it shouldn't matter what goes into the SOA as long as it resolves.

Post by Barry Margolin
not sure what you mean by the distinction between "published primary" and
"published secondary" -- all the published servers are slaves, so none of
them are primary. Ignore the fact that Network Solutions's registration
form still calls the first server "Primary" -- it's a meaningless
distinction.

Semantics I guess. Easier to say published primary than published domainz
(in my case) primary (PDP). This is of course seperate from master or
slave.

Tell me, is there a issue with only the PDP slaving to the stealth server
while the PDSs remain slaved to the PDP?

Post by Barry Margolin

Post by Nicholas Lee
So I'd be correct in saying that the SOA record is used only by: dynamic
updates, NOTIFYs and zone tranfers?

The MinTTL field is used by caching servers as the negative cache time.
And some lame delegation warning scripts use the point of contact as the
destination for mail.

Actually one other thing I noticed about the SOA record is that, given the
master zone, if no MX record exists in the db.domain file and a nic.domain
point of contact (POC) record is used in both the db.domain and db."PTR"
files, then named (8.2.2P5) complains on the db."PTR" POC but not the
db.domain POC.


Nicholas

[Barry Margolin]

In article <949615647.556171 at shelley.paradise.net.nz>,

Post by Nicholas Lee
Semantics I guess. Easier to say published primary than published domainz
(in my case) primary (PDP). This is of course seperate from master or
slave.

I usually just say "published servers" and "hidden primary".

Post by Nicholas Lee
Tell me, is there a issue with only the PDP slaving to the stealth server
while the PDSs remain slaved to the PDP?

No. The PDSs will log warnings about getting NOTIFY from a non-master
server, but you can ignore those. We use a similar setup when we provide
slave service for our customers' domains. We have a single stealth slave
server that does the transfer from all the customer masters, and then our
published slaves transfer from the stealth slave. As a result, the
published slaves get NOTIFY messages from the customer masters; they log
the warning and ignore them. We use also-notify on our stealth slave so
that it will notify the published slaves after it has transferred the zone,
and we tell our customers to use also-notify to notify the stealth slave
(but I don't think many of them bother).

Post by Nicholas Lee

Post by Barry Margolin

Post by Nicholas Lee
So I'd be correct in saying that the SOA record is used only by: dynamic
updates, NOTIFYs and zone tranfers?

The MinTTL field is used by caching servers as the negative cache time.
And some lame delegation warning scripts use the point of contact as the
destination for mail.

Actually one other thing I noticed about the SOA record is that, given the
master zone, if no MX record exists in the db.domain file and a nic.domain
point of contact (POC) record is used in both the db.domain and db."PTR"
files, then named (8.2.2P5) complains on the db."PTR" POC but not the
db.domain POC.

I've never heard of named complaining about the POC field at all. What
does it say about them?

[Nicholas Lee]

"Barry Margolin" <barmar at bbnplanet.com> wrote in message

Post by Barry Margolin
I usually just say "published servers" and "hidden primary".

I guess that makes things cleaner.

Post by Barry Margolin

Post by Nicholas Lee
Tell me, is there a issue with only the PDP slaving to the stealth server
while the PDSs remain slaved to the PDP?

No. The PDSs will log warnings about getting NOTIFY from a non-master

Great, thanks for the clarity.

Post by Barry Margolin

Post by Nicholas Lee
Actually one other thing I noticed about the SOA record is that, given the
master zone, if no MX record exists in the db.domain file and a nic.domain
point of contact (POC) record is used in both the db.domain and db."PTR"
files, then named (8.2.2P5) complains on the db."PTR" POC but not the
db.domain POC.

Actually that should be (8.2.2P6 openbsd, rather than 8.2.2P5)

Post by Barry Margolin
I've never heard of named complaining about the POC field at all. What
does it say about them?

Feb 2 18:15:17 water-open named[31688]: reloading nameserver
Feb 2 18:15:17 water-open named[31688]: Zone "kiwa.co.nz" (file
master/db.kiwa): No default TTL set
using SOA minimum instead
Feb 2 18:15:17 water-open named[31688]: master zone "kiwa.co.nz" (IN)
loaded (serial 200020101)
F
Feb 2 18:02:13 water-open named[31688]: Zone "8.168.192.in-addr.arpa" (file
master/db.192.168.8): N
o default TTL set using SOA minimum instead
Feb 2 18:02:13 water-open named[31688]: mail name
"hostmaster.kiwa.co.nz.(.8.168.192.in-addr.arpa"
(owner "8.168.192.in-addr.arpa") IN (primary) is invalid - rejecting
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:1: database
naming error
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:1: Database
error near (bad name "hostm
aster.kiwa.co.nz.(.8.168.192.in-addr.arpa")
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:2: Database
error near ()
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:3: Database
error near ()
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:4: Database
error near ()
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:5: Database
error near ()
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8: Line 6:
Unknown type: ).
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:6: Database
error near ())
Feb 2 18:02:13 water-open named[31688]: Zone "8.168.192.in-addr.arpa" (file
master/db.192.168.8): n
o SOA RR found
Feb 2 18:02:13 water-open named[31688]: master zone
"8.168.192.in-addr.arpa" (IN) rejected due to e
rrors (serial 0)
Feb 2 18:15:17 water-open named[31688]: Forwarding source address is
[0.0.0.0].28545
Feb 2 18:15:17 water-open named[31688]: Ready to answer queries.


I was simply fiddling around at the time trying to get my nslookup working.
So at the time I didn't bother with the MX record for kiwa.co.nz.
When I simply changed the POC from hostmaster.kiwa.co.nz. to
nic_lee.yahoo.com. the error simply went away.

Nicholas

[Nicholas Lee]

"Barry Margolin" <barmar at bbnplanet.com> wrote in message

Post by Barry Margolin
that it will notify the published slaves after it has transferred the zone,
and we tell our customers to use also-notify to notify the stealth slave
(but I don't think many of them bother).

Doesn't seem possible, but it might be nice to turn notify off except for
those listed in also-notify. I don't suppose there is some tricky way of
doing this?

Nicholas

[Cricket Liu]

Post by Nicholas Lee

Post by Cricket Liu

Post by Nicholas Lee
So the unpublished primary wont ever decide to send NOTIFY messages out.

No, I think the primary master just uses the intrazone NS records to
determine
where to send NOTIFY messages.

Huh?
" DNS NOTIFY works like this: [...]. It determines which servers are the
slaves for the zone by looking at the list of NS records in the zone and
*taking out* the one that points to the name server listed in the first
record-specific field in the zone's SOA record as well as the local host."

Right. The "list of records in the zone" is the intrazone NS records.
That's
how a primary master name server figures out where to send NOTIFY
messages. It *doesn't* send NOTIFY messages to itself or to any name
server named in the MNAME field.

Post by Nicholas Lee
So I'd be correct in saying that the SOA record is used only by: dynamic
updates, NOTIFYs and zone tranfers?

Sounds about right.

cricket

Acme Byte & Wire
cricket at acmebw.com
www.acmebw.com

Attend the next Internet Software Consortium/Acme Byte & Wire
DNS and BIND class! See www.acmebw.com/training.htm for
the schedule and to register for upcoming classes.

[Jim Reid]

Nicholas> Furthermore, would I be correct in say that NOTIFYs wont
Nicholas> work if the published primary is in the SOA entry and
Nicholas> the other published secondaries slave off it.

No, not unless you explicitly tell the master (primary) name server
not to send NOTIFYs.

Nicholas> So the unpublished primary wont ever decide to send
Nicholas> NOTIFY messages out.

No. The master server will by default sent NOTIFYs to the NS records
in the newly-loaded zone. All that matters is that the SOA record's
MNAME field is syntactically valid. An old version - 8.1? - of BIND
exhibited the behaviour you describe if the MNAME in the SOA record
didn't point at the master server, but that code is history now. The
only requirement to list the master name server in the SOA MNAME is if
dynamic DNS is used. It's the only way of reliably identifying the
master server and dynamic DNS clients need to know this.

[Nicholas Lee]

"Jim Reid" <jim at rfc1035.com> wrote in message

Post by Jim Reid
No. The master server will by default sent NOTIFYs to the NS records
in the newly-loaded zone. All that matters is that the SOA record's
MNAME field is syntactically valid. An old version - 8.1? - of BIND
exhibited the behaviour you describe if the MNAME in the SOA record
didn't point at the master server, but that code is history now. The
only requirement to list the master name server in the SOA MNAME is if
dynamic DNS is used. It's the only way of reliably identifying the
master server and dynamic DNS clients need to know this.

That is the behaviour I think I'm seeing with (openbsd) 8.2.2P6. When I
changed SOA primary ns record from the published primary to the unpublished
one, the logs indicated that:

Feb 3 23:10:51 water named[9020]: master zone "kiwa.co.nz" (IN) loaded
(serial 2000020311)
Feb 3 23:10:51 water named[9020]: Forwarding source address is
[0.0.0.0].10751
Feb 3 23:10:51 water named[9020]: Ready to answer queries.
Feb 3 23:11:16 water named[9020]: Sent NOTIFY for "kiwa.co.nz IN SOA"
(kiwa.co.nz); 1 NS, 1 A
Feb 3 23:11:53 water named[9020]: reloading nameserver
Feb 3 23:11:53 water named[9020]: Zone "kiwa.co.nz" (file master/db.kiwa):
No default TTL set using
SOA minimum instead
Feb 3 23:11:53 water named[9020]: master zone "kiwa.co.nz" (IN) loaded
(serial 2000020312)
Feb 3 23:11:53 water named[9020]: Forwarding source address is
[0.0.0.0].27186
Feb 3 23:11:53 water named[9020]: Ready to answer queries.
Feb 3 23:12:18 water named[9020]: Sent NOTIFY for "kiwa.co.nz IN SOA"
(kiwa.co.nz); 2 NS, 2 A
Feb 3 23:12:18 water named[9020]: Received NOTIFY answer from 203.96.152.4
for "kiwa.co.nz IN SOA"

Where 2000020311 had the 203.96.152.4 nameserver as primary and 2000020312
had water as primary in the SOA record.



Nicholas

[Mark.Andrews]

Post by Nicholas Lee
"Barry Margolin" <barmar at bbnplanet.com> wrote in message

Post by Barry Margolin
I usually just say "published servers" and "hidden primary".

I guess that makes things cleaner.

Post by Barry Margolin

Post by Nicholas Lee
Tell me, is there a issue with only the PDP slaving to the stealth server
while the PDSs remain slaved to the PDP?

No. The PDSs will log warnings about getting NOTIFY from a non-master

Great, thanks for the clarity.

Post by Barry Margolin

Post by Nicholas Lee
Actually one other thing I noticed about the SOA record is that, given

the

Post by Barry Margolin

Post by Nicholas Lee
master zone, if no MX record exists in the db.domain file and a

nic.domain

Post by Barry Margolin

Post by Nicholas Lee
point of contact (POC) record is used in both the db.domain and db."PTR"
files, then named (8.2.2P5) complains on the db."PTR" POC but not the
db.domain POC.

Actually that should be (8.2.2P6 openbsd, rather than 8.2.2P5)

Post by Barry Margolin
I've never heard of named complaining about the POC field at all. What
does it say about them?

Feb 2 18:15:17 water-open named[31688]: reloading nameserver
Feb 2 18:15:17 water-open named[31688]: Zone "kiwa.co.nz" (file
master/db.kiwa): No default TTL set
using SOA minimum instead
Feb 2 18:15:17 water-open named[31688]: master zone "kiwa.co.nz" (IN)
loaded (serial 200020101)
F
Feb 2 18:02:13 water-open named[31688]: Zone "8.168.192.in-addr.arpa" (file
master/db.192.168.8): N
o default TTL set using SOA minimum instead
Feb 2 18:02:13 water-open named[31688]: mail name
"hostmaster.kiwa.co.nz.(.8.168.192.in-addr.arpa"
(owner "8.168.192.in-addr.arpa") IN (primary) is invalid - rejecting
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:1: database
naming error
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:1: Database
error near (bad name "hostm
aster.kiwa.co.nz.(.8.168.192.in-addr.arpa")
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:2: Database
error near ()
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:3: Database
error near ()
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:4: Database
error near ()
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:5: Database
error near ()
Unknown type: ).
Feb 2 18:02:13 water-open named[31688]: master/db.192.168.8:6: Database
error near ())
Feb 2 18:02:13 water-open named[31688]: Zone "8.168.192.in-addr.arpa" (file
master/db.192.168.8): n
o SOA RR found
Feb 2 18:02:13 water-open named[31688]: master zone
"8.168.192.in-addr.arpa" (IN) rejected due to e
rrors (serial 0)
Feb 2 18:15:17 water-open named[31688]: Forwarding source address is
[0.0.0.0].28545
Feb 2 18:15:17 water-open named[31688]: Ready to answer queries.
I was simply fiddling around at the time trying to get my nslookup working.
So at the time I didn't bother with the MX record for kiwa.co.nz.
When I simply changed the POC from hostmaster.kiwa.co.nz. to
nic_lee.yahoo.com. the error simply went away.

No you also added the missing space before the "(".

e.g.
"hostmaster.kiwa.co.nz.(" -> "nic_lee.yahoo.com. ("

Mark

Post by Nicholas Lee
Nicholas

--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone] INTERNET: Mark.Andrews at nominum.com