Bug 10153 - Samba is not sending it's SOA record on a request for a domain where it is authorative
Samba is not sending it's SOA record on a request for a domain where it is au...
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: DNS server
unspecified
All All
: P5 minor
: ---
Assigned To: Kai Blin
Samba QA Contact
:
: 10155 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-19 06:18 UTC by Matthieu Patou
Modified: 2015-12-23 23:07 UTC (History)
3 users (show)

See Also:


Attachments
Proposed patch adding an authority record to error replies (7.91 KB, patch)
2015-07-17 13:20 UTC, Kai Blin
no flags Details
Patch to add authority record to authorative replies (13.50 KB, patch)
2015-08-06 13:17 UTC, Kai Blin
kai: review? (asn)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthieu Patou 2013-09-19 06:18:41 UTC
With Internal DNS server, if the server is authoritative for domain.tld, then other implementation (bind, MS, ...) are returning a SOA when a non existing name is queried (ie. nonexist.domain.tld)

See packet 9 for windows behavior and packet 255 for samba behavior
Comment 1 Kai Blin 2013-09-19 06:48:24 UTC
*** Bug 10155 has been marked as a duplicate of this bug. ***
Comment 2 Kai Blin 2013-09-19 06:50:25 UTC
While not strictly required by the RFC, this seems to break some clients.
Comment 3 Kai Blin 2014-10-13 11:12:31 UTC
Working on this at the moment
Comment 4 Remsnet LTD Support 2014-12-27 15:35:44 UTC
From my samba4 dlz setup :


root@gate1:/etc/named/slave# cat db.sample.dom
$ORIGIN .
$TTL 3600       ; 1 hour
SAMPLE.DOM  IN SOA  ad2.sample.dom. hostmaster.sample.dom. (
                                50         ; serial
                                900        ; refresh (15 minutes)
                                600        ; retry (10 minutes)
                                86400      ; expire (1 day)
                                3600       ; minimum (1 hour)
                                )

			$TTL 900        ; 15 minutes
                        NS      ad2.sample.dom.


But that shuold be to be authorative :

root@gate1:/etc/named/slave# 

$TTL 3600       ; 1 hour
@   IN SOA  ad2.sample.dom. hostmaster.sample.dom. (
                                50         ; serial
                                900        ; refresh (15 minutes)
                                600        ; retry (10 minutes)
                                86400      ; expire (1 day)
                                3600       ; minimum (1 hour)
                                )


@                      IN  NS      ad2.sample.dom.


1- the @ makes it authorative
2-  the IN NS are required 
    This are descripred in older DNS RFC under compatibly  and some dns howtows - and on ISC Bind´s mailing lists
3-  the dots behind the domain name required.

It´s just and way of Format the SOA header correctly.

This explains it :

-  http://daemonforums.org/showthread.php?t=4073
- https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-an-authoritative-only-dns-server-on-ubuntu-

---------------------------------


Second bug uppon this at least for samba dlz:

For samba-tool dns   the ".in-addr.arpa." are not the same as ".in-addr.arpa" 
This is an Kind of DNS reggression ... that Bind , and others take care of.
Comment 5 Kai Blin 2015-07-17 13:20:51 UTC
Created attachment 11270 [details]
Proposed patch adding an authority record to error replies

I think in the end we should be adding the authority record to all the replies we're authoritative for.
Comment 6 Kai Blin 2015-08-06 13:13:56 UTC
Changed the title to be more generic, as we should always be adding our SOA record to replies we're authorative for. This is not required as per RFC, but it's what both BIND and MS DNS do.
Comment 7 Kai Blin 2015-08-06 13:17:52 UTC
Created attachment 11315 [details]
Patch to add authority record to authorative replies

Patch from master that makes nsupdate happy.
Comment 8 Björn Jacke 2015-12-06 22:23:16 UTC
kai: looks like this bug should be closed fixed then?
Comment 9 Kai Blin 2015-12-23 23:07:02 UTC
Yes, unless someone wants to keep this to backport to one of the released branches.