MNAME not a listed NS record

[Dave Warren]

Is there anything technically wrong with having a SOA MNAME field that
isn't listed as a NS record?

The server listed as MNAME will host the zone and is authoritative for
the zone, but out of latency concerns it isn't ideal to have other
resolvers querying this server.

Various online DNS diagnostic tools throw warnings, but as far as I can
tell from the RFCs, this is a valid configuration. Is it valid? Are
there any operational gotchas to be aware of or can I ignore the "warnings"?

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

[Chuck Swiger]

On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
> Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record?

Sure. The SOA MNAME is expected to be the "primary master" nameserver for the zone; it's where things like dhcpd and such send dynamic updates for the zone to.

> The server listed as MNAME will host the zone and is authoritative for the zone, but out of latency concerns it isn't ideal to have other resolvers querying this server.

Okay...so why would you use that nameserver at all, then?

Choose a nameserver which is suitable for other resolvers to query for your master.

> Various online DNS diagnostic tools throw warnings, but as far as I can tell from the RFCs, this is a valid configuration. Is it valid? Are there any operational gotchas to be aware of or can I ignore the "warnings"?

It's not valid, but if you aren't doing dynamic updates to the zone, and you can live without SOA serial # sanity checking by slave nameservers trying to determine whether the zone has been updated or not by checking with the MNAME server, sure, you can setup DNS in such a fashion and (probably) nothing else would break.

Regards,
--
-Chuck

[Ben Croswell]

There is no issue with a configuration like this. It is the very definition of a stealth master and is a very common configuration. Any DDNS updates will continue to reach the stealth master via the mname and no resolvers will find the master via NS records so it won't be queried.

On Jan 16, 2013 3:42 PM, "Dave Warren" <li...@hireahit.com> wrote:

Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record?

The server listed as MNAME will host the zone and is authoritative for the zone, but out of latency concerns it isn't ideal to have other resolvers querying this server.

Various online DNS diagnostic tools throw warnings, but as far as I can tell from the RFCs, this is a valid configuration. Is it valid? Are there any operational gotchas to be aware of or can I ignore the "warnings"?

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Barry Margolin]

In article <mailman.1077.1358370...@lists.isc.org>,

Chuck Swiger <csw...@mac.com> wrote:

> On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
> > Is there anything technically wrong with having a SOA MNAME field that
> > isn't listed as a NS record?
>
> Sure. The SOA MNAME is expected to be the "primary master" nameserver for
> the zone; it's where things like dhcpd and such send dynamic updates for the
> zone to.

But that doesn't mean it should be the server for resolver queries.

>
> > The server listed as MNAME will host the zone and is authoritative for the
> > zone, but out of latency concerns it isn't ideal to have other resolvers
> > querying this server.
>
> Okay...so why would you use that nameserver at all, then?
>
> Choose a nameserver which is suitable for other resolvers to query for your
> master.

The master could be behind a firewall that only allows the published
nameservers to connect to it.

The performance requirements of a nameserver that serves public queries
are different from a server that only has to respond to zone transfer
requests from the published nameservers.

> > Various online DNS diagnostic tools throw warnings, but as far as I can
> > tell from the RFCs, this is a valid configuration. Is it valid? Are there
> > any operational gotchas to be aware of or can I ignore the "warnings"?

Consider this a sanity check, in case you intended to list one of the NS
records but made a typo, not a validity check.

--
Barry Margolin
Arlington, MA

[Chuck Swiger]

On Jan 16, 2013, at 1:42 PM, Barry Margolin wrote:
> In article <mailman.1077.1358370...@lists.isc.org>,
> Chuck Swiger <csw...@mac.com> wrote:
>

>> On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
>>> Is there anything technically wrong with having a SOA MNAME field that
>>> isn't listed as a NS record?
>>
>> Sure. The SOA MNAME is expected to be the "primary master" nameserver for
>> the zone; it's where things like dhcpd and such send dynamic updates for the
>> zone to.
>

> But that doesn't mean it should be the server for resolver queries.

True, but I don't see much utility from a nameserver which can be dynamically
updated but not queried.

>>> The server listed as MNAME will host the zone and is authoritative for the
>>> zone, but out of latency concerns it isn't ideal to have other resolvers
>>> querying this server.
>>
>> Okay...so why would you use that nameserver at all, then?
>>
>> Choose a nameserver which is suitable for other resolvers to query for your
>> master.
>

