Subject: 2052bis miscellany

From: Thomas Narten <[email-masked]>
Date: Tue, 01 Dec 1998 13:08:40 -0500

Here are some editorial comments on the current draft.

>   ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
>   level broadcasts to locate servers.

You should reference RFC 2219 for aliases, and 1035 for MX records.

>   either A RR's, AAAA RR's, or their most modern equivilent.

s/equivilent/equivalent

>        The symbolic name of the desired service, as defined in Assigned
>        Numbers or locally.  An underscore (_) is prepended to the

Reference RFC 1700?

> The format of the SRV RR

It wouldn't hurt to put in the sizes of the fields. As it is, one has
to figure this out by looking at the min/max values.

>    Target
>         As for MX, the domain name of the target host.  There MUST be
>         one or more address records for this name. Implementors are
>         urged, but not required, to return the address record(s) in the
>         Additional Data section.  Name compression is to be used for
>         this field.

I assume that CNAMEs are a MUST NOT here? Is this worth spelling out
explicitely?

>    the actual answer size by much.  If an answer may be close to the
>    limit, using e.g. "dig" to look at the actual answer is a good idea.

s/using e.g. "dig"/using a DNS querying tool (e.g., "dig")/ ??

>         else if the service desired is SMTP
> 
>              skip to RFC 974 (MX).

I must be missing something here. This "else if" resides *after* the
normal SRV lookups have already taken place. Isn't it the case that
for SMTP, SRVs should NOT be used at all?

>         else
> 
>              Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
> 
>              for each address record found, try to connect to the
>              (protocol, address, service)
> 
>    Notes:

Is there an unnecessary a page break right before "Notes"?

>       - With SRV, DNS spoofers can supply false port numbers, as well as
>         host names and addresses.  The authors do not see any practical
>         effect of this.

How about changing the last sentence to something like: Because this
vulnerability already exists today (i.e., DNS spoofers can supply
false addresses), this does not introduce a new vulnerability.

Thomas

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 02 Dec 1998 08:49:24 -0600

>>        Numbers or locally.  An underscore (_) is prepended to the

Referencing STD 2 would be more durable, na?

>>         one or more address records for this name. [...]
> 

That would be a corollary of the no CNAME-plus-other rule, but
statting the obvious would probably stave off O(3) naive questions
per year, and O(sqrt(N)) erroneous zone configurations.

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 02 Dec 1998 14:00:51 -0600

>   | That would be a corollary of the no CNAME-plus-other rule,
> 
> I think Thomas was referring to the name in the RDATA of the SRV,
> rather than the label of the SRV (for which I believe it is too obvious
> to need stating).

The name in the RDATA must have one or more address records.  Since
you can't have CNAME + other, that name must not have a CNAME record.

I guess it is subtle enough to be worth a mention.   :-/

> I agree that it would be good to explicitly say whether aliases are
> allowed as values in the SRV RDATA or not - saying "names must have A
> records" is the kind of semi-ambiguous restriction which later can lead
> to problems - some read it as "there must be an A RR in the DNS for this
> name exactly" (hence prohibiting aliases), others read it as "the name
> must be able to be resolved into an address" (which does not prohibit a
> few alias redirections along the way).

If you recall the last sentence of the "Overview" section, I think it
is already pretty explicit.  But, I've been hounded by AD's for
things that I thought were just as explicit, so may as well play to
the lowest common denominator*.

				Matt

