Subject: [DNSOP] DNS terminology: "Passive DNS"

From: Robert Edmonds <[email-masked]>
Date: Tue, 17 Mar 2015 22:56:44 -0400

Hi,

draft-hoffman-dns-terminology-02 has the following definition:

   Passive DNS -- A mechanism to collect large amounts of DNS data by
   storing queries and responses from many recursive resolvers.  Passive
   DNS databases can be used to answer historical questions about DNS
   zones such as which records were available for them at what times in
   the past.

I think this is referring to the concept originally described in Florian
Weimer's "Passive DNS Replication" paper [0], which sort of combines the
collection and retention aspects into a single term.  Also, scale
("large", "many") may be an interesting property of a particular
deployment, but it isn't really intrinsic to the definition of the term.
Nor do all systems collect both queries and responses (some only collect
responses).  I would propose something like the following instead:

   Passive DNS Replication -- A mechanism to collect and store resource
   records by observing responses, usually those sent by authoritative
   servers. Passive DNS databases can be used to recover DNS records
   which were served in the past, and may allow certain kinds of
   "inverse" searches of the stored records. Sometimes shortened to
   "passive DNS".

[0] http://www.enyo.de/fw/software/dnslogger/first2005-paper.pdf

-- 
Robert Edmonds

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 17 Mar 2015 20:03:40 -0700

I think the distinction here is really important. Precise language, or
lack thereof, results in unfortunate conclusions.

$bystander;

- - ferg

On 3/17/2015 7:56 PM, Robert Edmonds wrote:

> storing queries and responses from many recursive resolvers.
> Passive DNS databases can be used to answer historical questions
> about DNS zones such as which records were available for them at
> what times in the past.
> 
> I think this is referring to the concept originally described in
> Florian Weimer's "Passive DNS Replication" paper [0], which sort of
> combines the collection and retention aspects into a single term.
> Also, scale ("large", "many") may be an interesting property of a
> particular deployment, but it isn't really intrinsic to the
> definition of the term. Nor do all systems collect both queries and
> responses (some only collect responses).  I would propose something
> like the following instead:
> 
> Passive DNS Replication -- A mechanism to collect and store
> resource records by observing responses, usually those sent by
> authoritative servers. Passive DNS databases can be used to recover
> DNS records which were served in the past, and may allow certain
> kinds of "inverse" searches of the stored records. Sometimes
> shortened to "passive DNS".
> 

- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2
"I am tormented with an everlasting itch for things remote. I love to
sail forbidden seas." - Herman Melville

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 18 Mar 2015 17:06:38 +0100

On Tue, Mar 17, 2015 at 10:56:44PM -0400,
 Robert Edmonds <[email-masked]> wrote 

>    "inverse" searches of the stored records. Sometimes shortened to

My contribution to the painting of the bikeshed: I would drop "usually
those sent by authoritative servers" because the responses can be sent
by servers which are not authoritative for this specific zone (that's
why DNSDB indicates the bailiwick of the response).

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Mar 2015 09:18:59 -0700

> why DNSDB indicates the bailiwick of the response).

in DNSDB, any bailiwick value you see is of an authority zone, and thus,
"usually those sent by authoritative servers". i believe that robert's
terminology was carefully chosen, and is correct.

-- 
Paul Vixie

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 18 Mar 2015 12:37:42 -0400

> why DNSDB indicates the bailiwick of the response).

Hi, Stephane:

I was actually trying to draw a distinction between "above the
recursive" and "below the recursive" collection, which is shown
graphically in the slide 13 set in [0].  The work in [1] is an example
of a system that collected both types of data.

Maybe the following is better:

   records by observing responses, usually those received by recursive

Thanks!

[0] http://www.enyo.de/fw/software/dnslogger/first2005-interactive.pdf

[1] http://www.cc.gatech.edu/~ynadji3/docs/pubs/dnsnoise-dsn2014.pdf

-- 
Robert Edmonds

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 18 Mar 2015 17:29:49 -0400

Hi,

draft-hoffman-dns-terminology-02 has the following definitions:

   In-bailiwick response -- A response in which the name server
   answering is authoritative for an ancestor of the owner name in the
   response.  The term normally is used when discussing the relevancy of
   glue records.  For example, the parent zone example.com might reply
   with glue records for ns.child.example.com.  Because the
   child.example.com zone is a descendant of the example.com zone, the
   glue is in-bailiwick.

   Out-of-bailiwick response -- A response in which the name server
   answering is not authoritative for an ancestor of the owner name in
   the response.

A few comments:

 * A zone can't send a reply; the authoritative server for a zone can.

 * "Response" isn't defined(!), nor is "reply".  I was (pedantically)
   thinking of an RFC 1035 §4 message with the QR bit set to 1 at first,
   but that doesn't fit well in the context of "the owner name in the
   response", because a response message can contain RRs with different
   owner names, and records within a response message can be
   individually considered in-bailiwick or out-of-bailiwick.  It would
   be good to clarify which owner name is being compared.

 * RFC 5452 §6, though it uses "in-domain" rather than "in-bailiwick",
   uses the concept of "deeming" the authoritativeness of a record.
   RFC 3833 §2.3 refers to "the long-standing defense of checking RRs in
   response messages for relevance to the original query".  I think
   these two RFCs are alluding to the same or a similar bailiwick
   concept being defined here.

   Is "in-bailiwick" / "out-of-bailiwick" a property of the data in the
   DNS and how authoritative servers are configured to use it, or is it
   a determination (a "deeming") by a recursive server that the data has
   this property?  I favor the latter, because it is useful to have
   dedicated terminology for the process of determining a server's
   authority, but maybe a separate definition would be helpful:

   Bailiwick checking -- The process of determining whether a record in
   a response message should be considered "in-bailiwick" or
   "out-of-bailiwick".

