[Opendnssec-user] ods2 AXFR request to nameserver fails , reports "bad packet: ... received error code NOTAUTH", but no traffic (tcpdump) seen ?

[Berry A.W. van Halderen]

On 12/27/2016 01:52 AM, PGNet Dev wrote:
> I'm losing track of all my own attempts :-/  So a quick summary:
> since ODS2 is on the same box, it should be communicating for axfr only on localhost.  it is, with config
> 
> 	cat conf.xml
> 		...
> 		<Signer>
> 		        <Listener>
> 		    <Interface>
> 		        <Address>127.0.0.1</Address>
> 		        <Port>15354</Port>
> 		    </Interface>
> 		    <Interface>
> 		        <Address>10.1.1.53</Address>
> 		        <Port>15354</Port>
> 		    </Interface>
> 		        </Listener>
> 		<Privileges>
> 		...
> 
> and
> 
> 	cat addns.xml
> 		<?xml version="1.0" encoding="UTF-8"?>
> 		<Adapter>
> 			<DNS>
> 				<TSIG>
> 					<Name>ods-key</Name>
> 					<Algorithm>hmac-sha256</Algorithm>
> 					<Secret>xxx...xxx</Secret>
> 				</TSIG>
> 
> 				<Inbound>
> 					<RequestTransfer>
> 						<Remote>
> 							<Address>127.0.0.1</Address>
> 							<Port>53</Port>
> 							<Key>ods-key</Key>
> 						</Remote>
> 					</RequestTransfer>
> 
> 					<AllowNotify>
> 						<Peer>
> 							<Prefix>127.0.0.1</Prefix>
> 							<Key>ods-key</Key>
> 						</Peer>
> 					</AllowNotify>
> 				</Inbound>
> 			...
> 			</DNS>
> 		</Adapter>
> 		...
> notify mail, containing the new key, is sent/received correctly via a "<DelegationSignerSubmitCommand>" script, and we're done.
> 
> But, if --out-type == DNS, with add'l config
> 
> 	cat addns.xml
> 		<Adapter>
> 			<DNS>
> 			...
> 				<Outbound>
> 					<ProvideTransfer>
> 						<Peer>
> 							<Prefix>10.2.2.53</Prefix>
> 							<Key>ods-key</Key>
> 						</Peer>
> 					</ProvideTransfer>
> 					<Notify>
> 						<Remote>
> 							<Address>10.2.2.53</Address>
> 							<Port>53</Port>
> 						</Remote>
> 					</Notify>
> 				</Outbound>
> 			</DNS>
> 		</Adapter>
> 
> signing fails
> 
> 	tail -f opendnssec.log
> 		...
> 		Dec 26 16:32:26 dns ods-signerd: [notify] unable to send data over udp to 10.2.2.53: sendto() failed (Invalid argument)
> 		Dec 26 16:32:26 dns ods-signerd: [notify] unable to send notify retry 1 for zone example.com to 10.2.2.53: notify_send_udp() failed
> 
> which leads to this bug report
> 
> 	"error logging for failed ods-signer remote NOTIFY reports only "sendto() failed (Invalid argument)", no additional detail"
> 		https://issues.opendnssec.org/browse/SUPPORT-206
> 
> I think 1st order of biz is to fix the "Invalid argument" as in the bug, and find out what the sendto() error *is* ...
> _______________________________________________

Well, the error is in fact an "Invalid argument".  It is really all the
information available.  The sendto() call failed because one of the
arguments is invalid.  The destination address is printed (10.2.2.53)
and it earlier also indicated it wanted to send 132 bytes.  It is not
considered healthy to print the data that it wants to send, and that
doesn't help either anyway.  All arguments *look* valid, it is just
that the operating system cannot do.

It took some digging, but puzzling the pieces from your items together I
think this is the case.  You want to send a notify to 10.2.2.53,
but that will be send over the first (OpenDNSSEC can only assume/try
something) interface available to it.  You specified two interfaces,
unfortunately the first is local-only, while you want to send something
to another box.

  <Signer>
    <Listener>
      <Interface>
        <Address>127.0.0.1</Address><Port>15354</Port>
      </Interface>
      <Interface>
        <Address>10.1.1.53</Address><Port>15354</Port>
      </Interface>
     ...
So the NOTIFY gets as source address 127.0.0.1 while is being
sent to 10.2.2.53.  That is an "invalid argument" to the operating
system.  If you reverse the two interfaces probably things start
working.

You might wander why we bind to an interface at all, well, there are
bugs where some OSes do not use the right interface.  Also there could
be multiple addresses valid.  We either need to know magically which
one to take or start probing, which isn't very friendly either.
Also it is often the case that explicit security is used to require
NOTIFies to be sent using an explicit source address.  So it is
better to bind in these cases.

I'm afraid it is just one of those things that can go wrong in an
extended set-up.

\Berry