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:
Olafur Gudmundsson <firstname.lastname@example.org>
Randy Bush <email@example.com>
Internet Area Director(s):
Thomas Narten <firstname.lastname@example.org>
Erik Nordmark <email@example.com>
Internet Area Advisor:
Erik Nordmark <firstname.lastname@example.org>
To Subscribe: email@example.com
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
o Clarifications for IANA in DNS assignments
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:
|RFC2782||PS||A DNS RR for specifying the location of services (DNS
|RFC2845||S ||Secret Key Transaction Authentication for DNS (TSIG)
|RFC2929|| ||Domain Name System (DNS) IANA Considerations
|RFC2930||PS||Secret Key Establishment for DNS (TKEY RR)
|RFC2931||PS||DNS Request and Transaction Signatures ( SIG(0)s )
|RFC3007||PS||Secure Domain Name System (DNS) Dynamic Update
|RFC3008||PS||Domain Name System Security (DNSSEC) Signing Authority
|RFC3090||PS||DNS Security Extension Clarification on Zone Status
|RFC3110||PS||RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
|RFC3123||E ||A DNS RR Type for Lists of Address Prefixes (APL RR)
Current Meeting Report
[ 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
information flow in key handshake is now identical to NS
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.
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
DS complicates life for resolvers
chop off 2535, or DS, or opt-in
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
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
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
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.
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.
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)