"Unrelated Additional Info" from Windows 2000 Active Director y servers

Mark_Andrews at isc.org Mark_Andrews at isc.org
Fri Oct 5 01:23:19 UTC 2001


> In article <9pilbl$rff at pub3.rc.vix.com>, O'Neil,Kevin <oneil at oclc.org> wrote:
> >Here's the dig:
> >
> >net-thing 37 /tftpboot: dig soa metka-t.oa.oclc.org
> >
> >; <<>> DiG 8.3 <<>> soa metka-t.oa.oclc.org 
> >;; res options: init recurs defnam dnsrch
> >;; got answer:
> >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
> >;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> >;; QUERY SECTION:
> >;;      metka-t.oa.oclc.org, type = SOA, class = IN
> >
> >;; AUTHORITY SECTION:
> >oa.oclc.org.            1H IN SOA       oa1-server.oa.oclc.org.
> >administrator.oa.oclc.org. (
> >                                        47625           ; serial
> >                                        15M             ; refresh
> >                                        10M             ; retry
> >                                        1D              ; expiry
> >                                        15M )           ; minimum
> >
> >
> >;; ADDITIONAL SECTION:
> >oa1-server.oa.oclc.org.  1H IN A  132.174.29.60
> >
> >;; Total query time: 7 msec
> >;; FROM: net-thing to SERVER: default -- 132.174.47.100
> >;; WHEN: Thu Oct  4 16:00:46 2001
> >;; MSG SIZE  sent: 37  rcvd: 114
> 
> What BIND is warning about is that there's no requirement to include the A
> record for the SOA MNAME in the Additional Records section.  I suspect that
> Microsoft DNS does it for the benefit of dynamic update clients; since
> updates should be sent to the master server, they would need to do that A
> query right after the SOA query (this is the same reason that related A
> records are returned in MX or NS queries).

	Updates should be sent to the nameservers listed in the NS RRset.
	If the MNAME matches one of the listed nameservers it should be
	tried first.  The reason for this is to allow update to work
	through firewalls to stealth masters.

	The slaves forward the update (via the zone transfer graph),
	potentially changing only the id, and the response is sent back
	correcting the id if required.  TSIG does NOT cover id specifically
	to allow this to work.

	Before you tell us about nsupdate in bind 9 being broken, we know.

> 
> >I don't think that it's something to be concerned with.  And there doesn't
> >seem to be anything to be done about it.
> 
> I suspect the reason for the warning is that inappropriate additional info
> can be a source of cache poisoning.  I presume that the warning implies
> that the unrelated records are being ignored, so the server complaining is
> safe.
> 
> -- 
> Barry Margolin, barmar at genuity.net
> Genuity, Woburn, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the grou
> p.
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org


More information about the bind-users mailing list