Current Meeting Report

2.2.2 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 16-Oct-01
Olafur Gudmundsson <>
Randy Bush <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Erik Nordmark <>
Mailing Lists:
To Subscribe:
Description of Working Group:
The DNSEXT Working Group has assumed the RFCs and drafts of both the DNSSEC and DNSIND working groups. DNS is originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are protocol issues, including message formats, message handling, and data formats. New work items and milestones may be added from time-to-time with the approval of the Working Group and the IESG.

Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter. These issues are considered in other venues, such as operational issues in the DNS Operations Working Group.

Broad topics under consideration in DNSEXT are dynamic update, notify, zone transfers, security and adjustments to address the requirements of IPv6 addressing. Security topics, mostly inherited from the erstwhile DNS Security Extensions Working Group, will be addressed in cooperation with the DNS Operations Working Group.

The principal task within this Working Group is to advance several documents describing proposed extensions to DNS. The current list of documents under consideration for advancement is:

Title RFC Status

DNS Server MIB Extensions RFC1611 Proposed

DNS Resolver MIB Extensions RFC1612 Proposed

Serial Number Arithmetic RFC1982 Proposed

Incremental Zone transfer RFC1995 Proposed

Notify RFC1996 Proposed

DNS SRV service location RFC2052 Experimental

Dynamic Update RFC2136 Proposed

Security for Dynamic Update RFC2137 Proposed

Clarification to DNS RFC2181 Proposed

Negative Caching RFC2308 Proposed

DNS Security Extensions RFC2535 Proposed

DSA KEYs and SIGs RFC2536 Proposed

RSA KEYs and SIGs RFC2537 Proposed

Storing Certificates RFC2538 Proposed

Diffie-Hellman Keys RFC2539 Proposed

Extensions to DNS0 RFC2671 Proposed

Non-Terminal DNS names RFC2672 Proposed

Binary Labels RFC2673 Proposed

Other specific work items are:

o TSIG - transaction signatures in (dnsind-tsig-xx.txt)

o TKEY - Secret Key establishment for DNS (dnsind-tkey-xx.txt)

o Securing dynamic update (dnsind-simple-secure-update-xx.txt)

o Protocol clarifications and corrections for DNSSEC (draft-ietf-dnsind-sig-zero-xx.txt) (draft-ietf-dnsind-zone-secure-xx.txt)

o Clarifications for IANA in DNS assignments (draft-ietf-dnsind-iana-dns-xx.txt)

o Documentation of the zone transfer protocol (AXFR)

o Retirement of DNS MIB's RFC's

New work items may be added from time-to-time with the approval of the Working Group and the IESG.

Goals and Milestones:
Done   Advance RFC2052bis to RFC.
Jan 00   Advance RFC1996 for Draft standard.
Done   Advance TKEY and IANA considerations for IESG consideration
Feb 00   RFC1995bis and AXFR advanced for Proposed
Done   SIG(0) advanced for IESG consideration
Mar 00   RFC2136bis advanced for Proposed standard
Mar 00   IXFR (RFC1995bis) interoperabilty testing complete
Apr 00   Serial Number Arithmetic, Notify and DNS Clarify advanced to Draft Standard.
Apr 00   RFC1611 and RFC1612 status chaned to historic.
May 00   RFC2308bis advanced for IESG consideration.
Done   Secure update completed and ready for IESG consideration
Done   RFC2137 Obsoleted
Jun 00   Request that TSIG be advanced to Draft Standard
Jul 00   Revised DNSSEC submitted for advancement to Draft Standard
Request For Comments:
RFC2782PSA DNS RR for specifying the location of services (DNS SRV)
RFC2845S Secret Key Transaction Authentication for DNS (TSIG)
RFC2929 Domain Name System (DNS) IANA Considerations
RFC2930PSSecret Key Establishment for DNS (TKEY RR)
RFC2931PSDNS Request and Transaction Signatures ( SIG(0)s )
RFC3007PSSecure Domain Name System (DNS) Dynamic Update
RFC3008PSDomain Name System Security (DNSSEC) Signing Authority
RFC3090PSDNS Security Extension Clarification on Zone Status
RFC3110PSRSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
RFC3123E A DNS RR Type for Lists of Address Prefixes (APL RR)

