Subject: [DNSOP] Where in a CNAME chain is the QNAME?

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Sep 2016 18:13:50 +0200

Do you like long terminology discussions, backed by a dozen RFC, where
people disagree on what's written in these RFC? If so, read on.

This issue was spotted by Peter van Dijk. It is about
draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The
problem is the definition of "QNAME" when there is a CNAME chain.

Section 1.1 says:

> "Denied name": the domain name whose existence has been denied by a
> response of rcode NXDOMAIN.  In most cases, it is the QNAME but,
> because of [RFC6604], it is not always the case.

And section 2:

> Warning: if there is a chain of CNAME (or DNAME), the name which
> does not exist is the last of the chain ([RFC6604]) and not the
> QNAME.  The NXDOMAIN stored in the cache is for the denied name, not
> always for the QNAME.

This text in draft-ietf-dnsop-nxdomain-cut-05 assumes that the QNAME
is the owner name in the Question Section. But RFC 2308 thinks otherwise:

> "QNAME" - the name in the query section of an answer, or where this
> resolves to a CNAME, or CNAME chain, the data field of the last
> CNAME.

RFC 1034 had a different definition of QNAME but is not clear on the
specific case of CNAME chains:

> A standard query specifies a target domain name (QNAME)

RFC 7719 does not define QNAME (probably because it seemed obvious).

So, which is right? In this DNS query:

% dig A www.afnic.fr

; <<>> DiG 9.10.3-P4-Ubuntu <<>> A www.afnic.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35551
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;www.afnic.fr.		IN A

;; ANSWER SECTION:
www.afnic.fr.		213 IN CNAME www.nic.fr.
www.nic.fr.		213 IN CNAME lb01-1.nic.fr.
lb01-1.nic.fr.		213 IN A 192.134.5.24

;; Query time: 875 msec
;; SERVER: 192.168.43.1#53(192.168.43.1)
;; WHEN: Tue Sep 20 18:11:06 CEST 2016
;; MSG SIZE  rcvd: 100

Is the QNAME "www.afnic.fr" or "lb01-1.nic.fr" ("the data field of the
last CNAME")???

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 20 Sep 2016 12:37:53 -0400

> people disagree on what's written in these RFC? If so, read on.

Yes, please!

> > A standard query specifies a target domain name (QNAME)

RFC 1034 gives an "algorithm" (§4.3.2):

    […] Search the available zones for the zone which is the nearest
    ancestor to QNAME. […]

        […] If the whole of QNAME is matched, we have found the node.

            If the data at the node is a CNAME, and QTYPE doesn't match
            CNAME, copy the CNAME RR into the answer section of the
            response, change QNAME to the canonical name in the CNAME
            RR, and go back to step 1.

            […]

It seems the use of QNAME for anything other than the question resource
record name is due to this "variable reuse" in the §4.3.2 "algorithm".

RFC 1035 gives a definition of QNAME in §4.1.

    All communications inside of the domain protocol are carried in a
    single format called a message. […]

    The names of the sections after the header are derived from their
    use in standard queries.  The question section contains fields that
    describe a question to a name server.  These fields are a query type
    (QTYPE), a query class (QCLASS), and a query domain name (QNAME).
    […]

So, this implies that QNAME means the same thing regardless of whether
the message is a query or response.

Also see §4.1.2 which is even more graphic about where the QNAME is.

> Is the QNAME "www.afnic.fr" or "lb01-1.nic.fr" ("the data field of the

"www.afnic.fr", because that is the domain name in the question section.

-- 
Robert Edmonds

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 20 Sep 2016 09:56:14 -0700

The definition of QNAME in RFC 2308 feels like it is only relevant when 
discussing negative caching, not in general. All the other uses of the 
1034/1035 definition of QNAME after 2308 feel consistent.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Sep 2016 13:09:11 -0400

> "www.afnic.fr", because that is the domain name in the question section.

+1.
The QNAME is (or, should be :-)) the name which is in the question.
Things get tricky when chasing CNAMEs because there can be multiple
questions, and so "the" QNAME changes. But, in your example above, I
believe it is www.afnic.fr.

I think the RFC2308 definition is only true in the negative caching
context... or something...

W

>
> --
> Robert Edmonds
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 20 Sep 2016 22:08:20 +0200

Hello,

> people disagree on what's written in these RFC? If so, read on.

When I told you about this confusion in your draft I wasn’t even 
looking for a long terminology discussion. Be careful what you wish for, 
I suppose ;)

