Since we can't have a good argument unless we know we are arguing about:


RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
GLUE RECORDS

If the name server host for a particular domain is itself inside the
domain, then a 'glue' record will be needed. A glue record is an A
(address) RR that specifies the address of the server. Glue records
are only needed in the server delegating the domain, not in the
domain itself. If for example the name server for domain SRI.COM was
KL.SRI.COM, then the NS record would look like this, but you will
also need to have the following A record.


Also, RFC 1034, 4.2.1

to learn. To fix this problem, a zone contains "glue" RRs which are not
part of the authoritative data, and are address RRs for the servers.

And so on. Glue records are address records, not NS records, not PTR
records. Maybe you want to change design assumptions after the cows
have come home to roost, but don't go changing terminology - it just
annoys the pigs.

At 21:15 +0000 11/21/05, bmanning@vacation.karoshi.com wrote:

> so for the dnssec trust model, self-signed or third-party
>signatures are
> not to be used/trusted. but does this lemma preclude the existance of
> such signatures?


We really tried to make a general purpose trust model work. We
really, really tried hard. There was even a US DARPA research task
to study this called FMESHD. The fact is that no one has been able
to find an approach that isn't an open door to a denial of service
attack. Maybe there is one, but no one has found it.

In a nutshell, having one key signed by another, and then vice versa
is a nice little infinite verification loop. 'Course, we could treat
loops like CNAME does. But an implementation would have to also put
an arbitrary cap on chasing extended signature chains.

It's a mess, yes, and it was pushed aside as a neat little idea that
was operationally not feasible. You should have seen the early
cartoons and diagrams of "up tree validation" and the others. I
remember trying to demonstrate it with a bag of paper clips, showing
how it made the root of the DNS tree just another arbitrary starting
point. (Too bad we didn't document those goofy ideas, huh?)

I would say that the presence of third party signatures (I used to
call them non-germane signatures) is a problem for naive code bases
that may try to track them down into a dark alley.

> dns was never frozen while it was being deployed. and i suspect dnssec
> won't be either.


I don't think that is a safe assumption. DNS was deployed in an era
of no oversight. The Internet didn't matter to anyone outside the
club of engineers that worked on it. Now that the Internet matters
to daily life (I would stop short of saying it is essential) DNS and
DNSSEC will seem frozen or glacial. Note the speed with which the
root zone has taken up DNSSEC. Policy dudes don't like shifting
sands, they will put in concrete barriers to stop "erosion."
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar

3 months to the next trip. I guess it's finally time to settle down and
find a grocery store.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: