<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [dns-operations] IPv6 & IPv4 addresses</TITLE>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<STYLE type=text/css>BLOCKQUOTE {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</STYLE>
<META name=GENERATOR content="MSHTML 8.00.6001.19019"></HEAD>
<BODY bgColor=#ffffff>
<DIV>
<DIV><FONT size=2 face=Arial>> No - that violates what's in RFC 2308.
</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Err.. I don't see how it violates that, certainly
not on the authoritative server side.</FONT></DIV>
<DIV><FONT size=2 face=Arial>A server can put whatever it fancies in the
additional section if it feels it is helpful.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>On the resolver side, making use of the NSEC
information for related queries is more</FONT></DIV>
<DIV><FONT size=2 face=Arial>controversial, in view of </FONT><FONT size=2
face=Arial>the last section of rfc4035 section 4.5</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> In theory, a resolver could use
wildcards or NSEC RRs to generate<BR> positive and negative
responses (respectively) until the TTL or<BR> signatures on the
records in question expire. However, it seems<BR> prudent for
resolvers to avoid blocking new authoritative data or<BR>
synthesizing new data on their own. Resolvers that follow
this<BR> recommendation will have a more consistent view of the
namespace.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>The language here is quite tentative though,
leaving room for interpretation.</FONT></DIV>
<DIV><FONT size=2 face=Arial>There would be questions as to how long the
negative information can be cached.</FONT></DIV>
<DIV><FONT size=2 face=Arial>That's normally taken from the SOA
record.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>By way of an example, I have set up a server/domain
that sends the NSEC record proving no AAAA.</FONT></DIV>
<DIV><FONT size=2 face=Arial>( It doesn't send an SOA record yet...
)</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>dig A <A
href="http://www.emsv.co.uk/">www.emsv.co.uk</A>. +dnssec
@a.ns.emsv.co.uk</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>and a domain that sends both A and AAAA
</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>dig A test.emsv.co.uk +dnssec
@a.ns.emsv.co.uk</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>( Note, it sends the NSEC record anyway...
)</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>The problem I see (apart from the rfc section
above) is that the changes</FONT></DIV>
<DIV><FONT size=2 face=Arial>to resolvers to take advantage of the NSEC info
would be relatively complex.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>George</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV></DIV></BODY></HTML>