Subject: RCODE implementation done :-)

From: bert hubert <[email-masked]>
Date: Thu, 27 Sep 2001 18:57:04 +0200

On Thu, Sep 27, 2001 at 05:36:04PM +0200, bert hubert wrote:

> We're now implementing RCODE, and one thing that comes to mind is what
> should 'win' in a zone:
> 
> tst	IN	RCODE1  4 02030405
> tst	IN	A	1.2.3.4

We're now 'done' implementing RCODE. The main thing we learned was that
'RCODE140' may be a tad long for many implementations, we had to stretch our
SQL tables to accomodate. You may want to use an enum construction
internally.

The entire diff is under 150 lines, so other implementors should not have a
lot of problems.

> The easiest way out is to specify that RCODE matches are only tried for
> records which are really unknown to the nameserver. However, this might lead
> to uncertainty. Another way out is to suggest that a nameserver should
> reject a zone with RCODE records for rrtypes it understands natively.

This is what we do now.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: bert hubert <[email-masked]>
Date: Thu, 27 Sep 2001 17:36:04 +0200

tst	IN	RCODE1  4 02030405
tst	IN	A	1.2.3.4

Now a request comes along for the A record of tst, what should be in the
answer section? 

This is an admittedly trivial example, but some guidence would be nice. This
involves modifying the RFC1034 algorithm.

The clearest solution, which does require real work on the part of
nameserver implementors is to treat RCODE and 'native' equivalently, which
would in this case lead to an answer of '1.2.3.4' AND '2.3.4.5'.

Sorry for butting in this late, but non-specification of this behaviour will
lead to serious incompatibilities, which was just what we tried to prevent.

Regards,

bert

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 27 Sep 2001 12:37:06 -0700 (PDT)

> We're now implementing RCODE, and one thing that comes to mind is what

RCODE1?  Do you mean TYPE1?  Also, you are missing the \# marker.

> Now a request comes along for the A record of tst, what should be in the

A resource record set consisting of two A records.  The unknown-rrs
draft says:

   Even though an RR of known type represented in the \# format is
   effectively treated as an unknown type for the purpose of parsing the
   RDATA text representation, all further processing by the server MUST
   treat it as a known type [...]

In other words, your example is treated exactly the same way as if
the zone had contained two ordinary A records.
-- 
Andreas Gustafsson, [email-masked]

---

From: bert hubert <[email-masked]>
Date: Thu, 27 Sep 2001 22:35:32 +0200

> the zone had contained two ordinary A records.

Ok, missed that. For a nameserver that parses its zones on startup, this
means some extra work once (it needs to flag known-unknown rrs). 

For nameservers that work from a database, this means an additional lookup
for *each* query to figure out if there are 'known-unknown rrs' around.

In fact, it might be better to make each query an ANY query internally
then.

Regards,

bert

---

From: Brian Wellington <[email-masked]>
Date: Thu, 27 Sep 2001 19:57:26 -0700 (PDT)

> means some extra work once (it needs to flag known-unknown rrs).

Why?  When parsing the zone, it parses each record regardless of whether
it is known or unknown.

> for *each* query to figure out if there are 'known-unknown rrs' around.

Again, why?  The database should have a simple type number -> rrset
mapping.  There's no fundamental difference whether the data was loaded
from the canonical format or the unknown rr format.  Database lookups have
nothing to do with the textual representation of the type code.

If, however, you are storing data in a database that stores the textual
representation of types, you should convert unknown RR type formatted
records into their canonical form before storing them, when the type is
known.  For example, if you see a TYPE1 record, store it as an A record.

> In fact, it might be better to make each query an ANY query internally

No, this would be an exceedingly bad idea, and is completely unnecessary.

Brian

---

From: bert hubert <[email-masked]>
Date: Fri, 28 Sep 2001 10:44:22 +0200

> known.  For example, if you see a TYPE1 record, store it as an A record.

The main reason for being smart about 'known unknown types' is upgrades.
Only then will you encounter a TYPE# which you now understand natively. 

> No, this would be an exceedingly bad idea, and is completely unnecessary.

I suggest you write a database driven nameserver before making statements
about them.

Anyway, we've implemented it because it is useful for us - it provides a lot
of flexibility because of the ability to serve unknown types. I'm not sure
if we'll follow the 'known unknown types are equivalent with natice types'
rule.

Regards,

bert

---

From: Brian Wellington <[email-masked]>
Date: Fri, 28 Sep 2001 11:45:06 -0700 (PDT)

> Only then will you encounter a TYPE# which you now understand natively.

No.  The unknown rr-types draft does not prohibit using TYPE1 records
instead of A records, for example.

> I suggest you write a database driven nameserver before making statements

I suggest you don't make assumptions.  Having written both the unknown rr
type support for bind 9 and the sample postgres backend, I think I'm
qualified to say that it is possible, using exactly the method I
described.

> if we'll follow the 'known unknown types are equivalent with natice types'

Then you're violating the spec.

Brian