> The master could be behind a firewall that only allows the published
> nameservers to connect to it.

Sure. In which case, why publish an internal-only machine into the public
DNS via your SOA record? Someone else made mention of a "stealth master",
but my definition of that is an internal machine which is not visible in
any publicly published records.

> The performance requirements of a nameserver that serves public queries
> are different from a server that only has to respond to zone transfer
> requests from the published nameservers.

True. Handling AFXRs isn't much work, and you can always revert to other methods
of replicating zone data if need be, so my primary concern is making nameservers
work well enough to handle the query load, and not to make nameservers just handle
zone transfers.

Regards,
--
-Chuck

[Vernon Schryver]

> From: Dave Warren <li...@hireahit.com>

> Various online DNS diagnostic tools throw warnings,

Speaking of so called DNS diagnostic tools, one claims that my domains
have DNS servers with "private" network addresses. My only guess is
that they don't know the difference between IPv6 addresses and
RFC 1918 addresses. On the other hand, maybe that was random FUD
intended to drum up business, because they've stopped that nonsense
in the last 3 days and without my changing anything.

Another tool claims that ns3.isc-sns.info is "not sending glue" for
one of my domains.

That one is among the several that claim that having a single MX record
is a defect instead of a feature in this century. (On today's Internet,
where all SMTP clients from which you might want to receive mail can
reach all of your SMTP servers at almost any time and do proper queuing
for during very rare exceptions, one needs only one MX RR. Unless you
want to load balance millions of messages per day among SMTP servers
on multiple networks, you want a single a MX RR to avoid spam backscatter
without having to synchronize your definition of "valid mailbox" at
the distributed SMPT servers needed in the multiple-MX wisdom of the
previous century....well, there is the exception of bogus MX RRs for
trapping spam.)

Then there is the supposed dire insecurity of answering
`dig ch version.bind txt`

Let's not forget the popular DNS checkers that claim my SMTP servers
are open relays. Don't ask me about technical connections to DNS
health in seeing whether an SMTP Rcpt_To command is answered with
250_Ok. The spammers who continually hit my SMTP servers with floods
of checks of common holes in relay authentication and authorization
evidently know that 250_Ok even at the end of a DATA command doesn't
indicate that an SMTP server has relayed anything.


There is a common thread among the bogus DNS health checks from outfits
in the DNS help business and the worst domain registrars. Their sales
stories are based on the notion that DNS, HTTP, SMTP, and the Internet
in general are too complicated, dangerous, and generally scary for
mere humans to handle, and so you'd better buy their patent medicine.
On the other hand, good outfits simply sell competent services, perhaps
including technical support, but always without acting like proverbial
used car and computer saleslime.


Vernon Schryver v...@rhyolite.com

[Mike Hoskins (michoski)]

-----Original Message-----

From: Vernon Schryver <v...@rhyolite.com>
Date: Wednesday, January 16, 2013 5:05 PM
To: "bind-...@lists.isc.org" <bind-...@lists.isc.org>
Subject: Re: MNAME not a listed NS record

>> From: Dave Warren <li...@hireahit.com>
>
>> Various online DNS diagnostic tools throw warnings,
>
>Speaking of so called DNS diagnostic tools, one claims that my domains
>have DNS servers with "private" network addresses. My only guess is
>that they don't know the difference between IPv6 addresses and
>RFC 1918 addresses. On the other hand, maybe that was random FUD
>intended to drum up business, because they've stopped that nonsense
>in the last 3 days and without my changing anything.

Same thing here. It's important to remember these tools are written by
humans that also have busy mornings where they don't get to drink enough
coffee... :-)

Awhile back we updated an internal tool that generates DNS records as part
of a hosted email solution and one of these tools started baulking.
Everything we were doing was RFC compliant, but the tool turned red. This
spawned a lot of calls to support from customers who took the tool as an
omniscient being, support escalated to management because the customer is
always right (and were threatening to go elsewhere even after being
pointed to relevant RFCs and walking through dig showing everything worked
just fine in practice).

After triple-checking the RFCs and contacting the maintainer with our
justification, the tool started doing the right thing a few weeks later.

So now we need tools that check the tools, and they need to be written by
omniscient beings...

Failing that, the big thing I hope folks learn from this is that automated
tools written by third parties are helpful at times, but no substitute for
familiarity with standards and generally understanding how things work.

[Barry Margolin]