> RFC 7719 does not define QNAME (probably because it seemed obvious).

I checked 7719 today, was surprised QNAME was not in there. Probably a 
good idea to fix for 7719bis?

> Is the QNAME "www.afnic.fr" or "lb01-1.nic.fr" ("the data field of the

In my mind, lb01-1.nic.fr, but I understand the other position - 
somewhat.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 20 Sep 2016 22:09:25 +0200

Hello,

> context... or something...

Which, of course, is the context in which draft-ietf-dnsop-nxdomain-cut 
uses QNAME.

I’m not here to argue which definition of QNAME is correct, but I do 
think the text could use some clarification to avoid this confusion. 
Easiest might be to point at 2308 as that definition is functionally 
identical to the longer texts the draft has now.

Kind regards,

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 23 Sep 2016 10:22:32 +0200

On Tue, Sep 20, 2016 at 06:13:50PM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> problem is the definition of "QNAME" when there is a CNAME chain.

OK, after reading the discussion, my opinion, as an author (but I'll
of course defer the decision to the working group, the WG chairs, the
RFC editor and the flying spaghetti monster):

The re-definition of QNAME by RFC 2308 is awkward and does not match
the general usage, or the previous definitions. Therefore, I prefer to
keep the "common sense" usage "QNAME is the owner name of the record
in the Question Section". Which means that, in my example, the QNAME
is "www.afnic.fr" and the current text of
draft-ietf-dnsop-nxdomain-cut-05 is correct.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 23 Sep 2016 19:57:26 +0000

> draft-ietf-dnsop-nxdomain-cut-05 is correct.

This would I believe cause problems if one then concludes that the
subtree below the QNAME is absent.  Below is a live example I just
configured on a BIND 9.10.4-P2 authoritative server as reported by
an "unbound" recursor (RRSIGs elided):

    ; <<>> DiG 9.10.4-P2 <<>> +dnssec +noall +comment +qu +ans +auth +nocl +nottl +cmd -t a truth.msmuxy.org
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39791
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
    ;truth.msmuxy.org.      IN A
    truth.msmuxy.org.       CNAME   fiction.msmuxy.org.
    msmuxy.org.             SOA     ns.imrryr.org. postmaster.dukhovni.org. 631 3600 1200 604800 1200
    U3H5CG8C4NE5NMCTRQ6BGRTB6LS3ROJQ.msmuxy.org. NSEC3 1 0 10 468B49CA72DA45F2 VM1M59BBPA704LUI11Q0T4CA3VA6KS77  NS SOA MX RRSIG DNSKEY NSEC3PARAM
    RP80TVU8HQVVE7P086NTPTN2SLRLU5OC.msmuxy.org. NSEC3 1 0 10 468B49CA72DA45F2 TM87BRIHMJM6HUF608JKLNOGTJQIAH0J

While at the same time we also have:

    ; <<>> DiG 9.10.4-P2 <<>> +dnssec +noall +comment +qu +ans +auth +nocl +nottl +cmd -t a stranger.truth.msmuxy.org
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56877
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ;stranger.truth.msmuxy.org. IN A
    stranger.truth.msmuxy.org. A    192.0.2.1

So the NXDOMAIN for "truth" in the first query definitely does not
preclude a "stranger" subtree under "truth".  It only attests to
the non-existence of "fiction".

IIRC, reading a long-ago discussion on this topic, Paul Vixie, for
one, seemed to say that the first NXDOMAIN response is not only
acceptable, but is in fact the more correct choice.  That compared
with the alternative of returning just the CNAME (NOERROR) w/o a
chained answer for the original RRTYPE and leaving the client to
ask again with the target name only to discover that the target of
the CNAME elicits NXDOMAIN.

So it seems that "NXDOMAIN" + CNAME, attests only to the target,
not the original QNAME and with DNSSEC comes along with a proof
of non-existence for the target, and a proof existence for the
CNAME itself.

This could almost have imposed rather complex for DANE clients,
had there been a possibility of useful TLSA records for a hostname
that is an alias leading to a non-existent target.  However, since
it is not possible to connect to such a host (no A/AAAA records),
any TLSA records it might have are moot.

-- 
	Viktor.

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 23 Sep 2016 16:21:19 -0400

Viktor Dukhovni wrote:
> subtree below the QNAME is absent.

How would one conclude that, when the document is careful to distinguish
between the QNAME and the "denied name"?

    Abstract

       This document states clearly that when a DNS resolver receives a
       response with response code of NXDOMAIN, it means that the domain
       name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

       […]

       […]

       Warning: if there is a chain of CNAME (or DNAME), the name which does
       not exist is the last of the chain ([RFC6604]) and not the QNAME.
       The NXDOMAIN stored in the cache is for the denied name, not always
       for the QNAME.

       […]

-- 
Robert Edmonds

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 25 Sep 2016 11:06:02 +0000

On Fri, Sep 23, 2016 at 07:57:26PM +0000,
 Viktor Dukhovni <[email-masked]> wrote 

> subtree below the QNAME is absent.

For the record, I agree with Robert Edmonds: this case is well covered
in the current draft-ietf-dnsop-nxdomain-cut-05, with the concept of
"denied name" (which is often, but not always, the QNAME).

> preclude a "stranger" subtree under "truth".  It only attests to the
> non-existence of "fiction".
> 
> acceptable, but is in fact the more correct choice.

Yes, and it has been settled some time ago, with RFC 6604.

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 26 Sep 2016 09:33:46 +0200

Hello,

> draft-ietf-dnsop-nxdomain-cut-05 is correct.

2308 does not “redefine” QNAME. It clarifies that the usage in 1034 
4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not conflict 
with this; the QNAME there is just the initial QNAME.

Many other RFCs need 2308: 2874, 4035, 4343, 4592, 4470, 4471, 5074, 
5155, 6147, 6672 and most likely several others rely on the 2308 
definition of QNAME. Without 2308, each of these RFCs would need extra 
text such as the text your draft has now. It is simply not necessary.

Kind regards,

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 26 Sep 2016 12:33:39 +0100

On Mon, Sep 26, 2016 at 8:33 AM, Peter van Dijk <[email-masked]
> wrote:

> 2308 does not “redefine” QNAME. It clarifies that the usage in 1034 4.3.2
> is the definition we use in RFCs. 1035 4.1(.2) does not conflict with this;
> the QNAME there is just the initial QNAME.
>
> Many other RFCs need 2308: 2874, 4035, 4343, 4592, 4470, 4471, 5074, 5155,
> 6147, 6672 and most likely several others rely on the 2308 definition of
> QNAME. Without 2308, each of these RFCs would need extra text such as the
> text your draft has now. It is simply not necessary.
>
>
> Peter, is right
but the root cause is the role of "CNAME" and to lesser extent "DNAME".
Both is what I have part of DNS Navigation records that act like
"rewriters".
1034 was light on detail, 2308 might have uses a better notation but the
effect would have been the same,
The RCODE applies to the RRSET pointed to by the last CNAME in answer
section (or the missing one).

In hindsight the use of single RCODE with limited enumeration is the root
cause.
If one was designing this again one would allow multiple Questions in the
header and each RRset would have a header that says what its ReturnCode is,
but that is the advantage of hindsight.

Olafur

---

From: Matt Larson <[email-masked]>
Date: Mon, 26 Sep 2016 09:04:54 -0400

> On Sep 23, 2016, at 4:22 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

+1 to this interpretation.

I think a good case can be made that QNAME is the last target in a chain of aliases based on the "variable substitution" use of QNAME in §4.3.2 of RFC 1035 and the definition of QNAME in RFC 2308.  However, I think this definition violates the principal of least astonishment, as this thread shows: I'd venture that more people familiar with the subject matter would define QNAME as the name in the question section of a DNS message.  (That's my sense of the definition, FWIW.)

