Netfence

Like Envoy xDS, but for eBPF filters.

Netfence는 VM/컨테이너 호스트에서 데몬으로 실행되며, eBPF 필터 프로그램을 cgroup 및 네트워크 인터페이스에 자동으로 주입합니다. 허용된 도메인을 확인하고 IP 허용 목록을 채우는 내장 DNS 서버가 포함되어 있습니다.

Netfence 데몬은 로컬 Unix 소켓 API만으로 구동하거나, gRPC를 통해 구현하는 중앙 제어 플레인에 연결하여 백엔드와 허용 목록/차단 목록을 동기화할 수 있습니다.

제어 플레인은 연결된 인터페이스/cgroup에 ALLOW *.pypi.org 또는 ALLOW 10.0.0.0/16과 같은 네트워크 규칙을 푸시합니다. VM/컨테이너가 DNS를 쿼리하면 Netfence가 이를 확인하고, 해당 IP를 eBPF 필터에 추가하며, 알 수 없는 IP로의 트래픽은 호스트를 떠나기 전에 드롭합니다. 현재 벤치마크에서 워밍된 경로의 오버헤드는 일반 소켓 연결과 사실상 구별할 수 없습니다.

기능

• eBPF 필터를 네트워크 인터페이스(TC) 또는 cgroup에 연결
• 정책 모드: 비활성화, 허용 목록, 차단 목록, 모두 차단
• 선택적 TTL이 포함된 IPv4 및 IPv6 CIDR 지원
• 도메인 허용 목록/차단 목록과 순서 지정된 업스트림 재정의가 포함된 연결별 UDP/TCP DNS 서버
• 도메인 규칙은 하위 도메인을 지원하며, 더 구체적인 규칙이 우선함
• 확인된 도메인이 자동으로 IP 필터에 추가됨
• 데몬 및 연결에 대한 메타데이터로 VM ID, 테넌트 등과 연결 가능
• DNS 쿼리를 제어 플레인에 프록시하여 연결별 DNS 결정을 내리는 기능 지원

보안 참고: 기본 제외( carve-out )

허용 목록 모드에서 IPv4 링크-로컬(169.254.0.0/16)은 더 이상 기본적으로 자동 허용되지 않습니다 — 따라서 클라우드 메타데이터 서비스(169.254.169.254)는 명시적으로 허용 목록에 추가되지 않으면 차단됩니다. 이는 의도적인 것입니다: 메타데이터 서비스는 자격 증명 도용 대상이며, 샌드박스된 워크로드는 암묵적으로 이에 접근할 수 없어야 합니다. 로컬호스트(127.0.0.0/8, ::1) 및 IPv6 이웃 탐색(fe80::/10, ff02::/16)은 기본적으로 허용되어 기본 연결 및 NDP가 계속 작동합니다. 워크로드에 메타데이터 서비스를 허용하려면 169.254.169.254/32를 허용 목록에 추가하십시오 (제어 플레인을 통한 연결별 제외 재정의는 추후 예정).

IPv4 브로드캐스트(255.255.255.255) 및 멀티캐스트(224.0.0.0/4)는 제외되지 않으며 정책의 적용을 받으므로, TC 허용 목록 모드에서 DHCP 갱신 브로드캐스트와 같은 트래픽은 명시적으로 허용되지 않으면 차단됩니다. 제외 검사는 차단 목록보다 먼저 실행되므로, 제외된 범위는 제외를 해제해야만 차단할 수 있습니다. 그리고 IPv4 링크-로컬이 이제 기본적으로 꺼져 있으므로, 차단 목록 모드에서도 메타데이터 서비스를 차단할 수 있습니다.

다른 옵션과의 차이점

이 솔루션은 일반적으로 다른 옵션이 지원하지 않는 몇 가지 주요 이점을 제공합니다:

• IP를 허용하지 않도록 규칙이 변경될 때 기존 연결을 즉시 종료(인터페이스 연결만 해당)
• 모든 네트워크 프로토콜을 지원하며, IP 네트워킹에 직접 연결 가능. 예를 들어 훌륭한 httpjail은 IP에 직접 연결하거나 데이터베이스 연결과 같은 직접 TCP/UDP 연결을 허용하지 않습니다.
• DNS의 동적 확인 및 사전 확인 필터링 (따라서 secretdata.someattacker.com과 같은 데이터 유출이 없음)

제가 알기로는 다른 솔루션은 이러한 모든 기능을 함께 제공하지 않습니다.

알려진 제한 사항: cgroup 연결은 소켓 계층(connect/sendmsg 후크)에서 필터링하므로, CAP_NET_RAW 권한이 있는 프로세스는 이를 우회하는 원시 패킷을 생성할 수 있습니다. CAP_NET_RAW를 보유할 수 있는 워크로드에는 장치 계층에서 필터링하는 TC(인터페이스) 연결을 사용하십시오.

하지만, 이것은 httpjail과 같은 것보다 약간 더 많은 오버헤드가 있습니다.

성능 요약

이 수치는 권한 있는 Docker Linux 게이트(linux/arm64)에서 make bench-docker를 사용하여 측정되었습니다. 값은 5개 샘플의 중앙값입니다.

웜 소켓 경로

웜 소켓 벤치마크는 연결된 UDP 소켓을 사용하여 cgroup/connect4 eBPF 후크 비용을 TCP 핸드셰이크 지연 시간과 분리합니다. 이 경로에서는 DNS가 이미 도메인을 확인했고, IP가 여전히 TTL 내에 있으며, IP/CIDR이 이미 eBPF 맵에 존재합니다.

일반, 보호된 LPM 및 DNS 정확한 호스트 연결 경로 간의 측정된 차이는 샘플 노이즈 범위 내에 있습니다.

현재 "커널 미스가 부모 프로세스에 묻는" 경로는 없습니다. cgroup 허용 목록 미스는 eBPF에 의해 로컬에서 결정되며 즉시 차단됩니다.

DNS 쿼리 경로

이 수치는 웜 소켓 연결 경로가 아닌 DNS 서버 경로를 측정합니다.

콜드 행은 실제 연결 돌연변이 배리어를 동기화하고, 쿼리 사이에 벤치마크 소유권 그래프와 가상 정확 맵 스냅샷을 지웁니다. 타이머는 UDP 스케줄러 지역성을 유지하기 위해 계속 실행되며, ns/op은 별도로 보고된 fixture-reset-ns/op 월 시간(클라이언트가 패킷을 수신한 후 이전 핸들러의 꼬리 포함)을 빼서 현재 클라이언트 Exchange를 측정합니다. raw-total-ns/op은 둘을 함께 보고합니다. 재설정은 구성된 정책 도메인과 백업 저장소를 유지하며, 벤치마크는 쿼리당 하나의 물리적 정확 맵 추가를 단정합니다. 웜 행은 소유권을 한 번 초기화하고 실행 전반에 걸쳐 하나의 물리적 추가를 단정합니다.