-- 
Robert Edmonds

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Mar 2015 17:22:41 -0700

>   a response message should be considered "in-bailiwick" or

Ah, the joys of defining terms that have been used a long time, but almost never in RFCs. Grep all the RFCs: you'll see "bailiwick" is used, but not defined, in RFC 6763 and 7477, and nowhere else.

I think "response" and "reply" don't need to be defined, but they do need to be used more carefully, and we didn't do that here, I think (but my co-authors might disagree with me). From looking at your concerns and the general use of "bailiwick", I propose that it is records, not responses, that in- or out-of.

Further, I disagree with this being about "deeming". There is a simple rule (the owner name is a subzone of the answer), whereas "deeming" indicates that there might be other logic that is not given here.

Proposed rewording, quite open to editing or reversion:

In-bailiwick -- A glue record in which the name server answering is authoritative for an ancestor of the owner name in the record.  The term normally is used when discussing the relevancy of glue records.  For example, the server for the parent zone example.com might reply with glue records for ns.child.example.com.  Because the child.example.com zone is a descendant of the example.com zone, both glue records in-bailiwick.

Out-of-bailiwick -- A glue record in which the name server answering is not authoritative for an ancestor of the owner name of the record.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Mar 2015 22:19:20 -0400

> Ah, the joys of defining terms that have been used a long time, but almost never in RFCs. Grep all the RFCs: you'll see "bailiwick" is used, but not defined, in RFC 6763 and 7477, and nowhere else.

To be fair to the other authors, I suspect I am mostly to blame for
this particularly infelicitous way of defining things.  Good thing we
have WGs to review stuff!
 
> I think "response" and "reply" don't need to be defined, but they do need to be used more carefully, and we didn't do that here, I think (but my co-authors might disagree with me). From looking at…

What's tricky here is that the bailiwick-ness of something is only
relevant given a response.  So it seems to me that it's a question of
records in a given response.  I think Paul's proposed text doesn't
_quite_ get us there, but it's close.  I'll think some more.

> Out-of-bailiwick -- A glue record in which the name server answering is not authoritative for an ancestor of the owner name of the record.

Given the previous discussion about glue, that word seems especially
fraught here.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 18 Mar 2015 22:47:20 -0400

Hi, Andrew:

> _quite_ get us there, but it's close.  I'll think some more.

Do you think the "simple way" in RFC 5452 §6 is talking about the
bailiwick-ness of records, or is it describing something
different/stricter?

> Given the previous discussion about glue, that word seems especially

I note 6763 talks about verifying that "any records" (not just glue
records) in a response are in-bailiwick.

-- 
Robert Edmonds

---

From: Andreas Gustafsson <[email-masked]>
Date: Thu, 19 Mar 2015 10:12:19 +0200

Paul Hoffman wrote:
> Further, I disagree with this being about "deeming". There is a
> simple rule (the owner name is a subzone of the answer), whereas
> "deeming" indicates that there might be other logic that is not
> given here.

Bailiwick checking is not checking that the owner name is a "subzone
of the answer", it is checking that the owner name is a subdomain of
the domain whose servers are being queried.

Suppose we are resolving www.example.com and the "best servers to ask"
(in the algorithm of RFC1034 5.3.3, step 2) are the .com servers.  If
one of them responds with "example.com NS ns1.foo.com" and a glue
record with ns1.foo.com as its owner name, this glue record is
in-bailiwick because it is a subdomain of .com, the domain whose
server is being queried, even though it is not a "subzone of the
answer", which I would interpret as "a subdomain of example.com"
rather than "a subdomain of com".

I believe this is also what RFC 5452 means by "One very simple way to
achieve this is to only accept data if it is part of the domain for
which the query was intended".

This is not limited to glue; the same issues arise with records 
in the additional section and with CNAME chains.
-- 
Andreas Gustafsson, [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Mar 2015 10:23:12 +0000

Andrew Sullivan <[email-masked]> wrote:
> relevant given a response.

My understanding is that "bailiwick" was originally applied to the DNS by
djb. By his definition, bailiwicks are about how delegations are set up;
they are a property of the zone data not of any particular message.

The name servers for a zone are in-bailiwick if and only if their names
are subdomains of the zone apex (or at the zone apex, though this is
rare). In-bailiwick name servers require glue in their parent zone.

The term comes from thinking about poisonous referrals and about when glue
is required for locating a zone's servers, and how these considerations
comflict to some extent. http://cr.yp.to/djbdns/notes.html (though he does
not clearly define the term on that page).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Utsire, South Utsire, Forties, Cromarty, Forth: Variable 3 or 4,
becoming westerly or southwesterly 4 or 5, occasionally 6 later in Forties and
Cromarty. Slight or moderate. Rain at times. Moderate or poor, occasionally
good.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 19 Mar 2015 03:36:37 -0700

> Tony Finch <mailto:[email-masked]>
> Thursday, March 19, 2015 3:23 AM
>

i can't claim that i knew where the term came from, but, that's how i've
always used it.

-- 
Paul Vixie