I like the current text in draft-ietf-dnsop-nxdomain-cut-05, which avoids confusion by explicitly calling out "denied name".  Even if the consensus of this thread had been that the definition of QNAME was the "last alias target", I'd argue that we'd still want the "denied name" language to avoid any confusion because I don't think the "last alias target" of QNAME is the majority interpretation.

Matt

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 26 Sep 2016 07:32:57 -0700

On 26 Sep 2016, at 0:33, Peter van Dijk wrote:

> 2308 does not “redefine” QNAME. It clarifies that the usage in 
> 1034 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not 
> conflict with this; the QNAME there is just the initial QNAME.

This seems like a very limited view of RFC 1034. RFC 1034 actually 
defines QNAME in Section 3.7.1:

3.7.1. Standard queries

A standard query specifies a target domain name (QNAME), query type
(QTYPE), and query class (QCLASS) and asks for RRs which match.

Further, the usage in Section 4.3.2 does not say that the QNAME is the 
last name in the chain, just that the algorithm itself repeats with a 
new value for QNAME:

             If the data at the node is a CNAME, and QTYPE doesn't
             match CNAME, copy the CNAME RR into the answer section
             of the response, change QNAME to the canonical name in
             the CNAME RR, and go back to step 1.

> text such as the text your draft has now. It is simply not necessary.