아래의 내부 소유권 마이크로벤치마크는 확장성 진단 도구이며, 종단 간 DNS 쿼리 경로 승인 행이 아닙니다. 캐시된 헬퍼는 테스트 및 벤치마크용으로만 유지됩니다. 한 번에 하나의 레코드를 래핑하고 도메인 유효성 검사를 반복합니다. 이와 일반 리졸버 트래픽 모두 연결 돌연변이 배리어를 통과하며, 일반 리졸버 트래픽은 각 완전한 응답을 하나의 트랜잭션으로 인정합니다.

설계

아키텍처```

+------------------+ +-------------------------+ | Your Control |<------->| Daemon (per host) | | Plane (gRPC) | stream | | +------------------+ | +-------------------+ | | | DNS Server | | | | (per-attachment) | | | +-------------------+ | +-------------------------+ | +------+------+ | | TC Filter Cgroup Filter (veth, eth) (containers)

각 첨부된 워크로드는 데몬에 의해 제공되는 고유한 DNS 주소(포트)를 받습니다. 컨테이너/VM은 할당된 DNS 주소를 사용하도록 구성되어야 합니다. 일반 워크로드 DNS 트래픽을 필터링해도 투명하게 리디렉션되지 않습니다.

### DNS 리졸버 토폴로지 및 동작

`dns.listen_addr`는 연결된 모든 워크로드가 도달할 수 있는 하나의 구체적인 IPv4 또는 IPv6 주소를 식별해야 합니다. 와일드카드 주소는 리졸버 엔드포인트로 광고될 수 없기 때문에 거부됩니다. 구성된 호스트 이름은 데몬이 시작될 때 한 번 확인되며, 결과 구체적인 IP는 바인딩, 광고, 지속성 및 필터 부트스트랩에 사용됩니다. 기본값 `127.0.0.1`은 워크로드가 데몬의 네트워크 네임스페이스를 공유하는 경우에만 적합합니다. 다른 네임스페이스에 있는 컨테이너나 VM은 일반적으로 대신 도달 가능한 호스트/브릿지 주소가 필요합니다.```yaml
dns:
  listen_addr: 10.0.0.1
  port_min: 11000
  port_max: 11500
  # Daemon-global fallback when DnsConfig.upstream_servers is empty.
  upstream: 1.1.1.1:53
  # Hard daemon ceilings for each attachment's bounded DNS exact ownership.
  # Zero/unset uses these defaults (max_ips_per_family instead derives from
  # filter.max_dns_rule_entries).
  max_ips_per_family: 4096
  max_ips_per_response: 64
  max_ips_per_policy_domain: 1024
  max_tracked_domains: 1024
  max_ownership_edges: 8192
  # Rolling physical-admission/LRU mutation budget and slow-planning work
  # allowance. The window is daemon-global and immutable until restart;
  # DnsConfig.max_churn_units may only lower the daemon ceiling.
  max_churn_units: 8192
  churn_window: 1m

Attach는 구체적인 dns_address를 반환합니다. 정확히 해당 주소를 작업 부하의 해석기로 구성하세요. Netfence는 리스너 IP에 대한 보호된 만료되지 않는 /32 또는 /128 허용 항목을 설치하므로 허용 목록 모드가 제어 평면 DNS-IP 규칙 없이 부트스트랩할 수 있습니다. 현재 필터는 IP 접두사를 적용하고 대상 포트는 적용하지 않으므로, 보호된 항목은 리스너 IP의 모든 포트(DNS 포트뿐만 아니라)를 허용합니다. 이는 cgroup 연결 위협 모델에서 특히 중요합니다. 더 넓은 연결성이 허용되지 않는 경우 전용 리스너 IP를 사용하세요.

할당된 엔드포인트는 UDP와 TCP를 모두 제공합니다. UDP 응답은 레거시 클라이언트의 512바이트 제한 또는 광고된 EDNS 크기로 잘리며, 필요 시 TC 플래그를 설정하여 작업 부하가 동일한 엔드포인트로 TCP 재시도를 할 수 있도록 합니다. 업스트림 해석의 경우, 잘린 UDP 응답은 먼저 동일한 업스트림에 대해 TCP로 재시도됩니다. 전송 실패, SERVFAIL 또는 REFUSED가 발생하면 구성된 다음 업스트림으로 순서대로 진행됩니다.

DnsConfig.upstream_servers는 하나의 첨부에 대해 데몬 전역 dns.upstream을 재정의합니다. 항목은 host:port 구문(IPv6 리터럴은 대괄호 사용)을 사용하며, 정규화되고 처음 본 순서대로 중복 제거되며, 최대 8개의 고유 서버로 제한됩니다. 빈 목록은 전역 폴백을 선택합니다.

필터링 모드에서 Netfence는 HTTPS/SVCB 응답에서 ipv4hint 및 ipv6hint 매개변수(해당 mandatory 참조 포함)를 제거합니다. 힌트된 주소가 필터 승인을 독립적으로 통과하지 못했기 때문입니다. 비활성화 모드는 업스트림 응답을 변경하지 않고 유지합니다.

DNS 쿼리 카운터는 상호 배타적입니다. dns_queries_allowed는 정책이 허용하는 성공적으로 응답된 쿼리(NXDOMAIN 포함)를 계산하고, dns_queries_blocked는 정책 REFUSED 응답을 계산하며, dns_queries_errors는 해석기, 프록시, 필터 승인, 응답 쓰기 및 기타 오류 경로를 계산합니다. 각 쿼리는 정확히 하나의 버킷을 증가시킵니다.

필터링 DNS 모드에서 주소를 포함하는 모든 응답은 A/AAAA 응답, 권한, 추가 섹션의 주소가 반환되기 전에 한 번의 트랜잭션으로 첨부의 정확한 IPv4/IPv6 HASH 계층에 승인됩니다. 전체 응답을 표현할 수 없는 경우, 해석기는 주소 없이 SERVFAIL을 반환하고 이전에 승인된 작업 세트를 유지합니다. 주소를 반환하는 PROXY 결정은 add_to_filter를 설정해야 합니다. 그렇지 않으면 SERVFAIL로 실패 폐쇄됩니다. 비활성화 DNS 모드는 명시적인 통과 예외입니다.