In article <mailman.1080.1358373...@lists.isc.org>,

Chuck Swiger <csw...@mac.com> wrote:

> On Jan 16, 2013, at 1:42 PM, Barry Margolin wrote:
> > In article <mailman.1077.1358370...@lists.isc.org>,
> > Chuck Swiger <csw...@mac.com> wrote:
> >
> >> On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
> >>> Is there anything technically wrong with having a SOA MNAME field that
> >>> isn't listed as a NS record?
> >>
> >> Sure. The SOA MNAME is expected to be the "primary master" nameserver for
> >> the zone; it's where things like dhcpd and such send dynamic updates for
> >> the
> >> zone to.
> >
> > But that doesn't mean it should be the server for resolver queries.
>
> True, but I don't see much utility from a nameserver which can be dynamically
> updated but not queried.

Who says you're using dynamic update? The MNAME field has been part of
the DNS standard since long before DHCP and dynamic update. In many
instances it's just an FYI field.

>
> >>> The server listed as MNAME will host the zone and is authoritative for
> >>> the
> >>> zone, but out of latency concerns it isn't ideal to have other resolvers
> >>> querying this server.
> >>
> >> Okay...so why would you use that nameserver at all, then?
> >>
> >> Choose a nameserver which is suitable for other resolvers to query for
> >> your
> >> master.
> >
> > The master could be behind a firewall that only allows the published
> > nameservers to connect to it.
>
> Sure. In which case, why publish an internal-only machine into the public
> DNS via your SOA record? Someone else made mention of a "stealth master",
> but my definition of that is an internal machine which is not visible in
> any publicly published records.

You have to put something in the MNAME. You could lie and put one of the
public nameservers, but why do that when you could put the true master?

>
> > The performance requirements of a nameserver that serves public queries
> > are different from a server that only has to respond to zone transfer
> > requests from the published nameservers.
>
> True. Handling AFXRs isn't much work, and you can always revert to other
> methods
> of replicating zone data if need be, so my primary concern is making
> nameservers
> work well enough to handle the query load, and not to make nameservers just
> handle
> zone transfers.

Do that on the public nameservers. The hidden master doesn't need to be
dedicated to nameserving, since it's not handling all the load that the
public servers do.

[Chuck Swiger]

On Jan 16, 2013, at 4:30 PM, Barry Margolin wrote:
[ ... ]

>>>> On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
>>>>> Is there anything technically wrong with having a SOA MNAME field that
>>>>> isn't listed as a NS record?
>>>>
>>>> Sure. The SOA MNAME is expected to be the "primary master" nameserver for
>>>> the zone; it's where things like dhcpd and such send dynamic updates for
>>>> the zone to.
>>>
>>> But that doesn't mean it should be the server for resolver queries.
>>
>> True, but I don't see much utility from a nameserver which can be dynamically
>> updated but not queried.
>

> Who says you're using dynamic update? The MNAME field has been part of
> the DNS standard since long before DHCP and dynamic update. In many
> instances it's just an FYI field.

Nothing says one is using dynamic updates; if you aren't, then sure, the
MNAME field is quite a bit less important than if you are.

[ ... ]

>> Sure. In which case, why publish an internal-only machine into the public
>> DNS via your SOA record? Someone else made mention of a "stealth master",
>> but my definition of that is an internal machine which is not visible in
>> any publicly published records.
>

> You have to put something in the MNAME. You could lie and put one of the
> public nameservers, but why do that when you could put the true master?

Are you asking why someone would not publish an internal-only hostname?

Maybe it's using RFC-1918 addresses and only reachable on one's LAN?

>>> The performance requirements of a nameserver that serves public queries
>>> are different from a server that only has to respond to zone transfer
>>> requests from the published nameservers.
>>
>> True. Handling AFXRs isn't much work, and you can always revert to other
>> methods of replicating zone data if need be, so my primary concern is making
>> nameservers work well enough to handle the query load, and not to make nameservers
>> just handle zone transfers.
>

> Do that on the public nameservers. The hidden master doesn't need to be
> dedicated to nameserving, since it's not handling all the load that the
> public servers do.

Sure. The thing is, by the time an organization grows big enough to maintain
dedicated internal and external DNS views, and loads their DNS servers to the
point where dedicating a server just to act as master for zone data rather than
handling queries makes sense, well, you also tend to end up with firewalls,
load-balancers, and such which can redirect traffic based on source address,
server load and aliveness, etc.

You publish VIPs which handle your DNS traffic, and then balance that internally
onto your pool of reals (the DNS server boxes) as you choose. Keeping query load
low or moving it entirely off of a particular box is a LB config change. YMMV....

Regards,
--
-Chuck

[Barry Margolin]

In article <mailman.1085.1358384...@lists.isc.org>,

Chuck Swiger <csw...@mac.com> wrote:

> On Jan 16, 2013, at 4:30 PM, Barry Margolin wrote:
> [ ... ]
> >>>> On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
> >>>>> Is there anything technically wrong with having a SOA MNAME field that
> >>>>> isn't listed as a NS record?
> >>>>
> >>>> Sure. The SOA MNAME is expected to be the "primary master" nameserver
> >>>> for
> >>>> the zone; it's where things like dhcpd and such send dynamic updates for
> >>>> the zone to.
> >>>
> >>> But that doesn't mean it should be the server for resolver queries.
> >>
> >> True, but I don't see much utility from a nameserver which can be
> >> dynamically
> >> updated but not queried.
> >
> > Who says you're using dynamic update? The MNAME field has been part of
> > the DNS standard since long before DHCP and dynamic update. In many
> > instances it's just an FYI field.
>
> Nothing says one is using dynamic updates; if you aren't, then sure, the
> MNAME field is quite a bit less important than if you are.

You seemed to be assuming that they are, and that the MNAME field is
important.

>
> [ ... ]
> >> Sure. In which case, why publish an internal-only machine into the public
> >> DNS via your SOA record? Someone else made mention of a "stealth master",
> >> but my definition of that is an internal machine which is not visible in
> >> any publicly published records.
> >
> > You have to put something in the MNAME. You could lie and put one of the
> > public nameservers, but why do that when you could put the true master?
>
> Are you asking why someone would not publish an internal-only hostname?
>
> Maybe it's using RFC-1918 addresses and only reachable on one's LAN?

No, I'm asking why you would put one of the external nameservers in the
MNAME field, even if it's not really the master, just to avoid the
warning that the MNAME isn't one of the NS.

But the rest of your answers seem to be just saying that there's no
point in having a hidden master in the first place.

[Jan-Piet Mens]

> Is there anything technically wrong with having a SOA MNAME field
> that isn't listed as a NS record?

Not at all; that works fine.

> The server listed as MNAME will host the zone and is authoritative
> for the zone, but out of latency concerns it isn't ideal to have
> other resolvers querying this server.

Just omit the server listed as MNAME from the NS RRset.

> Various online DNS diagnostic tools throw warnings, but as far as I
> can tell from the RFCs, this is a valid configuration. Is it valid?

Yes, it is valid. (And most of the online diagnostic tools I know suck:
for example, they complain about SOA serial numbers not being in
YYYYMMDDn format.)

> Are there any operational gotchas to be aware of or can I ignore the
> "warnings"?

You should be aware of DNS Updates which will, by default, be directed
at the server listed in SOA MNAME. If you don't do DHCP, say, then it's
fine to ignore that.

-JP

[Dave Warren]

On 1/16/2013 22:17, Jan-Piet Mens wrote:
>> Is there anything technically wrong with having a SOA MNAME field
>> that isn't listed as a NS record?
> Not at all; that works fine.

Thanks. That's what I thought, but I wanted to confirm that this
particular "warning" didn't have any backing in reality.

>> Are there any operational gotchas to be aware of or can I ignore the
>> "warnings"?
> You should be aware of DNS Updates which will, by default, be directed
> at the server listed in SOA MNAME. If you don't do DHCP, say, then it's
> fine to ignore that.

At this point I don't do any dynamic DNS through BIND at all right now,
the only dynamic zones we currently host are internal-only on Microsoft
DNS and update via AD, so I think we'll be safe in this regard.

Thanks!

[Dave Warren]

On 1/16/2013 13:53, Chuck Swiger wrote:
> True, but I don't see much utility from a nameserver which can be dynamically
> updated but not queried.

It *can* be queried, it's just not ideal as the machine has a fair
amount of load and has fairly high latency. Since I have secondaries in
colocation facilities with available resources, it makes more sense for
them to handle external queries.

I'm also not sure where you're getting dynamic updates from, but we
don't do any dynamic updates through BIND at this time.

> Sure. In which case, why publish an internal-only machine into the public
> DNS via your SOA record?