Current Meeting Report

DNSEXT minutes

[ it is said that bill is a multicast address, but there was no help in disambiguation ]

multicast dns - is this the right solution?
?: is it the same protocol, or new protocol?
reuse of the port number, reuse of the packet format

?: when we started, "behavior just like DNS"
operational problem, conceptual problem

alain: icmp6 name lookup - one solution looked at (but was not provided for ipv4)

aboba: no set of goals stated, document is ready for ietf last call
something gone very wrong.

is this solving the right problem?
is there a better solution?

mohta: zeroconf is not a good thing to pursue. if we don't want client configuration, dns servers having wellknown anycast addresses work fine

?: would like to do "infrared" thing that palm does, or appletalk. need some mechanism for resolving name.

rob: there are people with different goals.

?: it is a good way to reuse DNS. we won't be able to solve the problem even if we start fresh

aboba: if zeroconf requirement is broken?

olafur: zeroconf is a part of requirement.

dns threat model (rob)

examine why dnssec was started
dnssec ensures data item is the same when they are put in, and when they are pulled out

lack of threat model?

dnssec has dependency on time sync.

delegation signer (olafur)

key record repeats the mistake of ns record in delegations, same record in two zones
key at child is clumbersome
parent advertises strong identifier of key used
verifies DS record from parent
only verifies key if sig matches verified DS

DS advantages
information flow in key handshake is now identical to NS
minimizes communication
only when hcild changes KEY set signing key
less data in parent
DS much small than key
DS only at secdure delegation
child in full control of security status
no conflicting key sets

disadvantages: more work for resolvers.

3 implementations

what change from the last IETF
NODS in NXT bitmap at unsecured delegations
DS can only pont at DS zone keys that can sign zone
key size field dropped
server returning...

DS complicates life for resolvers

chop off 2535, or DS, or opt-in

next steps
DS seem to work
DS makes DNSSEC much/some easier for operations
DS increments complexity in resolvers
advance or discard?

?: is it really advantageous to have less data in parent?
less state - similar to opt-in
minimizes communication

deployability difference for big zones
how much better

should combine discussion for opt-in

it is advantageous that downstream reload does not happen when upstream key changes

balance: decoupling child signing and parent signing - weakening security

outband or inband?

key rollover for .com - 6month, 2 key alive at one time

(comments continue after opt-in talk)


dnssec painful for large zones
huge upfront cost
null KEYS, nxt RR and signatures for child zones that are not secure
little initial deployment
high generation cost

changes since 00
total rewrite
goal is the same, different methods
NXT indicates opt-in instead of KEY
opt-in uses noSig techniques
basically, finer granurality, opt-in 2535 choice can be made on per-record (instead of per-zone)

2535 NXT - authenticated denial of existence of names
does not allow unsigned names
opt-in NXT - authenticated denial of existence of SIGNED names
does allow unsigned names

2535 - positive answer = this delegation is not signed
the unsigned name exist (crypto verifiable)
opt-in - negative answer = there exist no signed delgation between two signed names
the unsigned name exist (not crypto verifiable)

pros and cons
every advantage has disadvantages
positive: opt-in reduces the amount of crypto in a zone
negative: opt-in gives up authenticated denial of existence for unsecured delegations (give up security for unsecured data item)
don't "like" opt-in? sign it with 2535
opt-in does not obsolete 2535

positive side-effect
traversing a zone through NXT recodrs gives only signed names and signed delegations
a chain of secure delegations is possible without the requirement to sign the whole zone

2535 is not "better " ot "worse" than opt-in
2535 has advantages for the average zone
opt-in has advantages for the delegation-only zone (large zone)

randy: change in security model. attacking the problem of size by a protocol change, and security model change. assumption - the little part of zone gets signed.

?: it is already hard to keep up hardware with .com size.

vixie: losing ability to cryptographically prove non-existence of names, or nonexistence of child signature, is it true? - not exactly.

?: it is up to zone owner.

?: we can mix 2535 and opt-in in a single zone.


desire to have algorithms separately documented.
minimize dependency to 2535
key format draft documents standard moduli?

AD bit outstanding issue

ad draft status
document passed working group last call, not sent out

when can AD bit be set?
AD = authenticated data
AD draft says authoritative server can set the AD bit if local security policy allows
comments on the mailing list afer last call disagree

argument for text
the issue only affects resolvers that trust server
doing signature validation on all data loaded is expensive
either slows loading or answers
integrity of whole zones on servers can be protected by other means
signed zone files, signed zone transfer

AD MUST only be set if signatures have been verified
setting the AD bit under other conditions is wrong
AA bit implies that the data is authentic

authors must add text that clarify states that AD bit is not be set by default and MUST only be set if there are some other validity checks in place
document must also document what [stub] resolvers are affected

?: 2535 says about AD bit - data satisfies the security policy of the server

?: what is "policy"? can you tell what kind of policy the server is implementing?

?: the situation happens only when you talk to authoritative zone. it should be your own domain, so you know the policy?

?: why you can't use AA bit for that?

authors will update the draft.

do we need DS? do we need opt-in?

vixie: from test results, it seems (something like) DS is needed for key rollover
opt-in is just a hack for one zone (.com)
anyway we need to get this DONE.

?: opt-in is needed, to sign .com. can't deploy .com with 2535.

?: cost vs usefulness. cost is significant for large zones.

?: does opt-in break security of zones (= signed chain)?

bill: interoperability between 2535 and DS? - yes, DS-capable resolvers can (but there is a flag day).

olafur: we are doing this too long. for DS and opt-in, need go or nogo.

?: there are people who are trying to deploy 2535. too long wait.

randy: agree with vixie.

?: not deployable as it is today.

vixie: need to separate between deployability due to size, and other issues.
does it matter if we sign .com today, or 2004?

this needs to come to conclusion. during this week people will talk and try to come to conclusion, and then to the list.

vixie: the reason why root is not signed is that dnssec is still seems to be in flux

tkey securet key renewal mode

necessary to refresh shared keys for tsig
new mode for update procedure and mechanism in tkey
renewal mode defined

key has lifetime. during renewal, key lifetime overwraps

tsig-signed query from client
expiration time check
server urges clients to send tkey renewal requests

tkey secret key renewal request from client
DH public key
old key's name and algorithm
answer from server
establish new secret by DH

TSIG-signed query with the new key from client
server adopts the new key

systematic control by server
"renewal", not add/delete
limit number of shared keys

think about network errors.

feel no need for this. server can delete the key when it expires.

tkey is just for temporary measure. it is direciton we shouldn't go.

dns mib

proposed replacement for 1611
not ready for prime time yet. please read, test it and comment.

need requirement document to start with.

ngtrans dns op req

problem: IPv4-only and IPv6-only nodes coexist, how to resolve?
long term problem

consequences - this working group has to do something.

single root requirement, applies for IPv4 and IPv6
dns is IP version independent application. need to be able to get the same data independent from data.
we can change v6 things, we cannot change v4 things

need some kind of bridging system, so that v6 only resolver can get data from v4 only server, or other ways
need symmetry in bridging system? no.

v4 resolver - no good way. zone needs to be served by dualstack node.
v6 resolver - relaying system?

leakage of information
serve zones on dualstack node, period.

dynamic update

we assume that updated records gets eventually removed explicitly
state an expiration time

repeat of past effort.

if we are going to repeat this one, requirement document is needed.

we can't assume wall clock (powered off).

there seem to be some need.

application keys - limiting the scope of the key resource record

simple idea - restrict KEY to dnssec.

dnssec key vs application keys - looks like a different beast. reolver behavior is very different.

separate rtype, SRV, KEY, ...
protocol specific flag? attribute? should we separate pubkey and cert?
we need a requirement document.

(battery is out)



None received.