(* How did that term ever come about, anyway?  In math, there's a
*greatest* common deniminator, a/k/a greatest common divisor, and
there's a least common *multiple*.)

---

From: Robert Elz <[email-masked]>
Date: Thu, 03 Dec 1998 06:17:08 +1100

Date:        Wed, 02 Dec 1998 08:49:24 -0600
    From:        "Matt Crawford" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Referencing STD 2 would be more durable, na?

If the reference is there, the RFC Editor will poke it into standard
form, which includes both the STD, and the most recent RFC, number.
If this reference is added, making it be STD2 in the text, or "AssignedNum"
or something, would make more sense though.   (As does referencing STD13
rather than 1034/5).

Adding either "the name may be an alias (have a CNAME RR), as long as
A records can be obtained for it", or "the name must not be an alias,
it must have A records for it in the DNS with no CNAME records" would
be a benefit.    I prefer the latter - save the resolvers the extra work
of constantly chasing alias chains, and makes it much easier for the
server to do additional section processing.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 3 Dec 1998 03:11:52 -0000

Robert Elz writes:
> "names must have A records"

Do you seriously mean that the server is violating the protocol if it
provides a SRV record that points to a name that happens not to have an
A record? If someone sets up an offsite SRV record pointing to one of
your names, and you then remove your A records, is the previously valid
SRV record suddenly violating the protocol?

Or do you just mean ``the client will not use names without A records''?

> "the name must not be an alias,

Are you saying that an alias prohibition would simplify implementations?
How, exactly?

Or are you saying that an alias prohibition would make a perceptible
speed difference for the client or server? Have you done any real
measurements of the frequency of MX records pointing to aliases?

What do you do if, for internal reasons, you want to change blah.oz.au
into an alias for fubar.oz.au, but blah.oz.au happens to be listed in a
bunch of offsite SRV records?

---Dan

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 Dec 1998 16:56:59 +1100

Date:        3 Dec 1998 03:11:52 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Do you seriously mean that the server is violating the protocol if it
  | provides a SRV record that points to a name that happens not to have an
  | A record?

Server, questionable, probably not (the server should simply respond with
whatever data it has been configured) - the operator who set it up, then
perhaps yes, depending upon what is decided here (if you remember my
message was of the form "we should say explicitly either A or not A")

  | If someone sets up an offsite SRV record pointing to one of
  | your names, and you then remove your A records, is the previously valid
  | SRV record suddenly violating the protocol?

Yes, it would be.    Exactly as it would be if the name itself were
removed from the DNS completely, rather than just switching it to
have a CNAME rather than an A RR.   There is nothing new in this, it
applies to NS and MX already (technically anyway).

  | Or do you just mean ``the client will not use names without A records''?

That's another possibility - though the two can co-exist (it can
be a protocol error, which leads to the client not using it).

  | Are you saying that an alias prohibition would simplify implementations?
  | How, exactly?

If aliases are allowed, and additional section processing is to be
done, then the additional section processing needs to chase CNAME chains.
Typical implementations have not done that before, as it has never
been required.

  | Or are you saying that an alias prohibition would make a perceptible
  | speed difference for the client or server? Have you done any real
  | measurements of the frequency of MX records pointing to aliases?

No measurements, no.   I do however see those on occasion (sim for NS
records), and I do observe that the A record that would normally be in the
additional data section is not present, meaning that the resolver (if it
doesn't happen to have the data cached from some earlier query) is going
to have to do an extra query that could have been avoided - that is, even
in cases where the CNAME and the A record for the canonical name were all
authoritatively known by the server which answered the query.

  | What do you do if, for internal reasons, you want to change blah.oz.au
  | into an alias for fubar.oz.au, but blah.oz.au happens to be listed in a
  | bunch of offsite SRV records?

I don't make the change (not that that particular one would occur anyway,
oz.au isn't that kind of domain).   There is little requirement for the
use of aliases for anything, ever - simply duplicating the data of the
canonical name produces the same results.   So, if I have a name that I
am intending to allow to be a MX target, or a NS target (or probably in the
future, a SRV target), then I simply commit to keeping its A record for as
long as the underlying service is to exist.   If I want the server to have
a new name, I just create the new name, with its own A record (and potentially
change the PTR record).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Dec 1998 01:44:11 -0000

There are three different possibilities under discussion here:

   (1) Prohibit aliases in SRV records.

   (2) Allow aliases in SRV records, without requiring that servers
       attempt to chase those aliases in additional section processing.

   (3) Allow aliases in SRV records, and require that servers attempt to
       chase those aliases in additional section processing.

I was asking about the relative benefits of #1 and #2. It didn't occur
to me that anyone was considering #3.

> done, then the additional section processing needs to chase CNAME chains.

That is true for #3 but not for #2. Is there any reason that #2 would
create more work for implementors than #1?

> There is little requirement for the use of aliases for anything, ever -
> simply duplicating the data of the canonical name produces the same results.

Why don't you think that the same argument applies to IP addresses?

You attacked the idea of _allowing_ IP addresses by, first, bringing up
the strawman of _requiring_ IP addresses; second, claiming that such a
requirement would impose huge administrative burdens; third, ignoring
the traffic and cache benefits of widespread use of IP addresses.

But now you advocate _requiring_ canonical names. You point to the
efficiency benefits of not having resolvers ``constantly chasing'' alias
chains---even though you admit that this happens only ``on occasion.''
You ignore the administrative problems solved by offsite aliases.

There is a curious inconsistency here.

---Dan