Because it is actually the master, and from what I can tell, the slaves
will check against the MNAME to confirm whether they're up to date or not.

(Yes, notifies will usually take care of this. Usually.)

> Someone else made mention of a "stealth master",
> but my definition of that is an internal machine which is not visible in
> any publicly published records.

Strictly speaking, it's not internal-only, it's just on a slower,
occasionally overloaded connection which will result in some percentage
of requests taking significantly longer to answer. It's also on a
somewhat overloaded server, so it just makes more sense to push external
traffic to more ideal services.

[Barry Margolin]

In article <mailman.1089.1358406...@lists.isc.org>,

Dave Warren <li...@hireahit.com> wrote:

> Because it is actually the master, and from what I can tell, the slaves
> will check against the MNAME to confirm whether they're up to date or not.

No, slaves check against the IPs listed in the "master" clause in their
named.conf.

[Chris Buxton]

On Jan 16, 2013, at 1:01 PM, Chuck Swiger wrote:

> On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
>> Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record?
>

> Sure. The SOA MNAME is expected to be the "primary master" nameserver for the zone; it's where things like dhcpd and such send dynamic updates for the zone to.

No, not necessarily, not if there's no NS record for it.

RFC 2136 says says that the server "as given by the SOA MNAME field if matched by some NS NSDNAME" should be the preferred target of a dynamic update. That is, if the master server (as indicated by the SOA record) is not listed in an NS record as an authoritative name server, it need not be considered. However, the RFC is a bit vague on how a requestor determines (and orders) the list of authoritative name servers for a zone, and so...

- ISC DHCP sends DDNS updates to the SOA MNAME server if and only if that server is also listed in an NS record. Otherwise, it picks a name from the available NS records and sends the update there. This behavior can be overridden by a zone statement in dhcpd.conf.

- Microsoft clients send DDNS updates to various places, and will typically try multiple targets if the update is denied. I believe the order is the first configured caching resolver, the zone's MNAME field, and then any one of the servers listed in the NS RRSet. I believe the client will try three times, assuming these three cases are all different. (I'm not counting potential retries to the same target to attempt use of GSS-TSIG.)

I believe nsupdate behaves the same as dhcpd, but it's been a while since I last tested this.

Chris Buxton
BlueCat Networks

[Tim Maestas]

nsupdate will use the MNAME regardless of whether it is matched by a
NS record. ISC dhcpd, as you indicated, does not unless overridden
manually via a zone statement.
-Tim

[Barry S. Finkel]

On 1/19/2013 6:00 AM, bind-user...@lists.isc.org wrote:
> On Jan 16, 2013, at 1:01 PM, Chuck Swiger wrote:
>> >On Jan 16, 2013, at 12:40 PM, Dave Warren wrote:
>>> >>Is there anything technically wrong with having a SOA MNAME field that isn't listed as a NS record?
>> >
>> >Sure. The SOA MNAME is expected to be the "primary master" nameserver for the zone; it's where things like dhcpd and such send dynamic updates for the zone to.
> No, not necessarily, not if there's no NS record for it.
>
> RFC 2136 says says that the server "as given by the SOA MNAME field if matched by some NS NSDNAME" should be the preferred target of a dynamic update. That is, if the master server (as indicated by the SOA record) is not listed in an NS record as an authoritative name server, it need not be considered. However, the RFC is a bit vague on how a requestor determines (and orders) the list of authoritative name servers for a zone, and so...
>
> - ISC DHCP sends DDNS updates to the SOA MNAME server if and only if that server is also listed in an NS record. Otherwise, it picks a name from the available NS records and sends the update there. This behavior can be overridden by a zone statement in dhcpd.conf.
>
> - Microsoft clients send DDNS updates to various places, and will typically try multiple targets if the update is denied. I believe the order is the first configured caching resolver, the zone's MNAME field, and then any one of the servers listed in the NS RRSet. I believe the client will try three times, assuming these three cases are all different. (I'm not counting potential retries to the same target to attempt use of GSS-TSIG.)
>
> I believe nsupdate behaves the same as dhcpd, but it's been a while since I last tested this.
>
> Chris Buxton
> BlueCat Networks

The last time I checked (a number of years ago) there was no non-draft
RFC covering the DHCP-DNS interaction. So, when a DHCP server wants
to send a DDNS packet to a DNS server, there is no standard stating
which DNS server should be the recipient of the packet.
--Barry Finkel