I'm quite concerned about the assertion that RFC 4035 relies on RFC 
2038's definition. QNAME is only mentioned in Section 4.5 and 4.7 there, 
and I don't see how those usages indicate that it is the last name in a 
chain. Can you clarify?

--Paul Hoffman

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 26 Sep 2016 12:48:19 -0400

Paul Hoffman wrote:
> This seems like a very limited view of RFC 1034. RFC 1034 actually defines
> QNAME in Section 3.7.1:
> 
> 3.7.1. Standard queries
> 
> Further, the usage in Section 4.3.2 does not say that the QNAME is the last
> name in the chain, just that the algorithm itself repeats with a new value
> for QNAME:
> 

If STD 13 were to be typeset like a technical book, "QNAME" in 1034
§4.3.2 would be styled using the book's typographical convention for a
variable name.

The exact same formulation in §4.3 ("change … to the canonical name in
the CNAME RR") is used again in the resolver algorithm in §5.3:

    The following resolver algorithm assumes that all functions have been
    converted to a general lookup function, and uses the following data
    structures to represent the state of a request in progress in the
    resolver:

    SNAME           the domain name we are searching for.

    STYPE           the QTYPE of the search request.

    SCLASS          the QCLASS of the search request.

    […]

    5.3.3. Algorithm

    The top level algorithm has four steps:

       […]

       4. Analyze the response, either:

       […]

             c. if the response shows a CNAME and that is not the
                answer itself, cache the CNAME, change the SNAME to the
                canonical name in the CNAME RR and go to step 1.

       […]

Since "SNAME" doesn't conflict with a term from another part of the
document set, it's clear that SNAME is being used as a variable name. So
the parallel use in §4.3.2 ("change QNAME to the canonical name") must
also be as a variable name, not a terminological (re)definition.

-- 
Robert Edmonds

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 27 Sep 2016 14:51:31 +0200

Hello Paul,

>             the CNAME RR, and go back to step 1.

My reading of 3.7.1 + 4.3.2 is ‘the QNAME, at any time, means the name 
currently under consideration; initially this is the name from the query 
packet, but it gets updated on every CNAME follow’. To make QNAME work 
consistently between 1034, 2308 and several of the RFCs mentioned below, 
this is the only interpretation that makes sense to me. I don’t see 
any conflict between 1034 and 2308 given this reading.

>> definition of QNAME. Without 2308, each of these RFCs would need 
>> extra text such as the text your draft has now. It is simply not 
>> necessary.
>
> 2038's definition. QNAME is only mentioned in Section 4.5 and 4.7 
> there, and I don't see how those usages indicate that it is the last 
> name in a chain. Can you clarify?

I agree - on rereading that part of 4035 indeed it is talking about 
whole response packets. Must’ve confused it with denials, like in 
5155.

Kind regards,

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 27 Sep 2016 22:08:08 -0400

Hi,

Strong objections to this answer, or can we call it done? 

ISTM that the avoidance of ambiguity for implementers is the key thing here, so I’m especially interested in hearing from anyone who’s not sure how to code this as written.

Thanks all for a good discussion, and the suggestion that defining QNAME might be suitable for draft-ietf-dnsop-terminology-bis.

best,
Suzanne

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 28 Sep 2016 21:32:59 +0000

On Mon, Sep 26, 2016 at 09:04:54AM -0400,
 Matt Larson <[email-masked]> wrote 
 a message of 41 lines which said:

> I'd venture that more people familiar with the subject matter would
> define QNAME as the name in the question section of a DNS message.
> (That's my sense of the definition, FWIW.)

What about adding this text to the Terminology section of the draft?

   <t>"QNAME": it is defined in <xref target="RFC1034"/> and
   in <xref target="RFC1035"/>, section 4.1.2, but, because <xref
   target="RFC2308"/> provides a different definition, we repeat the
   original one here: the QNAME is the owner name of the record in the
   Question section.</t>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 28 Sep 2016 21:26:38 +0000

On Mon, Sep 26, 2016 at 12:33:39PM +0100,
 Ólafur Guðmundsson <[email-masked]> wrote 

> section (or the missing one).

This specific case was settled in RFC 6604 and I did not intend to
reopen it. My problem was with the definition of QNAME, not with the
proper rcode for a chain of CNAME.

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 29 Sep 2016 01:50:05 -0400

>    original one here: the QNAME is the owner name of the record in the

The QNAME is a domain name, but is it an owner name? There is no owned
record data in the question section (and the entries in the question
section are not RRs).

-- 
Robert Edmonds

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 29 Sep 2016 08:17:28 +0000

> proper rcode for a chain of CNAME.

By the way, is it the case that CNAMEs in the answer section MUST
appear in their natural chaining order:

	A. IN CNAME B.
	B. IN CNAME C.
	C. IN CNAME D.
	D. IN CNAME E.

Which is to say can stub resolvers assume that this is always the
case, or would it prudent to reassemble the list by finding the
CNAME whose owner is the qname, and using the target alias to find
the name CNAME, ... recursively without making assumptions about
the order in which the records appear?

I am writing some code in Haskell that process DNS responses, and
made no assumptions about CNAME ordering in the response, because
Haskell is recursive anyway and finding the starting point rather
than using the first remaining response is easy enough.  So this
code is more robust in the face of unexpected CNAME ordering,
irrelevant CNAME responses that are even part of the chain, ...

What I'm wondering about is whether this is just quaint pedantry,
encouraged by a language that makes it all too easy, or sensibly
defensive programming... :-)

Or put another way, does step "3 a" of Section 4.3.2 of RFC 1034
imply that responses MUST contain any CNAMEs in the typically
expected order?  And, if so, is it then the case that clients
(wether stub or iterative) need make no effort to deal with responses
that are not so ordered?  Should clients take care to deal with
CNAMEs in the answer section that don't form a linear chain (out
of order, or not even possible to re-order as a linear chain).

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 29 Sep 2016 07:26:06 -0400

