[Samba] DNS issues after FSMO seize
L.P.H. van Belle
belle at bazuin.nl
Tue Apr 5 10:01:23 UTC 2016
>> There is no link between SOA and NS except they share the zone....
Really... ? i dont agree..
SOA specifies the DNS server providing authoritative information about a domain, so looks to me its direcly related to NameServers.
SOA contains the primary (NS) server of the domain.
Looks to me its related...
Below it nice explained how DNS works.
That a SOA not (always) related is to a NS records, that i agree.
Greetz,
Louis
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens mathias dufresne
> Verzonden: dinsdag 5 april 2016 11:45
> Aan: Rowland penny
> CC: samba
> Onderwerp: Re: [Samba] DNS issues after FSMO seize
>
> Back from downstairs to take a break. I'll try to moderate my words and
> explain a bit more.
>
> SOA means Start Of Authority. That is true but that means nothing as
> itself.
>
> Parents are start of authority facing their children. My boss is start of
> authority for my job.
>
> NS are authoritative, but once more, as is, that means nothing.
>
> The question is what means "start of authority" and "NS is authoritative"
> in DNS.
>
> In DNS there are two kind of name server: masters and slaves.
> In DNS there are two of records to reference name servers: NS and SOA.
> The point is to make difference between these two records.
> That is simple:
> - NS are name servers you can trust the reply (they are authoritative for
> replying). This record should be used only by name servers, never by
> clients. Clients deal with their resolver which is often a name server, if
> the resolver does not know how to contact a name server for a specified
> zone, the resolver will ask for NS record of that zone, that request will
> be sent to upper level of name server (root servers). Then the resolver
> get
> IP of specified zone name server and can send to that name server the
> client's request, and finally send back the reply to the client. The
> client
> never uses NS records or I missed something.
> - SOA are name servers you can send them DNS updates, they can modify the
> zone. SOA is often declared as "best source of information" but this comes
> from the fact SOA would be the first to receive the update, the source of
> information the most up to date.
>
> There is no link between SOA and NS except they share the zone.
> You can build a DNS zone with 3 name servers, one declared as SOA, two
> declared as NS. I expect you can even configure SOA to refuse replying DNS
> requests which are not updates (with allow-query parameter I would say).
>
> Let say our SOA allow queries. Our SOA is not declared as NS.
> 3 clients (c1, c2, c3), each of them is configured with different
> resolver:
> - c1 uses NS1
> - c2 uses NS2
> - c3 uses SOA
>
> If our three name server allow queries, our three clients are able to
> resolve name from our DNS zone. This happens not because we have NS
> declared, this happens because our name server allow queries and share the
> same zone.
>
> The fact SOA is SOA and not NS does not forbid it to reply, we configured
> it to accept queries which means it cans reply.
>
> Update case (Bind with no DLZ or Samba internal DNS)
> - c1 use nsupdate to update our zone. nsupdate will look for a name server
> of that zone which can modify the zone, as we want to modify the zone and
> we know all name server are not _necessarily_ allowed to do that. So first
> thing, who is SOA. NS1 reply SOA record refers to machine named SOA (yes I
> know the reply is IP and not name, I just try to be understood), c1 send
> update request to SOA rather than NS1.
> - c2, same process except NS2 replies.
> - c3 same again except SOA replies.
>
> Update case (Bind + DLZ or MS AD name server)
> - c1 use nsupdate to update our zone. nsupdate will look for a name server
> of that zone which can modify the zone, as we want to modify the zone and
> we know all name server are not _necessarily_ allowed to do that. So first
> thing, who is SOA.Here NS1 replies "I am SOA", c1 send the request to NS1.
> - c2 same, with NS2
> - c3 same with SOA.
>
>
>
>
>
>
> 2016-04-05 10:33 GMT+02:00 mathias dufresne <infractory at gmail.com>:
>
> >
> >
> > 2016-04-04 14:20 GMT+02:00 Rowland penny <rpenny at samba.org>:
> >
> >> On 04/04/16 10:23, mathias dufresne wrote:
> >>
> >>> SOA means "this DNS se'rver can modify the zone".
> >>>
> >>
> >> No it doesn't, it stands for 'Start Of Authority' and contains who to
> >> contact for the domain records.
> >>
> >
> > Rowland... thank you again Captain Obvious. Yes SOA means Start Of
> > Authority, but I took time explain to clarify things which are clear for
> > everyone.
> > Now why when you want to update DNS you need to find SOA? Because they
> are
> > name server which can write the zone. With bind and no DLZ it's the
> master,
> > with dlz it's all name server you configured to be able to modify the
> zone.
> >
> >
> >>
> >> Using Bind-DLZ all DNS servers can modify the AD zones, they all reply
> "I
> >>> am the SOA" when you ask them about SOA for AD zones.
> >>>
> >>
> >> Sorry, but this, as standard, isn't correct, unless you add the other
> DC
> >> NS records to the SOA, only the first DC is in the SOA.
> >>
> >
> > You don't even tried! You come here to me I'm wrong and you don't even
> > took time to verify! Stop answering em if you don't know what you speak
> > about. Thank you.
> >
> > Here is a test I did for you start to understand better DNS and perhaps
> > stop telling stupid things:
> >
> > This server, dns20, uses as a resolver itself.
> > When asking for NS, there two: dc200 and dc100.
> > When asking SOA there is one: the name server which replied, it replied
> "I
> > am SOA".
> >
> > In AD DB SOA is dc200 which my FSMO.
> >
> > dns20:~# dig ad.dgfip.finances.gouv.fr -t NS
> >
> > ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> ad.dgfip.finances.gouv.fr
> > -t NS
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2556
> > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;ad.dgfip.finances.gouv.fr. IN NS
> >
> > ;; ANSWER SECTION:
> > ad.dgfip.finances.gouv.fr. 900 IN NS
> > dc200.ad.dgfip.finances.gouv.fr.
> > ad.dgfip.finances.gouv.fr. 900 IN NS
> > dc100.ad.dgfip.finances.gouv.fr.
> >
> > ;; Query time: 1 msec
> > ;; SERVER: 10.156.32.99#53(10.156.32.99)
> > ;; WHEN: mar. avril 05 10:16:53 CEST 2016
> > ;; MSG SIZE rcvd: 94
> >
> > dns20:~# dig ad.dgfip.finances.gouv.fr -t SOA
> >
> > ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> ad.dgfip.finances.gouv.fr
> > -t SOA
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58991
> > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;ad.dgfip.finances.gouv.fr. IN SOA
> >
> > ;; ANSWER SECTION:
> > ad.dgfip.finances.gouv.fr. 3600 IN SOA
> > dns20.ad.dgfip.finances.gouv.fr. hostmaster.ad.dgfip.finances.gouv.fr.
> > 462 900 600 86400 3600
> >
> > ;; AUTHORITY SECTION:
> > ad.dgfip.finances.gouv.fr. 900 IN NS
> > dc100.ad.dgfip.finances.gouv.fr.
> > ad.dgfip.finances.gouv.fr. 900 IN NS
> > dc200.ad.dgfip.finances.gouv.fr.
> >
> > ;; Query time: 1 msec
> > ;; SERVER: 10.156.32.99#53(10.156.32.99)
> > ;; WHEN: mar. avril 05 10:16:58 CEST 2016
> > ;; MSG SIZE rcvd: 147
> >
> > Same test on dc102, I don't search again for NS as the reply don't
> change.
> > It changes only for SOA.
> >
> > dc102:~# dig -t SOA ad.dgfip.finances.gouv.fr
> >
> > ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> -t SOA
> > ad.dgfip.finances.gouv.fr
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21947
> > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;ad.dgfip.finances.gouv.fr. IN SOA
> >
> > ;; ANSWER SECTION:
> > ad.dgfip.finances.gouv.fr. 3600 IN SOA
> > dc102.ad.dgfip.finances.gouv.fr. hostmaster.ad.dgfip.finances.gouv.fr.
> > 462 900 600 86400 3600
> >
> > ;; AUTHORITY SECTION:
> > ad.dgfip.finances.gouv.fr. 900 IN NS
> > dc100.ad.dgfip.finances.gouv.fr.
> > ad.dgfip.finances.gouv.fr. 900 IN NS
> > dc200.ad.dgfip.finances.gouv.fr.
> >
> > ;; Query time: 1 msec
> > ;; SERVER: 10.154.102.166#53(10.154.102.166)
> > ;; WHEN: mar. avril 05 10:22:23 CEST 2016
> > ;; MSG SIZE rcvd: 147
> >
> >
> >
> >
> >>
> >> Using Internal DNS I expect all DNS servers can modify the AD zones
> also
> >>> (that's internal stuff) but even if they can modify the AD zone
> locally
> >>> that's is not the process chosen by Samba Team. Samba Internal DNS
> relies
> >>> on DB content to reply to SOA query and there is only one SOA in the
> DB.
> >>> So with internal DNS you will have always only one SOA.
> >>>
> >>
> >> As standard this is true, but you can add the DC records to the SOA
> >> record in AD and then Bind dlz will show each DC as being the owner of
> the
> >> SOA, but as you say, the internal DNS doesn't.
> >>
> >
> > Yes internal does not follow standard.
> >
> >
> >>
> >>
> >>> This is an issue because if your SOA is down and some DC has DNS
> updates
> >>> to
> >>> send, updates will fail because no SOA available.
> >>> And when seizing roles because you are about to remove old FSMO,
> that's
> >>> the
> >>> same: once the FSMO is removed no more SOA to apply DNS updates on.
> >>>
> >>
> >> The problem isn't if you remove a DC, it is that, as standard, there is
> >> only one NS in the SOA.
> >>
> >
> > Missed. SOA as nothing to do with NS. I could write again the
> difference,
> > but you don't trust me. If I don't say same as you, I'm wrong (until I
> show
> > the contrary).
> >
> > As internal does not follow standard, it must move SOA at some moments
> > (hard to define all because conditional behaviour).
> >
> >
> >>
> >>
> >>> For me, I can be wrong, this behaviour comes from the fact Samba uses
> >>> "nsupdate" command to push DNS updates. nsupdate comes from Bind tools
> >>> suite, as it is bind tool it follows the protocol. And the protocol
> says
> >>> "updates can be pushed only on SOA". So nsupdate first ask the zone to
> be
> >>> modified what is the SOA to push updates on that server.
> >>>
> >>
> >> I don't think the problem is with 'nsupdate', I think it is with the
> way
> >> the internal DNS uses the SOA.
> >>
> >
> > You who don't seem to test much, do you run a tcpdump when using
> nsupdate
> > -g /path/to/file.generated_by_samba_dnsupdate?
> > If you did that you would have seen the first action of nsupdate is to
> > find the SOA (because SOA is or are the place(s) to push changes).
> >
> >
> >>
> >>
> >>> IMHO this should be managed by Samba itself rather than relying on
> Samba
> >>> admins DNS knowledge.
> >>> Samba Internal DNS should be able to push update locally and Samba
> >>> internal
> >>> DNS should answer "I am SOA" as they can push DNS updates locally
> (they
> >>> have access to the DB, they can push updates, even if this needs to
> write
> >>> some code).
> >>>
> >>
> >> Totally agree with you, do you want to write this code ?
> >>
> >
> > No.
> >
> >
> >>
> >> Or samba_dnsupdate should not use by default nsupdate from bind tools
> when
> >>> using internal DNS but rather use "samba-tool dns ..." which pushes
> >>> updates
> >>> locally.
> >>>
> >>
> >> Do you mean like archlinux did with dhcp ?
> >>
> >
> > dhcp on archlinux has some dependancy on samba4 in AD mode? I didn't
> > noticed that... Because for dhcp start to use samba_dnsupdate or samba-
> tool
> > there is certainly some work to do in dhcp code...
> >
> > I'm joking but seriously, I don't see any relation between arch, dhcp
> and
> > samba tools, so I don't see the point of that question.
> >
> >
> >>
> >> And before you start thinking I am trying to put you down, I am not, I
> am
> >> just pointing out what *I* see as mistakes. If you have any problems
> with
> >> what I write, provide proof of where I am wrong and I will apologise.
> >>
> >
> > I think I did. For both: being pissed of in the morning and giving you
> > explanations.
> >
> >
> >>
> >> Rowland
> >>
> >>
> >>>
> >>>
> >>> 2016-04-01 19:26 GMT+02:00 lingpanda101 at gmail.com <
> >>> lingpanda101 at gmail.com>:
> >>>
> >>> On 3/31/2016 3:12 PM, IT Admin wrote:
> >>>>
> >>>> Aaaaaaand more problems... Welcome to the continuing saga of FILER.
> >>>>>
> >>>>> It appears that neither SOA or NS records were updated during the
> >>>>> process
> >>>>> of moving fsmo roles to CBADC01. SOA entries on all three active
> DCs
> >>>>> point
> >>>>> to FILER. There aren't any NS records for any of the new DCs, only
> >>>>> FILER.
> >>>>> In RSAT each DNS server's properties show filer.cb.cliffbells.com
> is
> >>>>> the
> >>>>> primary server. This looks at awful lot like this to me:
> >>>>> https://lists.samba.org/archive/samba/2015-October/195352.html
> >>>>>
> >>>>> This process is killing me.
> >>>>>
> >>>>> I assume this misconfiguration is in large part responsible for
> >>>>> authentication and share access issues I'm now experiencing (I sent
> a
> >>>>> reply
> >>>>> to my last thread on failing to join DCs to the domain but received
> no
> >>>>> replies). I'm of the opinion mentioning this potential failure
> along
> >>>>> with
> >>>>> the procedure to mitigate the issue would be useful on the wiki page
> >>>>> detailing transfer/seize fsmo roles... If I read things right if
> the
> >>>>> original fsmo role holder has been demoted prior to identifying the
> >>>>> failure
> >>>>> samba-tool won't be able to query the original DC and manual
> >>>>> intervention
> >>>>> will be required?
> >>>>>
> >>>>> Please advise. This client is about ready to throw me off the roof
> and
> >>>>> abandon the system for quill and ink by candle light. I'm
> considering
> >>>>> just
> >>>>> going with it.
> >>>>>
> >>>>> JS
> >>>>>
> >>>>> I should mention the syntax to update the SOA if you do not know. I
> did
> >>>> this back in the Samba 4.0 days. Not sure if things have changed.
> >>>>
> >>>> samba-tool dns update SOA "fqdn_dns fqdn_email serial refresh retry
> >>>> expire
> >>>> minimumttl"
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> -James
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> To unsubscribe from this list go to the following URL and read the
> >>>> instructions: https://lists.samba.org/mailman/options/samba
> >>>>
> >>>>
> >>
> >> --
> >> To unsubscribe from this list go to the following URL and read the
> >> instructions: https://lists.samba.org/mailman/options/samba
> >>
> >
> >
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
More information about the samba
mailing list