정확한 항목은 정규화된 쿼리에서 일치하는 정책 소유자까지의 TTL 간선을 전달합니다. 도메인을 제거하거나 거부하면 마지막 DNS 전용 정확한 주소가 신속히 제거되는 반면, 공유 주소는 다른 활성 쿼리 소유자가 존재하면 유지되고, 겹치는 제어 평면 CIDR은 보호된 LPM 계층에서 독립적으로 계속됩니다. DNS 거부 목록 기본 허용 및 명시적 허용 응답도 추적됩니다. 패킷 거부 목록이 정확한 허용을 무시하는 동안에도 추적되므로, 이후 패킷 모드가 허용 목록으로 전환될 때 재쿼리 없이 이미 반환된 캐시된 주소를 사용할 수 있습니다.

모든 일반/활성 사용자 공간 소유권 상태는 위의 다섯 가지 소유권 설정에 의해 제한됩니다. 복원된 합성 임시 간선은 이러한 논리적 제한에서 면제되어 조정 전에 잊혀지지 않지만, 물리적 IPv4/IPv6 정확한 맵에 의해 제한됩니다. 구성된 정책 도메인과 활성 쿼리 도메인은 max_tracked_domains를 공유하며, 각 (query, matched owner, IP) TTL 레코드는 하나의 max_ownership_edges 슬롯을 소비합니다.

압박 시, 승인은 먼저 만료된 TTL 간선을 제거합니다. 그런 다음 가장 적은 물리적 collateral을 가진 완전한 논리적 쿼리/소유자 간선을 최신 순서보다 먼저 회수한 후, 결정론적 해석기 관찰 LRU(IP 정식화로 동점 해소)를 수행합니다. 물리적 제거는 전체 DNS 정확한 키와 모든 DNS 소유자를 제거합니다. 들어오는 물리적 IP와 정확한 (IP, query, owner) 간선은 응답 트랜잭션 동안 보호됩니다. 복원된 임시 소유권은 권위 있는 조정까지 물리적 키를 보호하지만, 해당 키를 공유하는 관련 없는 일반 DNS 메타데이터는 여전히 회수될 수 있습니다. 권위 있는 제어 평면/시스템 허용 및 모든 거부는 별도의 LPM 계층에 남아 있으며 DNS 회수 대상이 아닙니다.

롤링 첨부별 변동 예산은 새 물리적 정확한 키에 대해 한 단위, 제거된 각 활성 물리적 DNS 키에 대해 한 단위를 부과합니다. 따라서 완전한 구-신 교체는 2 단위가 소요됩니다. 새로고침, 논리적 전용 회수, 만료 및 정책 제거는 비용이 0입니다. 이벤트는 dns.churn_window보다 나이가 적은 동안 활성 상태를 유지하며, 정확한 경계에서 만료됩니다. DnsConfig.max_churn_units는 데몬 상한만 낮출 수 있습니다. 0은 이를 상속받습니다. 윈도우는 제어 평면이 변경할 수 없으며, 데몬 상한/윈도우 변경은 재시작이 필요합니다. 첨부 제한을 낮추었다가 다시 높이면 여전히 활성 상태인 내역을 잊지 않습니다.

별도의 롤링 작업 원장은 비용이 많이 드는 소유권 그래프 계획을 제한합니다. 빠른 새로고침과 일반 승인은 이를 건드리지 않습니다. 압박 경로가 그래프를 복제하거나 분석하기 전에, Netfence는 현재 물리적 키, 소유권 간선, 추적된 도메인 및 응답 크기(데몬/맵 변경 불가 상한 대비)에서 파생된 안정적인 작업 단위를 부과합니다. 이 시도 부하는 계획이 불가능하거나 이후 정확한 맵 트랜잭션이 실패하는 경우에도 유지되며, 위의 트랜잭션 물리적 변동 회계를 변경하지 않고 제로 변이 재시도 경로를 CPU/할당 압력으로 닫습니다. 기본 상한에서 허용량은 창당 최대 8회의 그래프 패스를 허용합니다. DnsConfig.max_churn_units를 낮추면 최소 1회가 유지됩니다. 제한을 낮추었다가 다시 높이면 활성 작업 내역이 다시 조정되거나 잊혀지지 않습니다.

적격 DNS 상태가 범위를 충족할 수 없거나 두 롤링 허용량 중 하나가 소진된 경우, Netfence는 승인된 작업 세트를 유지하고 승인되지 않은 주소를 반환하지 않고 SERVFAIL을 반환합니다. 용량 실패는 map_full_drops를 증가시킵니다. 물리적 변동 및 계획 작업 제한은 증가시키지 않습니다. 하트비트는 정확한 맵의 현재, 용량 및 프로세스 생성 최고값, 누적 DNS LRU 제거, 모든 승인 실패, 그리고 두 롤링 가드를 모두 포함하는 집계 예산 제한 횟수를 노출합니다. 용량, 물리적 예산 및 작업 예산 압박/복구 로그는 독립적으로 속도 제한됩니다. 운영자는 TTL/윈도우 복구를 기다리거나, 응답/도메인 변동 또는 반복된 용량 압력 시도를 줄이거나, DnsConfig.max_churn_units를 데몬 dns.max_churn_units 상한까지 높일 수 있습니다. 데몬 상한을 높이려면 재시작이 필요합니다. filter.max_dns_rule_entries를 늘리려면 첨부도 다시 만들어야 합니다. 고정 맵은 제자리에서 크기를 조정할 수 없기 때문입니다.

보호된 CIDR 용량 및 실패 폐쇄 복구

권위 있는 제어 평면 CIDR 및 데몬 시스템 규칙은 4개의 독립적이고 제거 불가능한 LPM 맵(허용/거부 × IPv4/IPv6)을 사용합니다. 각 맵은 filter.max_rule_entries 슬롯을 가집니다. DNS 리스너 /32 또는 /128 부트스트랩은 시스템 허용이며 해당 보호된 허용 맵에 포함됩니다. DNS 정확한 호스트 항목은 별도의 맵에 남아 있으며 이 슬롯을 소비할 수 없습니다. 보호된 규칙은 LRU 제거되지 않습니다. 명시적 허용, 시스템 규칙 및 모든 거부는 권한 있는 제거 또는 완전한 교체가 있을 때까지 유지됩니다.

완전한 SubscribedAck 또는 BulkUpdate는 정규화되고, 변이 전에 4개 맵 모두의 최종 점유율이 확인됩니다. 용량은 최종 상태를 기준으로 하므로, 가득 찬 맵에서 키를 교체하는 것은 유효합니다. 초과 상태는 규칙을 제거하거나 부분 수락하지 않고 거부됩니다. 생존자는 제거되었다가 다시 추가되지 않습니다. 이후 맵 syscall이 실패하면 Netfence는 호출 전 정확한 4개 맵 인벤토리를 복원하고 확인합니다. 롤백 후 입증된 모드는 이전 모드 또는 BLOCK_ALL(일반적으로 BLOCK_ALL)이므로, 데몬은 완전한 권위 있는 재시도가 성공할 때까지 첨부 실패 폐쇄를 유지합니다.

보호된 정책 안전 상태는 첨부와 함께 유지되며 하트비트로 내보내집니다. BLOCK_ALL 자체는 정상적인 건강한 구성 모드입니다. policy_degraded_reason이 비어 있으면 policy_degraded는 false입니다. 건강한 BLOCK_ALL 상태에서 시작하는 위험한 보호된 변이는 먼저 protected_policy_mutation_in_progress를 저널링합니다. 이는 일시적인 충돌 저널이지 안정적인 실패 진단이 아닙니다. 라이브 작업은 최종 저널 클리어 저장 전에 의도된 모드를 게시할 수 있으며, 성공적인 완료는 저널 자체를 지웁니다. 시작 시 충돌 후 이 저널을 발견하면, 시작은 먼저 BLOCK_ALL을 강제로 입증한 다음 protected_policy_mutation_interrupted를 유지합니다. 안정적인 저하 이유 코드는 다음과 같습니다.

• protected_policy_mutation_interrupted
• authoritative_protected_policy_failed
• incremental_deny_install_failed
• incremental_allow_removal_failed
• incremental_mode_change_failed

이것들은 안정적인 분류로, 원시 syscall/저장소 텍스트가 아닙니다. 진행 중 저널은 내부 유지 충돌 경계입니다. 하트비트 통계는 소유 변이와 함께 직렬화되므로, 라이브 중간 저널이 아닌 성공적인 clear 또는 안정적인 실패 변환을 관찰합니다. 안정적인 저하/중단 이유는 입증된 BLOCK_ALL에서 패킷 시행을 유지하고 증분 CIDR 및 패킷 모드 명령을 거부합니다. 독립적인 DNS 구성 변경 및 DNS TTL 만료는 해당 입증된 유지 아래 계속될 수 있지만, 안정적인 이유를 지우거나 패킷 정책을 다시 활성화할 수 없습니다. 안정적인 이유에서 복구하려면 하나의 완전한 LPM 및 DNS 원하는 상태가 필요합니다. 제어 평면 또는 로컬 API를 통해 BulkUpdate를 적용(또는 복원된 첨부의 새로운 Subscribed에 SubscribedAck로 응답)합니다. Netfence는 전체 보호된 상태를 준비하고, 권위 있는 DNS 상태를 적용하며, 요청된 모드를 활성화하고, 모든 단계가 성공한 후에만 지속 이유를 지웁니다. 제어 평면 복구 BulkUpdate에는 고유한 command_id를 사용하고 성공적인 CommandResult를 요구합니다. 로컬 API는 단항 RPC 결과가 이미 성공 또는 실패를 보고하므로 command_id를 거부합니다.

하트비트는 4개의 보호된 맵에 대해 각각 현재 물리적 항목, 하드 용량 및 데몬 생성 최고값을 노출합니다. 부트스트랩이 포함됩니다. 채택된 고정 맵은 새 생성의 최고값을 초기화합니다. map_full_drops는 누적되며 보호된 용량 거부를 포함합니다. 점유율 읽기가 실패하면, 데몬은 마지막으로 입증된 스냅샷을 유지하고 새 카운트를 발명하는 대신 최대 30초에 한 번 경고를 내보냅니다. 압박에서 복구하려면 각 맵 용량 미만으로 전체 원하는 규칙을 줄이고 전체 업데이트를 재시도하세요. filter.max_rule_entries를 높이는 것은 로드 시에만 가능하며 기존 고정 첨부를 다시 만들어야 합니다. 데몬이 BLOCK_ALL을 입증하거나 안전 마커를 지속적으로 기록할 수 없으면 변이 승인을 중단합니다. 맵/저장소 결함을 수리하고 시행이 다시 열렸다고 가정하지 말고 다시 시작하세요.

호스트별

데몬을 실행하면 다음이 수행됩니다.

• 첨부, 정책 및 검사를 위한 로컬 gRPC API(DaemonService) 노출
• 선택적으로 양방향 스트림(ControlPlane.Connect)을 통해 제어 평면에 연결
• eBPF 프로그램 로드 및 관리

데몬 시작:```bash

Start with default config

netfenced start

Start with custom config file

netfenced start --config /etc/netfence/config.yaml

**데몬 상태 확인:**```bash
netfenced status

control_plane.url가 없으면 새 첨부가 비활성화된 패킷/DNS 모드로 커밋되며 로컬 API 또는 CLI를 통해 즉시 구성할 수 있습니다. '첨부당'에 문서화된 독립 실행형 워크플로에는 컨트롤 플레인 프로세스가 필요하지 않습니다.

로컬 Unix 소켓 신뢰 경계

로컬 gRPC API에는 RPC별 인증이 없습니다. Unix 소켓에 대한 파일 시스템 액세스가 권한 부여 경계이며, 연결할 수 있는 모든 프로세스는 완전히 신뢰할 수 있는 호스트 네트워크 관리자입니다. 즉, 호스트 eBPF 프로그램을 연결하거나 분리하고, 패킷 및 DNS 정책을 교체하고, 워크로드 트래픽을 열거나 닫을 수 있습니다. 소켓 그룹 멤버십을 좁게 유지하고 소켓의 상위 디렉터리를 보호하세요.```yaml

Defaults to /var/run/netfence.sock.

socket: /run/netfence/netfence.sock

Unix group name or numeric GID. Empty/unset uses the daemon's effective GID.

socket_group: netfence-admin

`NETFENCE_SOCKET`와 `NETFENCE_SOCKET_GROUP`은 동등한 환경 변수입니다. 시작 시 데몬은 비공개 스테이징 디렉토리에 소켓을 바인딩하고, 도달 불가능한 상태에서 그룹과 모드를 `0660`으로 설정한 후, 원자적으로 게시합니다. 데몬은 구성된 대상에 이미 존재하는 유닉스 소켓을 제거합니다—오래된 소켓과 다른 활성 데몬이 소유한 소켓을 구분하지 않음—따라서 정확히 하나의 데몬이 소켓 경로를 소유해야 합니다. 소켓이 아닌 대상은 제거를 거부합니다. Linux에서는 no-replace rename을 통해 해당 제거 후 생성된 새 경로의 덮어쓰기를 방지합니다. 종료 시 데몬의 자체 소켓 inode를 여전히 식별하는 경우에만 게시된 경로를 제거합니다. 잘못된 그룹, 소유권/모드 실패 또는 소켓이 아닌 대상은 허용적인 엔드포인트를 게시하지 않고 시작에 실패합니다.

### 제어 평면 전송 보안 (TLS / mTLS / 베어러 토큰)

제어 평면 채널은 시스템에서 가장 가치가 높은 공격 표면입니다(이를 제어하는 사람은 모든 워크로드에 `ALLOW` 규칙을 푸시할 수 있음). 따라서 데몬은 **기본적으로 실패(fails closed)**합니다: `control_plane.url`이 설정된 경우, 구성은 명시적으로 전송 방식을 선택해야 합니다—`control_plane.tls` 블록 또는 `control_plane.insecure: true`. 둘 다 없는 URL은 시작 시 거부됩니다. 암시적 일반 텍스트 기본값은 없습니다. (이는 의도적인 동작 변경입니다: 이전 버전은 제어 평면에 암호화되지 않은 상태로 자동 연결되었습니다.)```yaml
control_plane:
  url: cp.internal:443
  tls:
    # CA bundle used to verify the control-plane server certificate.
    # Path to a PEM file or inline PEM; omit to use the system root pool.
    ca: /etc/netfence/cp-ca.pem
    # Client certificate + key (path or inline PEM). Setting BOTH enables
    # mTLS: the daemon presents this cert to the control plane. Setting only
    # one is a config error.
    cert: /etc/netfence/daemon.pem
    key: /etc/netfence/daemon.key
    # Optional hostname override for server certificate verification (SNI),
    # e.g. when dialing by IP.
    server_name: cp.internal
  # Optional bearer token, sent as `authorization: Bearer <token>` metadata
  # on every control-plane RPC. Refused on a plaintext channel unless
  # `insecure: true` was explicitly set (so a misconfiguration can't leak it).
  auth_token: "..."

시스템 루트만 사용하는 TLS (공개 CA 발급 서버 인증서, mTLS 없음)는 그냥 빈 블록입니다:```yaml control_plane: url: cp.example.com:443 tls: {}

로컬 개발을 위한 평문(plaintext)은 명시적인 옵트인(opt-in)이며 (상호 배타적
`tls`와):```yaml
control_plane:
  url: localhost:9000
  insecure: true

인증서와 키는 시작 시 한 번 로드되므로, 잘못된 경로/PEM은 재연결할 때마다 오류가 표시되는 대신 명확한 오류와 함께 시작에 실패합니다.

컨트롤 플레인 활성 상태 유지(keepalive) 및 재연결 백오프

데몬은 컨트롤 플레인 연결에 HTTP/2 keepalive 핑을 전송하여, 조용히 죽은 경로(케이블 분리, NAT 매핑 해제, 블랙홀 라우트)가 감지되고 대략 keepalive_time + keepalive_timeout — 대신 커널의 TCP 재전송 타임아웃이 발생할 때까지 몇 분 동안 CONNECTED 상태로 남아, 모든 프록시 DNS 쿼리가 전체 타임아웃을 소비하게 됩니다. 재연결은 지터가 추가된 지수 백오프(1초에서 시작, 두 배 증가, ±20% 지터, reconnect_backoff_max에서 제한)에 의해 조절됩니다. 백오프는 연결이 30초 동안 정상 상태를 유지한 후에야 최소값으로 재설정되므로, 연결을 수락했다가 즉시 끊는 컨트롤 플레인은 최소값에서 계속 재시도하는 대신 백오프를 계속하게 됩니다.```yaml control_plane:

Send a keepalive ping after this much inactivity… (default 30s; gRPC

clamps the effective interval to a 10s minimum client-side)

keepalive_time: 30s

…and declare the peer dead if no ack arrives within this (default 10s).

keepalive_timeout: 10s

Cap on the jittered exponential reconnect backoff (default 30s).

reconnect_backoff_max: 30s

0 또는 설정되지 않은 값은 기본값을 의미합니다 — **keepalive 또는 백오프를 비활성화하지 않습니다**. 제어 평면은 gRPC keepalive 시행 정책에서 이 핑 주기를 허용해야 합니다 (아래 참조), 그렇지 않으면 데몬을 `ENHANCE_YOUR_CALM (too_many_pings)` 오류로 거부합니다.

### 데몬 재시작, 충돌 및 업그레이드 (고정된 BPF 상태)

데몬은 모든 첨부(attachment)의 BPF 링크와 규칙 맵을 bpffs에 고정합니다(`filter.bpf_pin_dir`, 기본값 `/sys/fs/bpf/netfence`, 첨부 ID당 하나의 디렉터리). 고정된 상태는 커널이 보유하기 때문에 — 데몬 프로세스가 아닙니다 — **데몬이 종료된 동안에도 시행이 계속됩니다**: 충돌(`kill -9`), 정상 중지 또는 업그레이드 시 마지막으로 알려진 정책(모드 + 모든 규칙)이 시행 상태로 남아 있으며, 다음 데몬 시작 시 고정된 상태를 그대로 다시 채택합니다. 복원 시 라이브 맵을 다시 첨부하거나 다시 쓰지 않으므로, 허용 목록에 있는 워크로드가 차단되거나 차단된 대상이 허용되는 기간이 없으며, 중복 첨부도 발생하지 않습니다.

중지 동작은 명시적 구성(`filter.detach_on_stop`)입니다:```yaml
filter:
  # false (default): stopping the daemon KEEPS ENFORCING — filters stay
  # attached via their bpffs pins and are re-adopted on the next start
  # (fail-closed across restarts/upgrades).
  # true: stopping the daemon detaches filters and removes their pins —
  # traffic is unfiltered while the daemon is down (explicit fail-open).
  detach_on_stop: false
  # bpffs directory for pinned state. Must be on a bpffs mount; the daemon
  # mounts bpffs at /sys/fs/bpf if needed (privileged). An explicit "" turns
  # pinning off entirely (BPF state then dies with the process).
  bpf_pin_dir: /sys/fs/bpf/netfence
  # Capacity of each authoritative/system LPM map (allowed/denied per family).
  # Protected entries are non-evictable; the DNS listener bootstrap consumes
  # one slot in its address family. Changing pinned-map capacity requires
  # recreating the attachment.
  max_rule_entries: 4096
  # Independent capacity of each DNS-derived exact-host HASH map (IPv4/IPv6).
  # These entries can never consume or evict authoritative/deny capacity.
  max_dns_rule_entries: 4096

명시적인 Detach(RPC/CLI) 또는 라이브 일관성 있는 소유 대상의 제거는 연결과 함께 핀 고정 상태를 파괴합니다. 재시작 시 대상이 없어도 추측을 허용하지 않습니다. 향후의, 커밋되지 않은, 혼합된, 또는 검증할 수 없는 지속된 핀은 보존되며 시작이 중단되어 검사할 수 있습니다.

핀 디렉터리는 버전 관리된 지속성 형식입니다. 스키마 마커는 필요한 모든 맵과 링크가 존재한 후에 마지막으로 핀 고정됩니다. 사전 정확 계층 첨부 파일을 업그레이드하면 진행 중 마커와 함께 두 개의 새로운 빈 정확 맵이 핀 고정되고, 라이브 권위 맵을 재사용하면서 각 링크의 프로그램을 원자적으로 교체하며, 프로그램/맵 정체성을 확인하고 마지막으로 마커를 커밋합니다. 충돌 또는 모호한 업데이트는 마커가 커밋되지 않은 상태로 남습니다. 다음 시작 시 동일한 맵을 사용하여 모든 링크를 다시 업데이트합니다. 이전 및 새 프로그램 세대는 해당 제한된 혼합 상태 동안 동일한 권위 LPM 정책을 강제하므로, 마이그레이션은 실행 가능한 필터를 핀 해제하거나 재생성하지 않습니다. 알 수 없거나 불완전하거나 검증할 수 없는 핀 집합은 보존되며, 추측되지 않고 검사를 위해 시작이 중단됩니다.

재채택된 상태에 대한 참고 사항:

• 성공적으로 복원된 모든 첨부 파일은 권위 조정을 위해 표시됩니다. 각 제어 평면 연결 시 데몬은 먼저 SyncRequest를 보낸 다음, 여전히 조정이 필요한 복원된 각 첨부 파일에 대한 완전한 Subscribed 선언을 보냅니다. 새 SubscribedAck로 응답합니다. 해당 모드, CIDR, TTL 및 DNS 구성이 완전한 원하는 상태입니다. 데몬은 델타를 적용합니다(변경되지 않은 CIDR은 절대 제거되지 않음). 전체 Ack가 적용된 후에만 복원 마커를 지웁니다. 시간 초과, 연결 해제 또는 검증 실패는 강제를 변경하지 않습니다. 필터/맵/DNS/저장소 적용 실패는 부분 델타를 남길 수 있지만, 조정은 전체 맵 지우기 또는 변경되지 않은 생존자의 제거/재추가를 사용하지 않습니다. 복원 마커는 설정된 상태로 유지되며 데몬은 이후 연결 후 다시 시도합니다.
• 규칙 TTL 기한 자체는 지속되지 않습니다. 재채택된 규칙은 새 SubscribedAck가 도착할 때까지 임시로 영구적인 것으로 처리됩니다. 해당 권위 Ack는 정확히 수명을 대체하며, 기한을 단축하거나 임시 영구 규칙을 다시 유한 TTL 규칙으로 전환하는 것을 포함합니다. 복원된 정확 DNS 키는 인벤토리화되고 제한된 임시 소유자로 표현됩니다(실제 핀 고정 맵 용량이 한계임). 첫 번째 권위 DNS 구성은 모든 합성 클레임을 폐기하고, 소유자 없는 키를 제거하며, 키가 별도로 정상적인 라이브 소유자를 가질 때만 보존합니다. 비정식/충돌 인벤토리는 소유권 메타데이터를 추측하거나 부분 게시하지 않고 복원을 중단합니다.
• 지속된 로컬 원하는 상태 문서는 없습니다. 제어 평면이 구성되지 않았거나 연결할 수 없는 경우 자동 규칙 변경이 발생하지 않습니다. 채택된 핀 고정 맵은 사용자 공간 레지스트리에서 완전한 업데이트까지 임시로 표시된 마지막으로 알려진 보호된 CIDR을 계속 강제합니다. 유효한 핀을 채택할 수 없는 복원은 빈 맵(허용 목록/차단 모두에 대해 실패-폐쇄)으로 지속된 모드에서 첨부 파일을 재생성합니다. 독립형 오케스트레이터는 임시 패킷 상태를 대체하고 완전한 원하는 상태와 TTL을 복원하기 위해 데몬이 재시작할 때마다 netfenced apply-rules을 다시 재생해야 합니다.
• DNS 도메인 규칙, 첨부 파일별 업스트림 재정의 및 첨부 파일 DNS 제한은 로컬 API 또는 제어 평면을 통해 제공되는 런타임 원하는 상태입니다. 지속되지 않습니다. 마지막 DNS 모드가 ALLOWLIST, DENYLIST 또는 PROXY였던 복원된 첨부 파일은 빈 ALLOWLIST 상태로 리졸버를 시작하며, 완전한 BulkUpdate 또는 SubscribedAck가 적용될 때까지 REFUSED를 반환합니다. 명시적으로 DISABLED된 DNS 모드는 포워딩을 유지합니다. 커밋된 UDP/TCP 리스너 중 하나가 예기치 않게 종료되면 첨부 파일은 IP BLOCK_ALL로 격리되고 오류 구독 해지로 보고됩니다.

첨부 파일별

오케스트레이션 시스템이 데몬의 로컬 API를 호출합니다.

RPC:``` DaemonService.Attach(interface_name: "veth123", tc_direction: TC_DIRECTION_INGRESS, metadata: {vm_id: "abc"}) // or DaemonService.Attach(cgroup_path: "/sys/fs/cgroup/...", metadata: {container_id: "xyz"})

**CLI:**```bash
# Attach to a host-side veth peer or VM tap (TC) - use ingress direction
netfenced attach --interface veth123 --direction ingress --metadata vm_id=abc

# Attach to a cgroup
netfenced attach --cgroup /sys/fs/cgroup/... --metadata container_id=xyz

# Attach to an uplink inside the workload's own netns (TC) - egress is the default
netfenced attach --interface eth0 --metadata tenant=acme,env=prod

TC 방향: tc_direction 필드(CLI --direction)는 필터가 연결되는 TCX 훅을 선택하며, 올바른 방향을 선택하는 것은 인터페이스가 링크의 어느 쪽에 있는지에 따라 달라집니다.

방향은 인터페이스(TC) 첨부에만 적용됩니다. cgroup 첨부에는 무시됩니다.

• 데몬은 대상에 eBPF 필터를 첨부합니다.
• control_plane.url이 구성되면 데몬은 Subscribed{id, target, type, metadata}를 보내고 초기 구성(모드, CIDR, DNS 규칙)이 포함된 SubscribedAck를 기다립니다. 제어 평면이 타임아웃(기본 5초, control_plane.subscribe_ack_timeout으로 구성 가능) 내에 응답하지 않으면 첨부가 롤백되고 첨부 호출이 실패합니다. 유효성 검사 및 기타 사전 커밋 실패도 동일한 일반 롤백 규칙을 따릅니다.
• 제어 평면이 구성되지 않은 경우, 첨부는 비활성 모드로 즉시 커밋됩니다. 아래 로컬 정책 명령을 사용하여 구성하십시오.
• 보호된 맵/스토어 실패에 도달하는 유효한 초기 정책은 의도적으로 커밋된 오류 예외입니다. 데몬은 파괴적으로 롤백하는 대신 영구적인 BLOCK_ALL 상태로 첨부를 유지합니다. 제한된 타임아웃을 사용하면 Attach는 유지된 첨부 ID를 포함하는 오류를 반환합니다. 호출자는 List에서 대상을 일치시켜 해당 ID를 발견할 수 있으며, 제어 평면은 완전한 BulkUpdate로 복구해야 합니다.
• subscribe_ack_timeout: 0인 경우, 새로운 Attach는 Subscribed를 큐에 추가한 후 반환됩니다. 이후의 ack는 여전히 유효성 검사 및 적용됩니다. 이 0 값은 복원된 첨부 조정을 비활성화하지 않습니다. 복원 시도는 백그라운드에서 최대 5초 동안 대기하며, 필요한 경우 이후 연결에서 재시도합니다. 이후의 ack가 보호된 압력에 부딪히면, 이미 반환된 첨부는 BLOCK_ALL에 유지됩니다. 는 도 오류 도 내보내지 않으며, 데몬은 재시작 전에 자동으로 선언을 다시 구동하지 않습니다. 에서 와 그 이유, 점유율/용량, 를 감지한 후, 가 포함된 완전한 를 보내 명시적인 복구 결과를 얻으십시오.

RPC:``` DaemonService.Detach(id)

**CLI:**```bash
netfenced detach --id <attachment-id>

첨부 파일 목록:```bash netfenced list netfenced list --all # fetch all pages

### 로컬 정책 및 검사

모든 로컬 변경은 단일 `DaemonService.ApplyCommand(ControlCommand)` RPC의 얇은 CLI 인코딩입니다. `attach`에서 반환된 첨부 ID를 제공하십시오:```bash
# Packet policy and protected CIDRs.
netfenced set-mode <id> allowlist
netfenced allow-cidr <id> 10.0.0.0/8
netfenced allow-cidr <id> 192.0.2.10/32 --ttl 5m
netfenced deny-cidr <id> 10.20.0.0/16
netfenced remove-cidr <id> 10.20.0.0/16 --list deny
# --list accepts allow, deny, or both (the default).

# DNS policy.
netfenced set-dns-mode <id> denylist
netfenced allow-domain <id> example.com --subdomains
netfenced deny-domain <id> blocked.example.com
netfenced remove-domain <id> blocked.example.com

# Deterministic current-policy inspection as protobuf JSON.
netfenced rules <id>

Packet modes are disabled, allowlist, denylist, and block-all; DNS modes are disabled, allowlist, denylist, and proxy. DNS proxy requires a reachable configured control plane. Domain matching uses the most-specific matching suffix; when equally specific allow and deny rules both match, deny wins. CIDRs and domains are canonicalized. Negative, malformed, or otherwise invalid TTLs, enums, CIDRs, domains, selectors, and nested messages are rejected before mutation, so an invalid command is a policy no-op.

For a complete replacement, apply-rules reads the existing BulkUpdate protobuf JSON shape from a file or stdin:```bash cat >rules.json <<'JSON' { "mode": "POLICY_MODE_ALLOWLIST", "allowCidrs": [{"cidr": "10.0.0.0/8"}], "dns": { "mode": "DNS_MODE_DENYLIST", "denyDomains": [{"domain": "blocked.example.com", "includeSubdomains": true}] } } JSON netfenced apply-rules --file rules.json

Equivalent stdin form:

netfenced apply-rules --file - < rules.json

`ApplyCommand`는 `SetMode`, `AllowCIDR`, `DenyCIDR`, `RemoveCIDR`,
`BulkUpdate`, `SetDnsMode`, `AllowDomain`, `DenyDomain`, `RemoveDomain`만 허용합니다.
스트림 전용 동기화/확인 변형, 알 수 없거나 빈 명령, 로컬 `command_id` 값은 거부됩니다. `BulkUpdate`는 또한 안정적인 저하된 패킷 정책을 복구할 수 있는 유일한 로컬 작업입니다. 이 작업은 완전한 LPM 및 DNS 원하는 상태를 포함해야 합니다.

선택적 `ControlCommand.remove_cidr_list` 선택기는 명령 변형이 `RemoveCIDR`일 때 허용 목록, 거부 목록 또는 둘 다를 대상으로 할 수 있습니다. 이전의 지정되지 않은 값과 명시적 `BOTH`는 둘 다 두 목록에서 제거하여 원래 프로토콜 동작을 유지합니다.

로컬 및 제어 평면 변형은 하나의 파서, 변형 장벽, TTL 레지스트리, 장애 폐쇄 복구 경로 및 정책 소유자를 공유합니다. 의도적으로 로컬 대 제어 평면 소유권 중재는 없습니다. 개별 정책 목록에 대한 충돌 작업은 소스에 관계없이 커밋된 순서대로 적용됩니다. 특히, 이후의 완전한 제어 평면 `BulkUpdate` 또는 `SubscribedAck`는 로컬 상태를 대체할 수 있습니다.

`GetRules`/`netfenced rules`는 일관되고 결정적인 사용자 공간 레지스트리 스냅샷을 반환합니다. 각 CIDR은 허용/거부 목록, 로컬 또는 제어 평면 `policyOwned`, 데몬 `systemOwned`, 절대 `expiresAt`, 복원된 `provisional`, 마지막으로 커밋된 커널 `installed` 상태를 보고합니다. 소유자가 없는 설치된 항목은 실패한 제거 재시도이며, 원하는 정책이 아닙니다. DNS 출력은 라이브 정규화된 유효 `DnsConfig`입니다. 검사는 의도적으로 보호된 커널 맵을 열거하거나 동적으로 확인된 DNS 정확한 호스트 캐시 항목을 노출하지 않습니다. 보호된 맵 점유율을 확인하려면 하트비트 텔레메트리를 사용하세요.

## 제어 평면에서 (구현은 당신이 합니다)

`ControlPlane.Connect` RPC - 양방향 스트림을 구현하세요:

gRPC 서버의 연결 유지 시행 정책을 구성하여 데몬의 핑 주기(`control_plane.keepalive_time`, 기본값 30초)를 허용하세요. `MinTime`을 해당 간격 이하로 설정하고 `PermitWithoutStream: true`로 설정하세요. gRPC 기본 정책(5분)은 데몬의 핑을 남용으로 간주하여 `ENHANCE_YOUR_CALM (too_many_pings)`와 함께 연결을 닫습니다. Go에서:```go
grpc.NewServer(grpc.KeepaliveEnforcementPolicy(keepalive.EnforcementPolicy{
    MinTime:             10 * time.Second,
    PermitWithoutStream: true,
}))

데몬으로부터 수신:

• SyncRequest — 연결/재연결 시 (현재 첨부 목록 나열)
• Subscribed — 새 첨부가 추가될 때, 그리고 복원된 첨부가 여전히 새로운 권위 상태가 필요한 경우 SyncRequest 후
• Unsubscribed — 첨부가 제거될 때
• Heartbeat — 통계 포함
• CommandResult{command_id, id, success, error} — 비어 있지 않은 command_id로 보낸 모든 명령의 결과 (ControlCommand의 옵트인 상관 nonce; command_id가 없는 명령은 결과를 생성하지 않음). success는 명령이 완전히 적용된 경우에만 true입니다. 부분 적용된 BulkUpdate는 집계된 오류와 함께 실패를 보고합니다. 결과는 최선의 노력(best-effort)입니다: 누락된 결과는 실패가 아닌 알 수 없음으로 처리하십시오.

데몬으로 전송:

• SyncAck — SyncRequest 수신 후
• SubscribedAck{mode, cidrs, dns_config} — Subscribed 수신 후 (필수 - 데몬이 이를 기다림)
• SetMode{mode} — IP 필터 정책 모드 변경
• AllowCIDR{cidr, ttl} / DenyCIDR / RemoveCIDR (선택적으로 allow, deny 또는 둘 다 선택 가능; 지정하지 않으면 레거시 "both" 동작 유지)
• SetDnsMode{mode} — DNS 필터링 모드 변경
• AllowDomain{domain} / DenyDomain / RemoveDomain (가장 구체적인 일치가 우선; 동일한 구체성에서는 deny가 우선)
• BulkUpdate{mode, cidrs, dns_config} — 전체 상태 동기화

컨트롤 플레인이 Subscribed를 수신하면 완전한 SubscribedAck로 응답해야 합니다. 새 첨부의 경우 데몬은 일반적으로 로컬 호출자에게 성공을 반환하기 전에 해당 ack를 기다립니다. 복원된 첨부의 경우 핸드셰이크는 백그라운드에서 실행되며 고정된 마지막으로 알려진 정책이 계속 적용됩니다. 메타데이터를 사용하여 VM/테넌트/컨테이너를 식별하고 완전한 원하는 모드, CIDR(TTL 포함), DNS 상태를 반환하십시오; DNS 구성이 생략된 경우 빈 도메인 목록으로 비활성화됨을 의미합니다.

재연결 및 멱등성 (필수)

SyncRequest는 권위 있는 조정 지점입니다: 모든 (재)연결 시 스트림의 첫 번째 이벤트이며 데몬의 현재 완전한 첨부 집합을 나열합니다. 이에 대해 보기를 조정하십시오 — 알지 못했던 첨부를 추가하고, 목록에 없는 첨부는 제거하십시오. 재연결 시 데몬은 이전 연결에 대해 대기 중이던 이벤트를 제거합니다(동기화가 이를 대체함). 따라서 동기화에 이미 없는 첨부에 대한 오래된 Heartbeat, Unsubscribed, 또는 죽은 연결의 CommandResult가 재생되지 않습니다. 설계상 두 가지 에지 케이스가 남아 있으며, 컨트롤 플레인은 이들을 멱등적으로 처리해야 합니다:

• SyncRequest가 이미 동일한 ID를 나열하고 있는 경우 Subscribed가 뒤따를 수 있습니다. 이는 새 첨부의 ack가 재연결 사이에 보류 중이었을 때 발생하며, 복원된 모든 첨부에 대해 하나의 권위 있는 ack가 완전히 적용될 때까지 의도적으로 발생합니다. 이를 업데이트로 처리하고 신선한 완전한 SubscribedAck로 응답하며, 중복으로 폐기하지 마십시오. SyncRequest는 첨부 인벤토리를 조정하고, SubscribedAck는 원하는 정책을 조정합니다.
• (재)연결과 동시에 생성된 이벤트는 어떤 방향으로든 동기화 스냅샷과 경합할 수 있습니다. 알 수 없거나 이미 제거된 첨부 ID에 대한 Unsubscribed는 무효(no-op)로 처리하십시오.

규칙 수명 (TTL)

• CIDR 항목(AllowCIDR/DenyCIDR 명령, SubscribedAck/BulkUpdate의 CIDR 목록)은 선택적 TTL을 가지고 있습니다. TTL이 있는 규칙은 데몬의 청소기가 만료되면 제거됩니다(스캔 간격 ttl_janitor_interval, 기본값 1초). TTL이 없는 규칙은 영구적입니다.
• 증분 AllowCIDR/DenyCIDR 재추가는 CIDR을 더 늦은 마감일로 연장합니다 — 단축하지 않음 — 그리고 TTL 없이 증분 재추가하면 영구적으로 만듭니다. 반대로, SubscribedAck/BulkUpdate의 완전한 상태는 각 컨트롤 플레인 수명을 정확히 대체하므로, 권위 있는 조정은 라이브 맵 항목을 제거/재추가하지 않고도 TTL을 단축하거나 영구에서 유한으로 변경할 수 있습니다. 증분 규칙을 조기에 제거하려면 RemoveCIDR을 사용하십시오.
• DNS 확인 IP는 dns.min_filter_ttl(기본값 60초; 0 또는 설정되지 않음은 "바닥 없음"이 아니라 기본값을 의미)로 바닥이 설정된 레코드 TTL과 함께 정확한 계층에만 들어갑니다. 따라서 상위 TTL이 0이면 바닥값 동안 유지됩니다. 생략된 PROXY TTL은 바닥이 적용되기 전에 명시적으로 300초로 기본 설정됩니다. 동일한 주소를 포함하는 영구적이거나 수명이 더 긴 CIDR 규칙은 정확한 DNS 소유권이 만료될 때 보호된 LPM 계층에 독립적으로 설치된 상태로 유지됩니다.
• 권위 있는/시스템 허용 CIDR 및 거부 CIDR은 첨부당 filter.max_rule_entries(각각 기본값 4096)로 크기가 지정된 4개의 보호되고 축출 불가능한 LPM 맵에 남아 있습니다. 위의 "보호된 CIDR 용량 및 장애-폐쇄 복구"를 참조하십시오. DNS 파생 호스트 주소는 (IP 패밀리당 기본값 4096)로 크기가 지정된 별도의 정확 일치 HASH 맵을 사용하므로, 권위 있는 또는 거부 용량을 소비하거나 축출할 수 없습니다. 완전한 DNS 응답 수락은 모든 주소를 검증/정규화하고 변형 전에 물리적 및 논리적 용량을 사전 점검합니다. DNS 정확 맵 커널 오류는 호출 전의 정확한 스냅샷을 복원합니다. 해당 롤백이 입증될 수 없는 경우, 리졸버는 답변을 억제하고 다른 변형을 수락하기 전에 내구성 있는 IP 에 첨부를 격리합니다.