option 121

Tue Apr 4 10:35:58 UTC 2006

HI,

How the dhcpclient will extract the subnet mask from the dhcp option 121
value? Please refer any related links stating about this if you know.

Thanks in advance

Best Regards,
Abdul Rasheed.

-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On
Behalf Of Simon Hobson
Sent: Tuesday, April 04, 2006 1:13 PM
To: dhcp-users at isc.org
Cc: Ross Boylan
Subject: Re: unsuccessful update of A record

At 17:12 -0700 3/4/06, Ross Boylan wrote:

> > >While working on some network problems I rebooted a dhcp client
system
>> >several times.  For some reason, one of those times the client got a
>> >new IP address from the dhcpd server.  My forward (A) DNS ended up
>> >pointing at the old location, and the bind logs show the update to
the
>> >A record failed because there was an existing entry for that name.
>> >
>> >The logs also show that before updating the reverse record the old
>> >entry is deleted.
>>
>> Can you post the log entries.
>These are from bind9 logging category update.

Normal update at 15:33

>updating zone 'betterworld.us/IN': adding an RR at
'corn.betterworld.us' A
>updating zone 'betterworld.us/IN': adding an RR at
'corn.betterworld.us' TXT
>updating zone '192.in-addr.arpa/IN': deleting rrset at
'25.40.168.192.in-addr.arpa' PTR
>updating zone '192.in-addr.arpa/IN': adding an RR at
'25.40.168.192.in-addr.arpa' PTR

Then at 16:00

>updating zone 'betterworld.us/IN': update unsuccessful:
corn.betterworld.us: 'name not in use' prerequisite not satisfied
(YXDOMAIN)
>updating zone 'betterworld.us/IN': update unsuccessful:
corn.betterworld.us/TXT: 'RRset exists (value dependent)' prerequisite
not satisfied (NXRRSET)
>updating zone 'betterworld.us/IN': update unsuccessful:
corn.betterworld.us: 'name not in use' prerequisite not satisfied
(YXDOMAIN)
>updating zone 'betterworld.us/IN': update unsuccessful:
corn.betterworld.us/TXT: 'RRset exists (value dependent)' prerequisite
not satisfied (NXRRSET)

IIRC the query sent to do the update is something like :
IF <name> A a.b.c.d does NOT exist
  OR <name> TXT <some long text key> does exist
THEN
  ADD <name> A a.b.c.d
  ADD <name> TXT <some long text key>

IF the previous update was successful
THEN
  DELETE d.c.b.a.in-addr.arpa PTR
  DELETE d.c.b.a.in-addr.arpa PTR <name>

That is what you are seeing in :
corn.betterworld.us: 'name not in use' prerequisite not satisfied
(YXDOMAIN)
corn.betterworld.us/TXT: 'RRset exists (value dependent)' prerequisite
not satisfied (NXRRSET)
ie, it's failed both tests and so the update fails.

I'm guessing that it was written this way because it's nice and simple -
you compose an update request and fire it off, it either succeeds or
fails. The alternative is going off to get certain records, apply the
tests, then decide what to do - more dns calls, and duplicating
functionality that's already been written and extensively tested by the
Bind team.

># It tried several more times thereafter
>19:46
>22:27
>then

@22:34 - the lease on 192.168.40.25 has expired

>updating zone 'betterworld.us/IN': deleting an RR
>updating zone 'betterworld.us/IN': deleting an RR
>updating zone '192.in-addr.arpa/IN': deleting rrset at
'25.40.168.192.in-addr.arpa' PTR

then @09:26 the next day

>updating zone 'betterworld.us/IN': adding an RR at
'corn.betterworld.us' A
>updating zone 'betterworld.us/IN': adding an RR at
'corn.betterworld.us' TXT
>updating zone '192.in-addr.arpa/IN': deleting rrset at
'45.40.168.192.in-addr.arpa' PTR
>updating zone '192.in-addr.arpa/IN': adding an RR at
'45.40.168.192.in-addr.arpa' PTR
>
>So I guess it keeps trying to update DNS until it succeeds?  And the
>deletions above represent the expiry of the old lease?

It retries every time the client renews it's lease. By now, the lease on
192.168.40.25 has expired and so the pre-requisites are met and the
update succeeds.

>Or did you mean some other entries (e.g., to try to figure  out why I
>didn't get the same IP address--oh, I think I see.  The client came
>back up and asked for its old IP address.  But the server decided the
>address was in use, since there was an active lease.  So it gave out a
>different one.  Right?)

Wrong ! The server will give a client the same lease it previously had
IF it is available (ie hasn't been given to something else in the
meantime). The primary key is the client-id, if a client-id is not
specified then it falls back to using the MAC address. If the key used
changes (ie you change/add/remove the client id, or change network card
when no client id is used) then the client is NOT the same client any
more and will be given a different address.

I'm guessing that you changed (or added or removed) the client-id,
that's why the address changed.

> > That is up to the client. Mac OS X clients do that, they explicitly
>> release their lease before shutting down, most clients don't. There
>
>Is this configurable with the dchp3 client?

A quite peruse of the manual didn't show anything.

> > are pros and cons both ways : releasing the lease virtually
>> eliminates the problems caused by moving subnets when the dhcp server
>> is not authoritative; on the other hand, hanging on to it makes the
>> client more robust (it generally has a working address when it starts
>> so less problems if the dhcp server dies or there's a temporary
>> network problem).
>
>Is it the case that the client will try to get its old IP even if it
>has given up the lease?  I was mostly thinking of that, but I see your
>point about dealing with outages.

Again, that is client dependant. From the client side, it can ASK for
anything it wants, but the server will decide what it actually offers.

>I can come up with a method that is reliable enough for me, but I'd
>guess from the lack of this feature, and the discussion here of client
>id's, that there isn't a way that's reliable in general.  There are
>all kinds of oddball scenarios even I can come up with (switching
>ethernet cards between machines, two clients with same hostname, ...).

Hang around here for a while and you'll find situations that make those
seem routine !

>But let me turn that around: if the server is about to hand out an IP
>address to a machine that already has a forward record with a
>different IP address, isn't that a sign that something is wrong?  Even
>so, I guess the proper behavior isn't clear, particularly since dhcp
>clients may not be setup for passing on warning messages.

It may or may not be an error. The mechanism used was decided on a few
years ago when laptops with multiple nics (wired & wireless) were not
exactly common, and for most users, most of the time, it works OK. One
thing to bear in mind is that for most admins, the DNS is not essential
(heck, I'd say 99% of sites using dhcp don't even have ddns), and since
the hostname can be anything the user decided to call their machine then
the hostname isn't normally a reliable thing to use.

>Anyway, it would be nice to have some hooks for alternate ways of
>dealing with this.  Maybe they are there, and I just don't know them.
>
>>
>> >My leases are relatively brief, so at least the problems tend to
> > >self-correct after a few hours.

More precisely, when the old lease expires.

> > Better still, if you knwo that you are modifying the client,
manually
> > release it's lease beforehand (on Windows it's "ifconfig /release").
>
>Is there a linux analogue?

Again, don't know.

Simon

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com