Bug 584 - ldns-update tries to look up DDNS server from itself
ldns-update tries to look up DDNS server from itself
Status: RESOLVED FIXED
Product: ldns
Classification: Unclassified
Component: drill/tools
1.6.x
i386 FreeBSD
: P5 normal
Assigned To: LDNS dev team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-27 02:38 CEST by Nicholas Riley
Modified: 2014-12-07 20:05 CET (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicholas Riley 2014-05-27 02:38:08 CEST
The server I'm trying to use ldns-update with is not authoritative for its own domain, nor is it a public caching server.  However, ldns-update attempts to look up its address and gives up when it refuses to answer.

% ldns-update marcia.dyn.sabi.net […] dyn.sabi.net hmac-md5 '[…]'
;; trying UPDATE with FQDN "marcia.dyn.sabi.net" and IP "[…]"
;; tsig: "dyn.sabi.net" "hmac-md5.sig-alg.reg.int." "[…]"
% echo $?
11

% host -t soa dyn.sabi.net
dyn.sabi.net has SOA record osric.zoiks.net. hostmaster.zoiks.net. 2012041738 10800 3600 604800 60
% host -t ns dyn.sabi.net
dyn.sabi.net name server osric.zoiks.net.

On the server, I see:

May 27 00:32:04 osric named[2958]: client […]#10998: query (cache) 'osric.zoiks.net/AAAA/IN' denied
May 27 00:32:04 osric named[2958]: client […]#53699: query (cache) 'osric.zoiks.net/A/IN' denied

This seems strange because it's already resolved osric.zoiks.net to be able to contact it.  None of the other (3) RFC 2136 clients I've tried on various platforms do this.  Is this intentional?
Comment 1 Willem Toorop 2014-05-27 10:39:40 CEST
Hmmm... could you try to specify the zone explicitly? So

% ldns-update marcia.dyn.sabi.net dyn.sabi.net <ip> dyn.sabi.net hmac-md5 '<hmac>'

In noticed the optional zone is not mentioned in the man page, but it is in the "-h" help text.  That has to be fixed anyway...
Comment 2 Willem Toorop 2014-05-27 11:30:38 CEST
For my own record...

ldns_update_soa_zone_mname(const char *fqdn, ldns_resolver *r,
    ldns_rr_class c, ldns_rdf **zone_rdf, ldns_rdf **mname_rdf)

is called when no zone is specified to ldns-update to discover the zone and mname.

First it uses r to query for fqdn SOA.
It then looks up IP for mname (ipv4 only!) and modifies r to target mname.
It then uses r to (targeting mname's ipv4 address) to query for fqdn SOA.
It sets the zone_rdf and mname_rdf from the SOA found in the authority...
... and leaves r to target mname's ipv4 address directly!

Later in the ldns-update program itself, it reuses r to query for zone NS
   ... ( so in our case it targets osric.zoiks.net. to lookup dyn.sabi.net NS
         This will correctly return osric.zoiks.net. ) ...

Then it walks through the answer section with NS RRs, to add them to the nameserver list of another resolver that will later be used to perform the update.  Unfortunately it looks up the address of the NS with ldns_get_rr_list_addr_by_name() using the resolver modified in ldns_update_soa_zone_mname().

To fix, make sure ldns_resolver r is in its old state when returning from ldns_update_soa_zone_mname().
Comment 3 Nicholas Riley 2014-05-27 15:19:38 CEST
(In reply to comment #1)
> Hmmm... could you try to specify the zone explicitly? So
> 
> % ldns-update marcia.dyn.sabi.net dyn.sabi.net <ip> dyn.sabi.net hmac-md5
> '<hmac>'
> 
> In noticed the optional zone is not mentioned in the man page, but it is in
> the "-h" help text.  That has to be fixed anyway...

Thanks for the response!  You guessed it — I only looked in the man page for this.

When I specify the zone explicitly, the update hangs for ~15 seconds then fails.

With tcpdump I see no attempt to contact osric.zoiks.net (if it isn't obvious, plucky.cmi.sabi.net is the local DNS).

07:37:18.511722 IP (tos 0x0, ttl 64, id 3110, offset 0, flags [none], proto UDP (17), length 58, bad cksum 0 (->c76)!)
    marcia.cmi.sabi.net.26531 > plucky.cmi.sabi.net.domain: 14262+ SOA? dyn.sabi.net. (30)
07:37:18.577596 IP (tos 0x0, ttl 64, id 11895, offset 0, flags [none], proto UDP (17), length 117)
    plucky.cmi.sabi.net.domain > marcia.cmi.sabi.net.26531: 14262 1/0/0 dyn.sabi.net. SOA osric.zoiks.net. hostmaster.zoiks.net. 2012041738 10800 3600 604800 60 (89)
07:37:18.578916 IP (tos 0x0, ttl 64, id 3111, offset 0, flags [none], proto UDP (17), length 58, bad cksum 0 (->c75)!)
    marcia.cmi.sabi.net.27159 > plucky.cmi.sabi.net.domain: 13367+ NS? dyn.sabi.net. (30)
07:37:18.610573 IP (tos 0x0, ttl 64, id 11897, offset 0, flags [none], proto UDP (17), length 84)
    plucky.cmi.sabi.net.domain > marcia.cmi.sabi.net.27159: 13367 1/0/0 dyn.sabi.net. NS osric.zoiks.net. (56)
07:37:18.612368 IP (tos 0x0, ttl 64, id 3112, offset 0, flags [none], proto UDP (17), length 61, bad cksum 0 (->c71)!)
    marcia.cmi.sabi.net.51359 > plucky.cmi.sabi.net.domain: 31312+ AAAA? osric.zoiks.net. (33)
07:37:18.642172 IP (tos 0x0, ttl 64, id 11899, offset 0, flags [none], proto UDP (17), length 89)
    plucky.cmi.sabi.net.domain > marcia.cmi.sabi.net.51359: 31312 1/0/0 osric.zoiks.net. AAAA 2600:3c03::f03c:91ff:fe96:f166 (61)
07:37:18.643284 IP (tos 0x0, ttl 64, id 3113, offset 0, flags [none], proto UDP (17), length 61, bad cksum 0 (->c70)!)
    marcia.cmi.sabi.net.42224 > plucky.cmi.sabi.net.domain: 21709+ A? osric.zoiks.net. (33)
07:37:18.674471 IP (tos 0x0, ttl 64, id 11901, offset 0, flags [none], proto UDP (17), length 77)
    plucky.cmi.sabi.net.domain > marcia.cmi.sabi.net.42224: 21709 1/0/0 osric.zoiks.net. A 69.164.214.145 (49)
07:37:19.032883 IP (tos 0x0, ttl 64, id 3115, offset 0, flags [none], proto UDP (17), length 74, bad cksum 0 (->c61)!)
    marcia.cmi.sabi.net.60000 > plucky.cmi.sabi.net.domain: 62792+ PTR? 196.240.168.192.in-addr.arpa. (46)
07:37:19.034793 IP (tos 0x0, ttl 64, id 11902, offset 0, flags [none], proto UDP (17), length 107)
    plucky.cmi.sabi.net.domain > marcia.cmi.sabi.net.60000: 62792* 1/0/0 196.240.168.192.in-addr.arpa. PTR marcia.cmi.sabi.net. (79)
07:37:19.035782 IP (tos 0x0, ttl 64, id 3116, offset 0, flags [none], proto UDP (17), length 72, bad cksum 0 (->c62)!)
    marcia.cmi.sabi.net.63429 > plucky.cmi.sabi.net.domain: 62793+ PTR? 1.240.168.192.in-addr.arpa. (44)
07:37:19.037546 IP (tos 0x0, ttl 64, id 11903, offset 0, flags [none], proto UDP (17), length 105)
    plucky.cmi.sabi.net.domain > marcia.cmi.sabi.net.63429: 62793* 1/0/0 1.240.168.192.in-addr.arpa. PTR plucky.cmi.sabi.net. (77)

I tried disabling IPv6 in case I wasn't capturing something, but that didn't help.  BIND's nsupdate works fine, but the whole point of using ldns-update was to avoid installing BIND...

% nsupdate -y dyn.sabi.net:[…]
> server osric.zoiks.net
> zone dyn.sabi.net
> update add marcia.dyn.sabi.net. 86400 A 1.2.3.4
> send

08:16:07.005128 IP (tos 0x0, ttl 64, id 492, offset 0, flags [none], proto UDP (17), length 163, bad cksum 0 (->aabb)!)
    marcia.cmi.sabi.net.9009 > osric.zoiks.net.domain: 57701 update [1n] [1au] SOA? dyn.sabi.net. (135)
08:16:07.055297 IP (tos 0x20, ttl 55, id 52179, offset 0, flags [none], proto UDP (17), length 140)
    osric.zoiks.net.domain > marcia.cmi.sabi.net.9009: 57701 update- 0/0/1 (112)
Comment 4 Willem Toorop 2014-05-27 15:26:16 CEST
Looking at the code I also noticed ldns-update contact the update server on port 5353.  Do you see an attempt if you sniff for that port too?
Comment 5 Nicholas Riley 2014-05-27 15:54:48 CEST
Yes, three in fact:

08:52:54.610355 IP (tos 0x0, ttl 64, id 802, offset 0, flags [none], proto UDP (17), length 175, bad cksum 0 (->a979)!)
    marcia.cmi.sabi.net.52386 > osric.zoiks.net.mdns: 50547 update+ [1n] [1au] SOA (QM)? dyn.sabi.net. (147)
08:52:59.614114 IP (tos 0x0, ttl 64, id 812, offset 0, flags [none], proto UDP (17), length 175, bad cksum 0 (->a96f)!)
    marcia.cmi.sabi.net.39207 > osric.zoiks.net.mdns: 50547 update+ [1n] [1au] SOA (QM)? dyn.sabi.net. (147)
08:53:04.631667 IP (tos 0x0, ttl 64, id 814, offset 0, flags [none], proto UDP (17), length 175, bad cksum 0 (->a96d)!)
    marcia.cmi.sabi.net.26189 > osric.zoiks.net.mdns: 50547 update+ [1n] [1au] SOA (QM)? dyn.sabi.net. (147)
Comment 6 Willem Toorop 2014-05-27 17:36:40 CEST
:( Somewhere in 2006 the port to send updates to has been set to 5353 .

http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=047e61f0

I guess the quick fix is to change this back to 53, then at least it would work for you if you specify the domain explicitly.

This has been done in the developers release:
http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=558a40d5

I'll deal with the various other bugs in ldns-update later...
Comment 7 Nicholas Riley 2014-05-27 18:31:03 CEST
I applied the patch and it works.

Unfortunately, there's one more problem - ldns-update keeps adding addresses but it doesn't ever delete the old ones.

I think I'm going to declare defeat for the moment, but thanks again for following up and I hope I can use ldns-update in the future.
Comment 8 Willem Toorop 2014-05-27 18:47:21 CEST
Try none for the ip address to remove them all, i.e.:

ldns-update marcia.dyn.sabi.net dyn.sabi.net none dyn.sabi.net hmac-md5 '<hmac>'
Comment 9 Nicholas Riley 2014-05-27 18:53:40 CEST
Nice! That would be a good thing for the man page too :-)
Comment 10 Willem Toorop 2014-11-26 14:17:43 CET
Thank you Nicholas,

I finally came to fixing all the outstanding issues with this ticket:

http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=fd298327

You should now be able to use ldns-update without explicitly specifying the zone to be updated.

Regards,

-- Willem
Comment 11 Nicholas Riley 2014-12-07 20:05:20 CET
Thanks - recompiled/reinstalled and everything works great!  Now for a release so it can get packaged... :-)