Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals

[Jelte Jansen <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/29/2011 08:33 PM, Edward Lewis wrote:
> At 19:14 +0100 3/29/11, George Barwood wrote:
> 
>> The standard ( http://tools.ietf.org/html/rfc4034#section-4.1.2 ) says
>>    The Type Bit Maps field identifies the RRset types that exist at the
>>    NSEC RR's owner name.
> 
> It doesn't say "MUST".  That's giving the semantic meaning of the
> field.  And it doesn't say "when" existence is tested.
> 

It does not say 'MAY depend on type' either :)

> The problem is determining a if there is a protocol violation.
> 
> If you get this:
> 
> t=0 (Q:fqdn.tld./IN/AAAA):
> fqdn.tld.   3600 IN NSEC other.tld. priv_type
> t=5 (Q:fqdn.tld./IN/A):
> fqdn.tld.   3600 IN A 127.0.0.1
> 
> How can you tell if I generated the NSEC regardless of the A record or
> just before the A record was added to the zone?  In the latter case, if
> you asked for the A you don't get the would-be-new NSEC.
> 

as with another example you used in a previous discussion, it would seem
you are arguing for not doing negative caching at all (i.e. if an A
record is queried, does not exist, is then added, and queried again it
would show the same behavior as when you ask for a different type and
derive data from the nsec bitmap). Taking that further, what if
something is removed between t=0 and t=5, should we also not do positive
caching? :)

IMO whether or not aggressive caching should be done or allowed, giving
different answers where one would expect the same (i.e. different NSECs
depending on the qtype, in this case) makes me slightly nauseous :p But
that is probably not much of a protocol qualification.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2TFmAACgkQ4nZCKsdOncWNfwCfQl7zOdcS8jue8L3wv6G9KApc
fwcAoLlIQlvsQSpRuWRrmIOHmzjBuPT9
=ut5O
-----END PGP SIGNATURE-----