<!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>