9.2.3 EDNS0 incompatibility

Tue Sep 14 22:54:56 UTC 2004

> Thank you for your reply. Doesn't this change necessitate additional 
> network traffic?

	No it doesn't.  The address of the server needs to be looked
	up but that also happens when nsupdate is making SOA queries
	to discover the zone name and master server.  In fact is
	you specify both the zone and the server you usually end
	up with less traffic.  If you use a IP address for the
	server the only network traffic is the UPDATE itself.

> Why wouldn't the forwarder (9.2.3) return the record 
> as sent from the authority, is there some standards reason that 
> outweighs the reduced interoperability and network load?

	Yes there is a second bug but all that does is make named
	behave like a non RFC 2308 aware server when it receives a
	RFC 2308 Type 1 (SOA + NS) response.  The actual answer
	named returns is a legal Type 3 (no SOA or NS records)
	response.  When the bug is fixed it will be a legal Type 2
	(SOA only) response.

	nsupdate should have coped with any of the RFC 2308 responses
	however it was wanting a Type 1 or Type 2 response.  It was
	a overcite when nsupdate was re-implemented for BIND 9.
	
	So, while not optimal, named behaviour is not broken.
	nsupdate's behaviour on the other hand was broken as it
	failed to cope with a legal reply.

	Mark