> record data in the question section (and the entries in the question

Yes, I agree. I suggest "the QNAME is the domain name that appears in the
Question section of a DNS message".

-- 
Shumon Huque

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Sep 2016 13:32:15 +0200

On Thu, Sep 29, 2016 at 01:50:05AM -0400,
 Robert Edmonds <[email-masked]> wrote 

> record data in the question section (and the entries in the question

You're rigt, of course. Here is the new version:

<t>"QNAME": it is defined in <xref target="RFC1034"/> and
   in <xref target="RFC1035"/>, section 4.1.2, but, because <xref
   target="RFC2308"/> provides a different definition, we repeat the
   original one here: the QNAME is the domain name in the
Question section.</t>

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 29 Sep 2016 07:36:16 -0700

> record data in the question section (and the entries in the question

Oddly, "owner name" is correct here. From RFC 1035, Section 3.2.1 which 
describes the format of resource records:

All RRs have the same top level format shown below:

                                     1  1  1  1  1  1
       0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                                               |
     /                                               /
     /                      NAME                     /
     |                                               |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |                      TYPE                     |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. . .

where:

NAME            an owner name, i.e., the name of the node to which this
                 resource record pertains.
. . .

And I think that Stephane's new definition text is a good addition to 
the draft.

--Paul Hoffman

---

From: Shumon Huque <[email-masked]>
Date: Thu, 29 Sep 2016 10:44:18 -0400

> All RRs have the same top level format shown below:

Yes, Owner name is defined in terms of a resource record, i.e. the domain
name that owns a resource record.

But the question section has no resource record. It has 3 components of a
potential resource record.

-- 
Shumon Huque

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 29 Sep 2016 11:01:43 -0400

> describes the format of resource records:

Compare that section to the nearly identical §4.1.3, which replaces this
sentence:

with:

    The answer, authority, and additional sections all share the same
    format: a variable number of resource records, where the number of
    records is specified in the corresponding count field in the header.
    Each resource record has the following format:

But, the "All RRs" part of §3.2.1 is still accurate, because an entry in
the question section is not a RR.

There are some other differences between §3.2.1 and §4.1.3, for instance
§3 uses "owner name" while §4 uses "domain name" to describe the NAME
field, and the infamous signed vs. unsigned definition of the TTL field.

-- 
Robert Edmonds

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 29 Sep 2016 08:15:07 -0700

> field, and the infamous signed vs. unsigned definition of the TTL field.

Yes, I see that now. N'r mind...

--Paul Hoffman