> Regards,
> 
> Chris
>
> On Sep 12, 2004, at 3:13 PM, Mark Andrews wrote:
> 
> >
> > 	It's a bug in nsupdate.  It should cope with this sort of
> > 	NXDOMAIN.  Use server and zone commands to workaround the
> > 	problem.
> >
> > 	server pm-members.mac.com.
> > 	zone csharp.members.mac.com.
> > 	<rest of update commands>
> >
> >> Your response indicates that I could have done a better job at
> >> articulating the problem. Here is what I think the 
> >> client-server-server
> >> communication looks like:
> >> client query SOA ? ---> 9.2.3 Server query SOA + OPT RR ---> Authority
> >> for members.mac.com
> >> Authority for members.mac.com responds FormErr ---> 9.2.3
> >> 9.2.3 Server query SOA ? ---> Authority for members.mac.com
> >> Authority for members.mac.com responds with NXDOMAIN (see dig below).
> >>
> >> When the 9.2.3 server receives the answer to the second SOA query 
> >> which
> >> does not include the OPT RR it most certainly does contain an SOA in
> >> the authority statement. Functionally, it would be equivalent to:
> >> dig -t soa computer.csharp.members.mac.com. @17.250.248.161
> >>
> >> ; <<>> DiG 9.2.2 <<>> -t soa computer.csharp.members.mac.com.
> >> @17.250.248.161
> >> ;; global options:  printcmd
> >> ;; Got answer:
> >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46632
> >> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
> >>
> >> ;; QUESTION SECTION:
> >> ;computer.csharp.members.mac.com. IN    SOA
> >>
> >> ;; AUTHORITY SECTION:
> >> csharp.members.mac.com. 3600    IN      SOA     pm-members.mac.com.
> >> postmaster.mac.com. 1507 10800 3600 604800 10
> >> csharp.members.mac.com. 3600    IN      NS      pm-members.mac.com.
> >>
> >> ;; ADDITIONAL SECTION:
> >> pm-members.mac.com.     3600    IN      A       17.250.248.161
> >>
> >> ;; Query time: 133 msec
> >> ;; SERVER: 17.250.248.161#53(17.250.248.161)
> >> ;; WHEN: Sun Sep 12 10:22:27 2004
> >> ;; MSG SIZE  rcvd: 137
> >>
> >> The dig command you reference below is received from the 9.2.3
> >> "forwarder" and does not contain the SOA and hence the problem. Let me
> >> restate the question (carefully stated in the initial posting), is it
> >> possible that the first Formerr response is being cached and
> >> causing the empty SOA response to the client?
> >>
> >> Regards,
> >>
> >> Chris
> >>
> >> On Sep 11, 2004, at 8:43 AM, Jonathan de Boyne Pollard wrote:
> >>
> >>> CS> $ dig -t soa computer.csharp.members.mac.com.
> >>> CS> [...]
> >>> CS> The 9.2.3 server then re-issues the query without the OPT RR and
> >>> CS> gets an NXDOMAIN with the SOA record in the authority section.
> >>>
> >>> No, it doesn't.  Read the output _carefully_.
> >>>
> >> Hello,
> >> Since upgrading from 9.2.1 we are seeing some strange behavior on our
> >> 9.2.3 server. When I issue:
> >>
> >> csharp6:~/bin csharpl$ dig -t soa computer.csharp.members.mac.com.
> >>
> >> ; <<>> DiG 9.2.2 <<>> -t soa computer.csharp.members.mac.com.
> >> ;; global options:  printcmd
> >> ;; Got answer:
> >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23436
> >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> >>
> >> ;; QUESTION SECTION:
> >> ;computer.csharp.members.mac.com. IN    SOA
> >>
> >> ;; Query time: 33 msec
> >> ;; SERVER: 17.128.100.12#53(17.128.100.12)
> >> ;; WHEN: Fri Sep 10 13:58:12 2004
> >> ;; MSG SIZE  rcvd: 49
> >>
> >> the 9.2.3 server responds this way. This causes nsupdate to fail
> >> "response to SOA query didn't contain an SOA". Note, the 17.128.100.12
> >> address is internal and forwards to 17.254.0.35 (9.2.3 server).
> >>
> >> We turned logging all the way up to 99 on the 9.2.3 server and did not
> >> see anything out of the ordinary - or at least to my eyes.
> >>
> >> A network trace comparing the new server with the old shows that the
> >> new server is issuing the SOA lookup with an OPT resource record:
> >> SOA? computer.csharp.members.mac.com. ar: . OPT UDPsize=2048 (60)
> >>
> >> where the old server:
> >> SOA? computer.csharp.members.mac.com. (49)
> >>
> >> The custom dynamic DNS server responding (17.250.248.161) to the first
> >> query responds with a FormErr. The 9.2.3 server then re-issues the
> >> query without the OPT RR and gets an NXDOMAIN with the SOA record in
> >> the authority section.
> >>
> >> Is it possible that the first Formerr response is being cached and
> >> causing the empty SOA response to the client?
> >>
> >> Regards,
> >>
> >> Chris Sharp
> >>
> >> -- Binary/unsupported file stripped by Ecartis --
> >> -- Type: application/pkcs7-signature
> >> -- File: smime.p7s
> >>
> >>
> >>
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
> >
> 
> --Apple-Mail-5-907297766
> Content-Transfer-Encoding: base64
> Content-Type: application/pkcs7-signature;
> 	name=smime.p7s
> Content-Disposition: attachment;
> 	filename=smime.p7s
> 
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGMTCCAuow
> ggJToAMCAQICAwwZ7zANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
> d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
> YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDA5MjEwNDI0WhcNMDUwNDA5MjEwNDI0WjBhMQ4wDAYDVQQE
> EwVTaGFycDEUMBIGA1UEKhMLQ2hyaXN0b3BoZXIxGjAYBgNVBAMTEUNocmlzdG9waGVyIFNoYXJw
> MR0wGwYJKoZIhvcNAQkBFg5jc2hhcnBAbWFjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
> AQoCggEBALG4Glfoi4i+4sS1lHJMgVpfColJ45pDn84LClJTbdskQt6HdnAVRSL3J2M/VNlJAJoW
> NJCu89D0QxLpcDGFQLFQ0Z1TKorUZk7wPz8wbTAH0/HVugl9HCRkrt+vEjhIk2BSbtUe5Hon78L5
> 1F22IdvHGADdv56oYlNksLd5G4LbKfEC+a/ihoy9FzoHi+HYmLQDsKP/347gi4QhDKM1iFpahhMv
> F01zuKPxxltbVc6879FvvKUlDzH9wMzVZY/4EN93wA0V+boRPR2LUxXQTZ1iCOcI+FVMPwB7qaJP
> 38RvET52VyZX+3pTFdv5hsE/JKySsK4pUHLG3jGLjbqy6DsCAwEAAaMrMCkwGQYDVR0RBBIwEIEO
> Y3NoYXJwQG1hYy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBT5kRkILuB6+IR
> BXTDddGm7Qf4sZg5ELzx/5irHCcOTYIBIHjhFZWIyaJy2HJcTzhd8LLha+bazWKB5FaAJ9G1r2Ak
> BEENuBS6lMFGTOBq9HC3HLcVAAwZxCxlT8rBa0rdi4TpuT6rskdtbdylKlDZTXjX1rtYU7DYQYu5
> SF84vTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYD
> VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
> bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV
> BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt
> ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJ
> BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
> EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOB
> jQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDX
> AmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l
> 0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG
> A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVt
> YWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
> YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4
> +DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l
> X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIx
> CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
> VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDBnvMAkGBSsOAwIaBQCg
> ggFTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDkxNDE2MTY1
> NVowIwYJKoZIhvcNAQkEMRYEFP/F4wng6hDToQNI9DszZPzzNnudMHgGCSsGAQQBgjcQBDFrMGkw
> YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
> BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMGe8wegYLKoZIhvcN
> AQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
> KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDBnv
> MA0GCSqGSIb3DQEBAQUABIIBAE4VAkF0dauwY8WJzixp+6niuA6ysWF7hBRRIN1+VMfGZ+l2EJJ/
> BUGpLViL5YL//2FTO9LiNkMMnhnBbUot7dT9nC7npiZObbDW31ggtG5R16myBKPiJ1hKFFP+H/aM
> +Joirwt+MOBY2ywT1ygI2KMSQpDYMk0iX+Oo2/qeDBs3JFY9izYYY4KRkXiQ47ZzbCyT77Gied/U
> F6yF4CPvqKPCZI0kVgV7VVrzo5Y/Gotwf9tq3FfQ/wbAj+nsawJaub2oRL29LnG9sIdt2kQgBk+e
> +Qb9XuwQJplvl6IKqi+mRQ9G2Gq4t5jW2qADIofmDv748SxNK6SIewVkQAo/eqsAAAAAAAA=
> 
> --Apple-Mail-5-907297766--
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org